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

[Oriol Bausą Peris <oriol@invinet.org>]

El 26/08/2010, a las 02:36, G. Ken Holman escribió:

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

I am not pretty sure about the business process related with the CoO. I really don't know if this document is intended for different actors  start signing different parts of a structured message whenever it is compiled, I tend to think that the CoO is a collection of documents, some of them can be signed and others not, but I cannot see people signing parts of the document.... What I mean is that we are getting to something too complex to fulfill a business process that (at least for me) is unclear. If I am wrong and the CoO requires different actors signing the same CoO (or different parts thereof), then the solution could be fine.

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

Again, i think all this comes from an unclear business process related to the Certificate of Origin, but maybe it is only unclear to me.

Best regards, 
Oriol


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