ACTION-60

Dear all,

This message is in response to action 60: Investigate mime types vs uri.

First I compile all the sentences in XMLSig that refer to one and the 
other, and afterwards, starting from these sentences I try to reach some 
conclusions or formulate questions where I am not able to reach them.

1. Sentences on attribute ds:Reference's Type attribute. This is of type 
xs:anyURI.

1.1 Section 4.3.3 says:

"The |Type| attribute facilitates the processing of referenced data. For 
example, while this specification makes no requirements over external 
data, an application may wish to signal that the referent is a |Manifest"

1.2 Section 4.3.3.1.

For this section we have produced two sentences that read as follows:
|

"The optional Type attribute contains information about the type of 
object being signed after all |ds:Reference| transforms have been 
applied. This is represented as a URI. For example:"

The Type attribute applies to the item being pointed at, not its 
contents. For example, a reference that  results in the digesting of an 
|Object| element containing a |SignatureProperties| element is still of 
type |#Object|. The type attribute is advisory. No validation of the 
type information is required by this specification."


2. Sentences on attribute ds:Object's mimeType attribute. This is of 
type xs:string.

2.1 Section 4.5 says:
" The |MimeType| attribute is an optional attribute which describes the 
data within the |Object| (independent of its encoding). This is a string 
with values defined by [MIME 
<http://www.w3.org/TR/xmldsig-core/#ref-MIME>]. For example, if the 
|Object| contains base64 encoded PNG <http://www.w3.org/Graphics/PNG/>, 
the |Encoding| may be specified as 'base64' and the |MimeType| as 
'image/png'. This attribute is purely advisory; no validation of the 
|MimeType| information is required by this specification. Applications 
which require normative type and encoding information for signature 
validation should specify |Transforms 
<http://www.w3.org/TR/xmldsig-core/#sec-Transforms>| with well defined 
resulting types and/or encodings."


3. Conclusions

On ds:Reference's  Type attribute XMLSig says that "contains information 
about the type of object being signed after all |ds:Reference| 
transforms have been applied".


On ds:Object's mimeType attribute XMLSig says that it is an "optional 
attribute which describes the data within the |Object| (independent of 
its encoding)"

---> With this reading it seems difficult to me see the differences 
between both attributes. There are, nevertheless, two things that seem 
to give some clue:

1. For ds:Reference's Type attribute, XMLSig mentions two usage 
examples, one identifying the type as a #Manifest and the other 
identifying it as an #Object.

2. For ds:Object's mimeType, XMLSig mentions that its values must be one 
of the values defined in MIME.
These values identify the media type of what is within ds:Object.

It could initially thought that ds:Reference's Type operates at a higher 
level than the ds:Object's mimeType, the first identifying that what is 
signed is a ds:Object and the second identifying that the media type of 
what is signed si for instance a pdf document. If this is true then 
these attributes could be seen as somehow orthogonal.

But this interpretation has one drawback:

1. If the signature is dettached and the signed data object is not a 
child of a ds:Object, then how to report its media type?

If I am not wrong (and please forgive me if I am) the text in a MIME 
media type identifier could also be seen as a relative URI reference (a 
one having a relative-part= path-noscheme without query and fragment). 
If we may set the ds:Reference's Type attribute to a MIME media type 
then we may assert the media type of the dettached data object to be 
signed, but then we should make it clear that both attributes overlap in 
their purposes.

In the light of that, I would propose:

1. Decide whether both attributes may overlap in their purposes and in 
fact a mime media type identifier may be part of the ds:Reference's Type 
attribute.

2. Propose text for notes (that will not be mandatory) to be included in 
XMLSig that clearly reflect the aforementioned decisions.

Regards

Juan Carlos.

Received on Monday, 9 July 2007 13:07:53 UTC