[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Issue 389: Detection of Duplicate IDs
Your solution still isn't quite restrictive enough, because it misses two cases: 1) It doesn't detect the case where two attributes *with different names* both contain a relevant ID. 2) The reference that points to the ID doesn't contain the name, only the value, so given a document like: <foo wsu:id="thisIdentifier" xmlns:foo="the ws-utility namespace"> <bar fumble:grumble="thisIdentifier" xmlns:fumble="some third-party namespace"/> <mumble refersTo="thisIdentifier"/> </foo> we need to know: (a) foo/mumble/@refersTo is of type IDREF. This we can hard code, because we know which IDREFs we care about - the ones in WS-Security and XMLDSIG. (b) foo/@wsu:id is of type ID. Again, fine, because we either have the WSU schema or we hard code this case. (c) Whether or not foo/bar/@fumble:grumble is of type ID. If fumble:grumble is ID, then we have a conflict, because we can't tell which element the IDREF is supposed to point at. On the other hand, if fumble:grumble is a non-ID type, this document is perfectly legal. There are lots of use cases that could look like this; a likely case would be for fumble:grumble to be another IDREF that the third party schema uses to point at a relevant enclosing element. The *only* way to resolve point (c) is to have access to the schema for the third party namespace. Aside: was anybody on this list around for the original design of ID attributes in XML? Did anyone suspect that it was going to cause this much trouble? - irving - > From: ronald monzillo [mailto:Ronald.Monzillo@Sun.COM] > > Reid, Irving wrote: > >>From: ronald monzillo [mailto:Ronald.Monzillo@sun.com] > >> > >>Is is not sufficient to say something like the following > >> > >>The wsse:Security processing MUST generate a fault if it > employs any > >>id attribute in its processing for which there are multiple > elements > >>within the message that share that same id attribute name and value. > > > > > > No, it's not sufficient. The attribute *name* is completely > irrelevant. All > > attributes that are given type "ID" by some XML schema or > DTD map into the > > same identifier namespace, in a sense. That's why it's such > a problem - when > > you get an arbitrary XML document, you need to have access > to all the > > applicable schemas in order to determine which attributes are IDs. > > > > - irving - > > > > It may be that I didn't communicate clearly enough. > > I think the rule I proposed would be more restrictive than > necessary, as > the processing COULD avoid generating faults if the id-ness > of duplicate > (relative) named attibute can be determined or if the fully qualified > names of such attributes can be determined; but knowing > either of these > things would require schema knowledge (which we don't want to > require). > > If same (relative) named and valued attributes can be > detected (without > schema knowledge), and we reject documents where such attribute > instances are employed in the wssee:Security processing > performed on the > document, then wouldn't we be throwing away all potentially dangerous > messages and a few others? > > Ron > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]