Object tag in Dsig 2.0

Ed had reviewed Signature 2.0 and pointed out that this particular paragraph does not make sense in the 2.0 mode.  I have an action (ACTION-556) to fix it.



Here is Ed's comment :
7) In section 4.6, it says "Note, if the application wishes to exclude the <Object> tags from the digest calculation the Reference must identify the actual data object (easy for XML documents)...". More detail is needed here about how this is going to work in "2.0 mode"
given the new restrictions on the <Reference> @URI attribute and the <dsig2:Selection> transform only returns element nodes (right?).

------------

My proposal:

The <Object> tag is meant for Enveloping signatures, where the user wants to put the data to be signed inside the <Signature> itself.  There are three subcases for this.

a) The data to be signed is a single XML subtree, and it is present as a child of the <Object>.  The subtree has an ID, and the <Reference> uses this ID to look up this subtree, no transforms are used.  This is the simple use case, I propose that we only support this one in 2.0. 

b) The data to be signed is multiple XML subtrees and they are present as a child of <Object>. The <Object> has the ID, and the <Reference> uses Transforms to select only the child of <Object>. In 2.0 this can be possibly done using an IncludedXPath of "/../ds:Object/*", but I propose that we don't mention this case at all.

c) The data to be signed is binary. The <Object> tag has a Encoding and MimeType attributes to indicate what kind of binary it is. Again this could be supported in 2.0 with Type = "...binary" and Subtype = "...fromBase64Node"  but I propose that we don't mention this.

   
Personally I have never seen an <Object> tag being used in practice.  That's why I am suggesting that we only support the very simplest use case for Object tag in 2.0 mode, and leave everything else in Compatibility mode.

Pratik

Received on Tuesday, 1 June 2010 17:53:11 UTC