RE: [wss] Comments on SAML Token Profile

["Mishra, Prateek" <pmishra@netegrity.com>]

These are two distinct comments that need to be considered independent of each other. The first comment refers to an alleged inadequacy in an OASIS standard and the second comment suggests that this inadequacy be resolved BEFORE profiles can be built against the Standard. I believe this raises significant procedural issues that the TC should provide guidance on, if necessary, via a vote.

 

The WSS Core (“Web Services Security: SOAP Message V1.0”)  is an OASIS standard that has been voted on and accepted by this TC and by OASIS. There are many profiles that will build on this standard. It would be an astonishing situation if profiles were blocked because of alleged issues with the standard. Essentially it would mean that any profile that is built against the standard can be challenged at any point based on allegations of inadequacy with the standard. It also brings into question of the use of the word “Standard” for WSS Core.

 

I would urge the Chairs to consider these comments in two parts:

 

(1)  Proposed errata for “Web Services Security: SOAP Message V1.0”. Once the TC has decided to accept such an errata (Is there a formal errata document and process?) it can be added to the errata list and incorporated within a future “Web Services Security: SOAP Message V1.1”.

(2)  Comments on the SAML Token Profile as based on the interoperability tests, current draft and the following OASIS standards --- SAML 1.1 and “Web Services Security: SOAP Message V1.0”. Comments that fall outside these boundaries should be considered out-of-scope,

 

 

Thanks,

 

Prateek Mishra

 

 

 

---

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