Re: [wss] Comments on SAML Token Profile

[Anthony Nadalin <drsecure@us.ibm.com>]

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.