OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: <SignedReferences> and RefID (was Re: [dss] Re: comments on XAdES profile wd-02)



Juan Carlos, all -

Juan Carlos raises a point we should consider.  Right now, the only way for 
the client to set a ds:Reference/@Id attribute in a resultant signature is 
to use the <SignedReferences> optional input:

<SignRequest>
   <OptionalInputs>
     <SignedReferences>
       <SignedReference WhichDocument="0" RefId="SomeID"/>
     </SignedReferences>
   </OptionalInputs>
   <InputDocuments>
     <Document RefURI="#SomeURI">......</Document>
   </InputDocuments>
</SignRequest>

Juan Carlos proposes allowing RefId on input documents:

<SignRequest>
   <InputDocuments>
     <Document RefURI="#SomeURI" RefId="SomeID">......</Document>
   </InputDocuments>
</SignRequest>

This avoids the need for <SignedReferences>, if all you want to do is set 
the ds:Reference's Id.

Why didn't we do this in the first place?
  - Logically, it makes sense to separate properties of the input document 
from properties of the <ds:Reference>.
  - Since you can use <SignedReferences> to create multiple <ds:Reference>s 
for the same input document, in that case we'd have to specify how the 
document's RefId interacts with the SignedReference's RefId (should they 
match? should the document's RefId not be present?  should the 
SignedReference override the document?)
  - It adds 2 ways to do the same thing, which means more code, and more 
cases to test.

So I'd rather leave this as-is.

Other comments?


Trevor



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]