OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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]