Re: [ubl-security] UBL-XAdES-Profile 1.0-RC1

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

At 2010-08-11 17:14 -0400, I wrote:
>- in fact I now believe (after working on this document) that we 
>should not use a simple string that is too easily ambiguous with 
>what users might inadvertently use (yes, I know "UBL" is not common, 
>but why use an ad hoc identification scheme when there is one we can 
>use) and select two URNs for the values on lines 430 and 435, and 
>the values along the lines of:
>
>  <cac:Signature>
> 
><cbc:ID>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature</cbc:ID>
>    [...]
> 
><cbc:SignatureMethod>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/xades-enveloped</cbc:SignatureMethod>
>    <cac:SignatoryParty>
>      <cac:PartyIdentification>
> 
><cbc:ID>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature-defined</cbc:ID>
>      </cac:PartyIdentification>
>    </cac:SignatoryParty>
>    [...]
>  </cac:Signature>

Something just came to mind regarding the URI strings:  as is true 
with namespaces, I think we typically do not include "CD" or "PRD" or 
"CS" in URI strings because software working with the drafts will 
have to change for the final version even if nothing changes in the 
specification.

We don't have to do it today, but I would like to take out the "cd-" 
from the above strings so that when we go through the different 
phases we will not have to change what we have in the examples.

Moreover, after discussion with Jon, we should use URI strings that 
will resolve to a file in the distribution (once the distribution is 
mounted after final voting and standardization, so a *long* time from today).

Therefore I suggest we standardize the following:

  <cac:Signature>
    <cbc:ID>http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/signature</cbc:ID>
    [...]
    <cbc:SignatureMethod>http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/xades-enveloped</cbc:SignatureMethod>
    <cac:SignatoryParty>
      <cac:PartyIdentification>
        <cbc:ID>http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/signature-defined</cbc:ID>
      </cac:PartyIdentification>
    </cac:SignatoryParty>
    [...]
  </cac:Signature>

To support this, we then create in the distribution the following files:

  etc/signature/index.html
  etc/xades-enveloped/index.html
  etc/signature-defined/index.html

When we have done this, then if any user sees the HTTP URI in a 
signature and they blindly plug that HTTP URI into a web browser, 
what they will see will be the index.html file that the SecuritySC 
creates for the distribution.

So we need three files from the SecuritySC, each one describing the 
semantic represented by the URI used in the document.  For example:

  etc/signature/index.html
     "This URI identifies a signature in a UBL document that is
      tied to the committee standardized extension for embedding
      a digital signature"
  etc/xades-enveloped/index.html
     "This URI identifies the method of using the committee
      standardized extension for embedding a digital signature"
  etc/signature-defined/index.html
     "This URI indicates that the party is identified in
      the signature embedded in the committee standardized extension"

... or something along those lines.

These will be the first pages we have that are resolved as URI 
strings, so we have to think about the syntax and appearance, but we 
don't have to do that for PRD1.  But I think we do need the three 
files for PRD1 so that we can get feedback on what we have to say in the files.

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