RE: [wss] Comments on SAML Token Profile

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

"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-security-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