RE: [wss] Comments on SAML Token Profile

[Michael McIntosh <mikemci@us.ibm.com>]

"Maneesh Sahu" <maneesh@westbridgetech.com> 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.

Thanks,
Mike

> 
> --ms
> 
> -----Original Message-----
> From: Michael McIntosh [mailto:mikemci@us.ibm.com] 
> Sent: Thursday, June 24, 2004 3:04 PM
> To: Ron Monzillo
> Cc: Anthony Nadalin; wss@lists.oasis-open.org
> Subject: Re: [wss] Comments on SAML Token Profile
> 
> Ron Monzillo <Ronald.Monzillo@Sun.COM> 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.
> 
> 
>