Michael McIntosh/Watson/IBM wrote on 06/24/2004 07:32:58 PM:
> "Maneesh Sahu" <> wrote on 06/24/2004 06:20:25
PM:
>
> > Hi Michael,
> >
> > Adding a wsu:Id to the SecurityToken - the SAML Assertion in this case
> > would cause it to violate the SAML schema. Is this permissible?
>
> Maneesh,
>
> The proposal is not to add anything to the existing SAML Assertion, but
to create a
> SAMLToken element with a wsu:Id attribute and a child SAML Assertion
element.
Another possibility would be to use a wsse:KeyIdentifier to reference the
SAML Assertion by AssertionID.
This would be prefered to doing it form the wsse:Reference since finding
tokens by Key Identifier is by definition token specific, but using
wsse:Reference for Direct Reference to a local token is best done using
token agnostic methods.
>
> Thanks,
> Mike
>
> >
> > --ms
> >
> > -----Original Message-----
> > From: Michael McIntosh [mailto:]
> > Sent: Thursday, June 24, 2004 3:04 PM
> > To: Ron Monzillo
> > Cc: Anthony Nadalin;
> > Subject: Re: [wss] Comments on SAML Token Profile
> >
> > Ron Monzillo <> wrote on 06/24/2004 12:01:08
PM:
> >
> > >
> > >
> > > Anthony Nadalin wrote:
> > >
> > > > We ran into some inconsistencies while participating in the recent
> > > > SAML interop. The WSS core specification describes a "Direct
> > > > Reference" mechanism to be used with STRs. A Reference element
with
> > a
> > > > URI attribute is used. When the referenced token is located within
> > the
> >
> > > > Security header, the URI contains a shorthand XPointer reference
to
> > > > the token. In order for this to work, the token element must
contain
> >
> > > > an attribute of type ID. WSS defines the wsu:Id attribute with
type
> > ID
> >
> > > > for naming the reference. Direct references within the message
> > should
> > > > not require token specific methods so we suggest the following
> > actions
> >
> > > > be taken:
> > > >
> > > > 1) Errata to the WSS core to make it clear the tokens must have an
> > > > attribute named wsu:Id.
> > > > 2) Change to the SAML Token Profile to use an wsu:Id attribute or
> > use
> > > > a wsse:KeyIdentifier
> > > >
> > > These changes are not a good idea.
> >
> > It is a good idea, otherwise the dereferencing mechanism would require
> > XML
> > schema processing to enable it to identify which attributes were ID
> > type.
> >
> > Please see my response to Rich Levinson.
> >
> > >
> > > The wsu:id attribute was defined for use as a convenience where new
> > shema
> > > elements are being defined, or with elements which support attribute
> > > extensibility
> > > and which do not already include an id attribute.
> > >
> > > The only constraint on using an STR Direct Reference with a fragment
> > > containing
> > > an id value is that the thing being referenced must have an
attribute
> > of
> >
> > > type id.
> > >
> > > In SAML V1.1 the AssertionID attribute so qualifies, that is:
> > >
> > > <attribute name="AssertionID" type="ID" use="required"/>
> >
> > I do not understand the aversion to adding the wrapper element. It
seems
> >
> > to me that it makes it easier for services to support the profile.
Using
> >
> > the known ID type of wsu:Id facilitates extensibility of platforms to
> > enable new token types. Using token specific mechanisms for references
> > potentially requires modifying the core WSS dereferencing processing
for
> >
> > every new token type.
> >
> > >
> > > Ron
> > >
> > > PS: I also concurr with Rich Levinson
> > >
> > > > In particular, the ValueType attribute (lines 702-708) appears to
be
> >
> > > > intended
> > > > to provide token-specific processing rules to be applied in
> > > > conjunction with
> > > > the URI attribute. In the case of SAML 1.1 assertions, the SAML
> > ValueType
> > > > indicates that the saml:AssertionID should be treated as an XML ID
> > type
> > > > attribute.
> > >
> > > >
> > > > Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
> > > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from the
roster
> > of
> > the OASIS
> > > TC), go to
> >
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
> > .php.
> > >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster
of
> > the OASIS TC), go to
> >
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
> > .php.
> >
> >
> >
