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

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

El 26/08/2010, a las 17:21, G. Ken Holman escribió:

> At 2010-08-26 17:08 +0200, Oriol Bausą Peris wrote:
> 
>> El 26/08/2010, a las 02:36, G. Ken Holman escribió:
>> 
>> 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.
> 
> The CoO work came out of Singapore and I don't think we have access to the people who had particular workflows in mind when they modeled multiple signature business objects in a single document.
> 
> Nevertheless, if our solution were structured as you proposed with only a single group of signatures, this would also preclude future UBL documents from supporting associations with multiple signature groups should that be necessary.

What I really do not understand is who may require now or in the future having multiple signatures for different parts of a UBL document. That's why the identifier should be required isn't it? And I do not understand also the need to differentiate different groups of signatories using a UBL extension schema.

> 
> Regardless, a particular customization could choose to subset the use of the extension to only the unassociated signature group ... whereas another customization would find multiple groups useful for CoO or future documents.
> 
> I think in UBL we have been trying to present flexible solutions from which communities of users can pare down what is available into what they need.  Tags are cheap ... we don't have to make the length of them or the number of them the absolute smallest theoretically possible and thereby jeopardize simplicity or understandability.

I think we should present flexible solutions, but I also think we should present simple solutions allowing the community to deploy tools implementing it. And I think that technical complexity that does not answer clear requirements is something that will confuse the community

>> 
>> 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.
> 
> But I think I've also proven that the solution of using any <ds:Signature> attribute or descendant is not appropriate, thus necessitating us proposing a UBL-based solution for the association of a group of signatures to one of possibly many signature business objects in a document.  Yes, CoO is the only one thus far with multiple signature business objects, but I think having this flexibility will be important in case future documents need to have this feature.  If communities don't want the feature, they can subset its use.
> 
> But I will defer if people can propose an alternative.  Just that the alternative of using the <ds:Signature Id=""> attribute is technically inappropriate because of the uniqueness constraint on the attribute value.  And what about future documents that need flexibility if they choose to use more than one <cac:Signature> element in their design, which they have every right to choose?
> 
> I value that other proposals are being put forward ... this properly challenges what I've put forward so that we can search for a better solution if my proposal falls short.  If other proposals can be made as soon as possible, we can go to PRD1 with something for the community to test.
> 
> . . . . . . . . . . . Ken
> 
> p.s. any immediate feedback on my other message of last night regarding the scope of the signature hash will be very helpful ... if someone endorses that change I'm proposing then I can make another ZIP for Jon for the packaging that has the revised example.
> 

Nevertheless, if the rest of the SC is okey with the proposed solution, then I'll just stop arguing on that...

All the best
Oriol

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