Fwd: Re: [ubl-security] Re: Sample instances

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

>Date: Mon, 16 Aug 2010 10:22:35 +0800
>From: Tim McGrath <tim.mcgrath@documentengineeringservices.com>
>Organization: Document Engineering Services Ltd.
>To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
>CC: Andrea Caccia <andrea.caccia@studiocaccia.com>,
>  Jon Bosak <bosak@pinax.com>
>Subject: Re: [ubl-security] Re: Sample instances
>
>(Ken: please forward to ubl-security)
>
>As i tried to explain I have lost track of what we are trying to do 
>here. I thought the ubl-security SC was trying to create a profile 
>of the UBL cac:Siganture that could identify a XADES digital signature.

Yes, that is my understanding as well.

>Now we are designing UBL extensions for XADES digital signatures

Yes, work began in August 2009.  This will be the first 
committee-standardized extension.  It becomes a model for people 
creating their own extensions.

Sadly, W3C Schema wild card limitations provide for defining only a 
single extension namespace at a time for validation purposes.  But 
that is something that can be discussed in an implementation guideline.

>and trying to relate them to parts of a UBL document?

No, the other way around.  UBL appears to have multiple signatures 
(as in the COO) and so if there are, say, two signature references in 
the COO and two signature groups in the extension, it was thought 
necessary by the members of the Security SC to point to the extension 
from the signature business object.

>If we need an extension to store a XADES signature then this 
>extension does not need to refer to the main document (or parts of 
>it). I would have thought that the main document (or parts of it) 
>would refer to the signatures in the extension.

Precisely.  And when there is more than one signature in the main 
document then there will be multiple signature groups in the extension.

Every document other than the COO has (or will have when we fix the 
final five that currently don't have one) exactly one signature 
business object and it will work with the extension point without the 
need for correlating identifiers.  As you say, the UBL document need 
not have a signature business object and the scheme will still 
work.  If it has exactly one signature business object, the scheme 
will work with or without a correlating identifier.

If, however, there is more than one signature business object in the 
instance then correlating the business object with the group of 
signatures associated with that object is seen as necessary.

>In other words the extension will just contain the required XADES 
>structures. The UBL cac:Signature allows us to refer to parts of the 
>document (such as the extension) - isn't that what we should be doing here.

I believe that is exactly what we are doing here.

>Why make this so complicated?

Where is the complication?  The structure seems so very simple.

>Why design new structures?

Because we don't have a standardized extension.  All of the 
structures I've designed are for the extension.  No-one on the 
Security SC has proposed touching the signature business object in 
the common library.

>The direction seems wrong to me.

But if we don't dictate what goes in the extension, then we won't 
have a standardized extension for everyone to use.

>Am i missing something?

Perhaps so ... did you perhaps think we were talking about the common 
library in all of this discussion?  We are not.  We are, and have 
been for a year now, talking about what goes into the technical 
committee's first standardized extension.

>Perhaps we should try to summarize what we are aiming for before 
>getting into naming issues.

The committee has set out its requirements and we have pretty well 
agreed on the structure of the extension.  I'm trying to accommodate 
the modeling conventions for naming and structuring.

. . . . . . . . . . . Ken
begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:Managing Director
tel;work:+45 36 95 33 58
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard


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