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