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