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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Last call issues with schema



I'm not sure why we wouldn't use xsd:anyURI instead of xsd:NCName for saml:IDReferenceType.
If we want to refer across documents don't we need a URI?

WS-Security uses xsd:anyURI to point to ids, as in a "direct reference" with the URI
attribute on the wsse:Reference element [1]

Does this make sense?

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones

[1] http://www.oasis-open.org/committees/download.php/1043/WSS-SOAPMessageSecurity-11-0303.pdf



> -----Original Message-----
> From: ext Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Monday, May 05, 2003 10:13 PM
> To: SAML
> Subject: [security-services] Last call issues with schema
> 
> 
> I've been communicating with Eve regarding a couple of 
> outstanding issues with the proposed 1.1 schemas, discovered during my
> implementation testing of signed messages based on the new spec.
> 
> Mostly things are looking good, but I discovered two problems 
> with our attribute/type definitions, one a definite XML bug, the other
> technically correct but wrongly implemented by at least one 
> popular parser.
> 
> The definite change is that we currently propose that the 
> saml:IDReferenceType be an IDREF, and this is not legal in 
> XML because an
> IDREF has to be referencing an ID value that appears in the 
> document. Our use of IDReferenceType is for attributes like 
> InResponseTo
> that reference ID values in a *different* message. We need to 
> change the type to xsd:NCName which has the same syntax as IDREF but
> doesn't have any other requirements.
> 
> The other issue is due to the fact that our new ID attributes 
> are not directly given the xsd:ID type, but are given the saml:IDType
> type, which is in turn an xsd:ID. This seems to be legal, but 
> is not supported by one validating parser that I know of, Xerces-C (as
> of 2.2). They plan to fix this at some point. Xerces-J does 
> support this now. I don't know how many other parsers might 
> exhibit the
> bug.
> 
> We could consider removing the saml:IDType type, and just 
> directly define AssertionID/etc. as xsd:ID, in the interest 
> of making life
> easy for implementers. I'm not sure we lose anything 
> important doing that, since the only real reason to define a 
> new type is to
> change the allowable values, and we don't do that. If we did 
> want to do that, and I'm not sure why we would, we could do it in 2.0.
> 
> -- Scott
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]