RE: [wss] Comments on SAML Token Profile

["Levinson, Richard" <rlevinson@netegrity.com>]

It appears to me that the WS-Security core spec is loose
enough to accept both your interpretation and the interpretation
that is in the SAML Token Profile spec. Lines 305-308 show
the use of a "custom token" where the particular token
has a wsu:ID that is referenced by the STR that has only
a URI attribute.

I think it is reasonable to consider a SAML Assertion to
be a "custom token" in this sense, with the exception that
the SAML Assertion does not allow the wsu:Id attribute.

As such, the SAML Token profile has chosen to take advantage
of the ValueType attribute which states "... specifications
for individual token types MAY define specific processing
rules and semantics around the value of the URI and how it
SHALL be interpreted.". (lines 705-707)

It would seem reasonable to me that when a recipient encounters
a token with a particular ValueType that the recipient would
know whether or not it contains the facilities for processing
such a token. In the case of the SAML Assertion, the processing
facility would seem to be little more than applying the same
technique used to establish wsu:Id as an ID type attribute, i.e.
to establish the AssertionID as an ID type attribute, as well,
when dereferencing the URI with the SAML ValueType.

If we were to take the "strict interpretation" then XML tokens
would be divided into two classes: those that allow wsu:Id attr
and can be peers of other tokens in the Security header and
those that don't, which would have to reside one level lower.

Possibly, the authors of the clauses that we are citing could
weigh in and help us resolve the interpretations.

	Rich Levinson
	Netegrity

 

-----Original Message-----
From: Michael McIntosh [mailto:mikemci@us.ibm.com] 
Sent: Thursday, June 24, 2004 5:59 PM
To: Levinson, Richard
Cc: Anthony Nadalin; wss@lists.oasis-open.org
Subject: RE: [wss] Comments on SAML Token Profile

"Levinson, Richard" <rlevinson@netegrity.com> wrote on 06/22/2004 09:44:43
AM:

> I have reviewed this comment and I think it may be an overly 
> restrictive interpretation of the intended usage of the URI attribute 
> described in
the
> WS-Security core spec, section 7.2, lines 699-701. 

The lines you reference state that "... If a fragment is specified, then it
indicates the local ID of the token being referenced."

I think you also must look at Section 4 (lines 363-374) which state "There
are many motivations for referencing other message elements such as
signature references or correlating signatures to security tokens. For this
reason, this specification defines the wsu:Id attribute so that recipients
need not understand the full schema of the message for processing of the
security elements. That is, they need only "know" that the wsu:Id attribute
represents a schema type of ID which is used to reference elements. However,
because some key schemas used by this specification don't allow attribute
extensibility (namely XML Signature and XML Encryption), this specification
also allows use of their local ID attributes in addition to the wsu:Id
attribute. As a consequence, when trying to locate an element referenced in
a signature, the following attributes are considered: 
? Local ID attributes on XML Signature elements ? Local ID attributes on XML
Encryption elements ? Global wsu:Id attributes (described below) on
elements"

I think this make it clear that the intent is to require wsu:Id for ID type
attributes (other than those defined in XML Signature and XML
Encryption) because doing otherwise would require the WSS processing to have
access to and process the schema for every part of every message.

Please explain why the SAML token profile could not add an outer element
containing a wsu:Id element?

> 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-securit
y-1.0.pdf
> 
> 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. As described in section 4.2 lines 418-425, this may be 
> done without requiring XML schema validation.
> 
> I have also looked at the REL Token Profile specification that has 
> been approved by the TC and this appears to suggest using this same 
> mechanism with direct references in Table 2 (section 3.4 line 150) and 
> shows this
mechanism
> used in the example in section 3.5.1 lines 308-309, 336-342,  and 
> again
in
> the example in section 3.6.1 lines 404-405, 423-425 (although the
ValueType
> appears to have been left out in this 2nd example).

The REL Token Profile makes it clear that where a Local Direct Reference is
used, that it be done using s reference to the wsu:Id attribute. The other
forms of reference are for external references.

> 
> 
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/7347/oasis-___
_-wss-
> REL-token-profile-1.0-draft08-clean.pdf ,
> 
> From my reading of these documents plus the use of the STR mechanism 
> in scenario 3 of the SAML Interop, which is compliant with the
recommended
> usage in the SAML Token Profile (Section 3.3.1 lines 318-319, lines
326-331)
> 
> 
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/6877/WSS-SAML-
11.pdf
> 
> it appears that both the SAML and REL authors and interop participants
have 
> interpreted the usage of ValueType and URI in the STR element to allow
for the 
> token (license or assertion) having its own ID-type attribute.
> 
>     Rich Levinson
>     Netegrity
> 
> 
> From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
> Sent: Monday, June 21, 2004 2:39 PM
> To: wss@lists.oasis-open.org
> Subject: [wss] Comments on SAML Token Profile

> 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
> 
> Anthony Nadalin | work 512.838.0085 | cell 512.289.4122