Re: Sample instances

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

At 2010-08-14 08:38 +0200, Oriol Bausą Peris wrote:
>I am sorry, I forgot to attach the files in my 
>last mail. Here come both samples. They of 
>course do not include all the new ideas and identifiers proposed by Ken.

But it does lead me to a question:  how did you 
accomplish the embedding of the extension 
elements in any form at all?  I see the correct 
use of <ext:*> elements and the embedding of the 
<odsig:document-signatures> element, even though 
that element is missing the version attribute 
required by the schema but inadvertently missed in the Security SC document.

So this leads me to believe that you were able to 
somehow add those scaffolding elements yourself 
and then trigger the signature software to embed 
the actual <ds:Signature> element.  Is this 
true?  Are we, then, safe to continue with our 
own wrapper specification and not be obliged to 
use an existing ODF or OCF wrapper?  If so, this is good news.

My revelation was that even if we *did* try to 
save effort by adopting a standardized wrapper 
such as ODF or OCF, a UBL instance cannot use 
that wrapper without embedding the extension 
scaffolding we require to allow the schemas to 
still validate an instance.  So this scaffolding 
means we can never use any off-the-shelf 
signature software unless it gives us the 
flexibility to specify the wrapper for the 
wrapper, so we might as well have our own wrapper 
and put in the features we need.

Can you share with us, Oriol, the effort it took 
to configure your software to include the 
extension schema scaffolding in the instance?

>As we were talking about when defining the spec, 
>you'll see that there is no signature aggregate, 
>as adding this ABIE makes the signature process very complex.
>
>Regarding the CoO, I think we should clarify the 
>use and scope of the signatures that are 
>enveloped inside this document, maybe adding 
>some special paragraph in the recommendation. 
>And regarding the UBL ABIE Signature, my 
>recommendation is not using it as it is 
>unnecessary, can create inconsistencies with the 
>actual signature, and generates some problems when signing the xml instance.

As Tim pointed out it could be used for alternate 
methods of specifying a signature, like referencing a PDF file.

So I think the security committee can *recommend* 
the use of cac:Signature in conjunction with 
sig:Signatures and ds:Signature, but not require 
it.  That way it provides additional information 
if available, but the UBL document is still 
digitally signed even if <cac:Signature> is not 
present, and the schemas stay as they are in PRD1 
so that the scaffolding for <ds:Signature> is standardized.

So based what I hope your answer will be, Oriol, 
the schemas might finally be complete.  We 
standardize the scaffolding for <ds:Signature> in 
the extension schema fragments of UBL's namespace 
(not OCF nor ODF).  And the Security SC revises 
their document regarding the recommended 
association between a <cac:Signature> element and 
the extension, not making it a requirement.  A 
community of users can then, seeing the 
recommendation, choose to adopt the 
recommendation as a requirement.  But whether a 
sender of a UBL document adopts that 
recommendation or not, all recipients of the 
document will still be able to verify the digital 
signature in <ds:Signature> with or without the 
supplemental documentation in <cac:Signature>.

Unless anyone objects, then, I'll proceed with 
the SGTG schema production for PRD1.

Thank you for taking from your time to look at 
this on the weekend!  I hope to have something 
published by the end of today (my time).

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