RE: [wss] Comments on SAML Token Profile

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

<Frederick.Hirsch@nokia.com> wrote on 06/25/2004 10:17:25 AM:

> Why cannot reference saml:AssertionId if specified in profile? Same 
xsd:Id type as 
> wsu:ID, also "well known" to profile. Same properties as wsu:Id. Why a 
problem? 

Because WSS implementation knows wsu:Id is of type xsd:Id.
In order for it to know saml:AssertionID (or any other token defined 
attribute) is of type xsd:Id, requires schema processing.

> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> > -----Original Message-----
> > From: ext Anthony Nadalin [mailto:drsecure@us.ibm.com]
> > Sent: Thursday, June 24, 2004 7:01 PM
> > To: Maneesh Sahu; Michael McIntosh
> > Cc: wss
> > Subject: Re: [wss] Comments on SAML Token Profile
> > 
> > 
> > Also pointed out is to use KeyIdentifier
> > 
> > -
> > Anthony Nadalin
> > Sent from my BlackBerry Handheld.
> > 
> > 
> > ----- Original Message -----
> > From: "Maneesh Sahu" [maneesh@westbridgetech.com]
> > Sent: 06/24/2004 04:20 PM
> > To: Michael McIntosh/Watson/IBM@IBMUS
> > Cc: <wss@lists.oasis-open.org>
> > Subject: RE: [wss] Comments on SAML Token Profile
> > 
> > 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?
> > 
> > --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.
> > 
> > 
> > 
> > 
> > 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.
> > 
> > 
> 
> 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.
>