Re: [ubl-security] Questions regarding the XAdES Profile

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

At 2010-08-25 18:24 +0200, Oriol Bausą Peris wrote:
> > No full agreement is reached as Oriol 
> reported some concern on the scaffolding structure:
> > http://lists.oasis-open.org/archives/ubl-security/201008/msg00031.html
> >
> > I summarize very quickly what is the solution we are discussing:
> >
> > 1) all UBL documents will have a 
> document-wise cac:Signature (optional) element 
> and the general scaffolding structure inside the UBL extension is:
> > <sig:SignatureInformation>
> > <sig:SignatureGroup>
> >  <ds:signature>…</ds:signature> (one or more)
> > </sig:SignatureGroup>
> > </sig:SignatureInformation>
> >
>
>Why do you need SignatureGroup inside 
>SignatureInformation? Is it not enough with 
>sig:SignatureInformation as a container for all signatures?

Because there could be many groups of signatures, 
one group for each of the signature business 
objects in the Certificate Of Origin 
document.  Without the SignatureGroup element, 
all of the signatures would be mixed ... I don't 
know if that would impact on workflow or 
not.  But, I feel the association is important to 
express ... though it is only the Certificate Of 
Origin for now, future document types might need 
multiple groups of signatures with each group 
associated to a different signature business object.

> > 2) only for documents where more than a 
> single cac:Signature for different purposes can 
> be present (at present just COO) the 
> scaffolding can include an ID to reference to 
> the relevant UBL document part that the signature refers to:
> >  <sig:SignatureInformation>
> >    <sig:SignatureGroup> (one, if needed)
> >      <ds:signature>…</ds:signature> (one or more)
> >    </sig:SignatureGroup>
> >    <sig:IdentifiedSignatureGroup> (one or more, if needed)
> >      <cbc:ID></cbc:ID>
> >      <sig:SignatureGroup>
> >        <ds:Signature> … </ds:Signature> (one or more)
> >      </sig:SignatureGroup>
> >    </sig:IdentifiedSignatureGroup>
> >  </sig:SignatureInformation>
> >
>
>  why we cannot simply use the identifier 
> attribute from the ds:Signature element as such signature identifier?

Because the declared type of that attribute named 
"Id" is "ID" which is a *source* attribute ... it 
isn't an IDREF or a *reference* attribute.  It is 
uniquely identifying each individual 
signature.  All instances of that attribute must 
be unique in the XML document.  The semantic that 
is needed is an association of a group of 
signatures to a particular signature business object.

Thus, if there are two signatures for one 
business object with <cbc:ID>x</cbc:ID>, they 
cannot both have Id="x" because of the schema 
constraint that says all <ds:Signature Id="?"> 
attributes must be unique.  There would be a 
validation error.  The structure I proposed 
creates the <sig:IdentifiedSignatureGroup> 
associated with the <cac:Signature> business 
object through the <cbc:ID>x</cbc:ID> child, and 
then the one group of all <ds:Signature> 
signatures for that association.  No validation errors.

Also if the signing software wants to add unique 
identifiers to those signatures, it can do so 
without interfering with UBL semantics because we 
will have avoided changing or co-opting anything 
from the W3C specification for our own purposes 
... which on its own is, I think, a compelling reason.

So, I'm of the opinion the current attributes and 
elements in <ds:Signature> cannot give us the 
association pointer we need to the 
<cac:Signature> business object.  Therefore, 
after considering your proposal I still think we 
need the structure I've proposed.

*BUT* thinking about the response to your email, 
something came to mind.  I'll start a new thread with my question.

. . . . . . . . . . . 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