Re: [ubl-security] Where to go from here - Final proposal?

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2010-08-30 08:29 -0400, I wrote:
>True.  Consider that (I believe) a user could use the following to 
>digitally sign a single line item whose ID is '12345', thus allowing 
>any of the remainder of the document to change but this signature to 
>remain valid:
>
>    <Transform
>      Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
>     <XPath xmlns:cac="..." xmlns:cbc="...">
>       ancestor-or-self::cac:InvoiceLine[cbc:ID='12345']
>     </XPath>
>    </Transform>
>...
>And one could scope the signing of *only* the attachment and nothing 
>else through this XML signature hash transformation expression:
>
>  <Transform
>    Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
>   <XPath xmlns:cac="..." xmlns:cbc="...">
> 
>ancestor-or-self::cac:ExternalReference[cbc:FileName='Invoice1234OCR.gif']
>   </XPath>
>  </Transform>
>
>... provided, of course, that aggregate has the hash and algorithm filled in.

What the flexibility in the above has brought to mind is that a user 
wanting to do any of the above may wish to document with the 
signature the reason or purpose in adding the particular 
signature.  In parallel with extension reasons, this suggests 
augmenting the structure as follows with new optional signature 
metadata constructs:

   <sac:SignatureInformation>
     <cbc:ID>...</cbc:ID>
     <sbc:ReferencedSignatureID>...</sbc:ReferencedSignatureID>
     <sbc:SignatureReasonCode>(code value)</sbc:SignatureReasonCode>
     <sbc:SignatureReason>(text value)</sbc:SignatureReason>
     <ds:Signature>
       ...
     </ds:Signature>
   </sac:SignatureInformation>

The above would allow the user to formally document the signatures 
being added to the document.  And for a user community to dictate 
that, say, "five different signatures are possible for a document and 
this is the code list of possible values for the reason code".  Such 
reasons are inappropriate for the <ext:ExtensionReasonCode> and 
<ext:ExtensionReason> elements, because those elements relate to the 
entire extension, not just to a single signature.

For a moment I thought of adding <cac:SignatoryParty> but then it 
became too much a copy of <cac:Signature> and too much of a business 
object, so I took it out.  I think the above metadata is suitably 
restrictive to be considered as metadata for the digital signature 
and not business information.  The party information can likely be 
found anyway in the <ds:Signature> content.

Any objections to adding this reason-related signature metadata to the model?

. . . . . . . . . . Ken


--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal