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

["Roberto Cisternino" <roberto@javest.com>]

We originally avoided binding the URI to a specific version of UBL because
this methodology could be used with UBL 2.0 and later versions.

I also would like to enphatise that this URI should be clearly represent a
a profile for digital signatures with UBL.

So the actual URI is in some way assciated to the above concept.

http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature

But the new URI is too generic:

http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/signature-defined

I agree that pointing to a permanent location is valuable, so as UBL 2.1
is a minor version I think the UBL-2.1 root is fine but the URI should be
revised to meet the original intentions.

For instance:

http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/profiles/dsig/signature-defined

Cheers,

Roberto

> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>


-- 
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123 begin_of_the_skype_highlighting              +39
328 2148123      end_of_the_skype_highlighting
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org