RE: ACTION-581: proposal around IDness of attributes

Scott,

Since this element is per reference, should the signer precisely specify how the ID was specified, or give a generic list of ID attribute definitions?


E.g. let us say the first reference  uses xml:Id and the second uses wsu:ID.  Does the signer have to put in xml:Id  for the first and wsu:ID front the second, or can he put in both for both references? The second option is imprecise, but it is easier for the signer, he can just say list out all the Id mechanisms that he normally uses, and not precisely specify which one he is using for a particular reference. However the first option is better for the verifier and that is what I have assumed.

Please review this section - 
4.4.3.9 http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/Overview.html#sec-Verification-2.0
and 3.2.6 http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/Overview.html#sec-ReferenceValidation-2.0

This should complete my actions: ACTION-636, ACTION-637 and ACTION-639

Pratik

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Sunday, August 22, 2010 2:47 PM
To: public-xmlsec@w3.org
Subject: ACTION-581: proposal around IDness of attributes

The issue I'm trying to address with this action is the same problem that led to the creation of xml:id.

Without a DTD, there is technically no way to define IDness in an XML document. In practice, this typing was extended to documents validated by an XML Schema, and then to the creation of xml:id. Unfortunately, DTDs have mostly fallen out of practice, and schemas are expensive, rarely used in many runtime scenarios, and can't be counted in to be completely known by the verifying entity in the presence of extensible XML scenarios.

xml:id has not seen wide adoption yet, mainly because a lot of the standards that needed it (SAML, WS-Security) predated it.

The result of all this is that applications that rely on ID-based references for signing have typically made insecure assumptions about the IDness of attributes based on their name (ID, id, Id, etc.), or have to provide APIs for applications to call before verification (which is also a problem for extensibility). DOM level 3, which is now fairly widely implemented, also provides the ability to identify attributes as an ID at runtime, although often without guaranteeing the uniqueness property.

My suggestion is that we piggyback on the proposed <dsig2:PositionAssertion> that Pratik just added to the draft and turn this into a generalized IDAssertion that includes not only the positional XPath expression, but also an optional list of elements:

	<dsig2:QualifiedID name="..." ns="..."/>
	<dsig2:UnqualifiedID name="..." parentname="..." parentns="..."/>

This is analagous to the proposed mechanism for the c14n QNameAware option to identify QName attributes, but for IDness instead.

This would tell the verifier which attributes the signer believed to be IDs, and thus give the verifier information it might not otherwise have about how to perform the dereference process.

Both the XPath positional expression and the list of attributes would be optional, or we could leave the PositionAssertion alone and add a new one for this information. I suggest combining them simply because they both deal with ID-based reference information.

I like using the Verification step as a container for this proposal because it again pushes the complexity onto verifiers that want to use the information without complicating applications that might have other ways of dealing with IDs already.

-- Scott

Received on Thursday, 26 August 2010 08:29:39 UTC