[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Comments on SAML Token Profile
I have reviewed the documents that Paul recommended below. I certainly don't claim to be an expert in these matters, but reading over the material, I have come to the following perception of the situation. There are 2 basic classes of XML parsing applications: those that check for well-formedness and those that also check for validity based on DTDs and/or XML schemas. The concept of ID only comes into play in the latter case of validity checking, but validity checking has huge overhead of schema/DTD location etc. To fill the void between well-formedness and validity, ad hoc implementations have emerged which just add a little IDness to the well-formedness. "wsu:Id" is an instance of an ad hoc implementation filling the void for the WS-Security domain. "xml:id" is a target under consideration by the W3C to potentially fill the void for all domains, although it will require evolution of existing applications before it is reached, if, in fact, the target becomes a W3C Recommendation which it currently is not. The problem we have been discussing appears to revolve around whether profiles that extend the WS-Security core spec should have the ability to define their own IDness if the IDness provided by WS-Security is not sufficient. Taking all this into consideration, I still look at lines 699-708 of the core spec which are copied below and interpret the meaning of ValueType to indicate that token-specific processing of the URI attr is the intended capability. And therefore, I see no reason why token-specific IDness should explicitly be forbidden from set of token-specific processing that can be supplied to implement the profile. Also it appears to me that this attribute defn (702-708) was very carefully constructed and well thought out, and if the authors of the original definition can provide further guidance as to whether there were specific limits on its scope that are not apparent, then that would be very useful to those of us who were not part of its original creation. 699 /"wsse:SecurityTokenReference/wsse:Reference/@URI 700 This optional attribute specifies an abstract URI for where to find a security token. If a 701 fragment is specified, then it indicates the local ID of the token being referenced. 702 /wsse:SecurityTokenReference/wsse:Reference/@ValueType 703 This optional attribute specifies a URI that is used to identify the type of token being 704 referenced. This specification does not define any processing rules around the usage of 705 this attribute, however, specifications for individual token types MAY define specific 706 processing rules and semantics around the value of the URI and how it SHALL be 707 interpreted. If this attribute is not present, the URI MUST be processed as a normal URI. 708 The usage of ValueType is RECOMMENDED for references with local URIs. " Rich Levinson Netegrity -----Original Message----- From: Paul Cotton [mailto:pcotton@microsoft.com] Sent: Friday, June 25, 2004 12:18 PM To: Levinson, Richard Cc: Anthony Nadalin; maneesh@westbridgetech.com; wss@lists.oasis-open.org; Michael McIntosh; Frederick.Hirsch@nokia.com Subject: RE: [wss] Comments on SAML Token Profile > Any implementation that has done the above to support the wsu namespace > with local name "Id" should find it straight forward to also then support > the saml namespace with local name "AssertionID". This would push us further down the slippery slope of changing our parsers to recognize each special ID attribute as it arrives on our door step. This is not only bad design but it creates a huge deployment problem. For a better design and solution to this problem I suggest you check out the W3C xml:id Version 1.0 Working Draft [1]. For those new to this problem I suggest you check out the W3C TAG issue [2] from which the xml:id work originated. /paulc [1] http://www.w3.org/TR/2004/WD-xml-id-20040407/ [2] http://www.w3.org/2001/tag/issues.html?type=1#xmlIDSemantics-32 Paul Cotton, Microsoft Canada 17 Eleanor Drive, Nepean, Ontario K2E 6A3 Tel: (613) 225-5445 Fax: (425) 936-7329 mailto:pcotton@microsoft.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]