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