Re: UBL Profile for XML Digital Signatures and XAdES implementation

[JAVEST by Roberto Cisternino <roberto@javest.com>]

Hello,
my comments below,

Andrea Caccia ha scritto:

273DACE4-A786-40E6-98A8-FFE813ED7523@studiocaccia.com" type="cite">

Dear Julián,
Thanks for your answer. I see no difference between this this version of the document and the previous one you already sent. Here follows my comments on the issue you identified.

About identification of the signature: ds:Signature has an ID so it must be unique in the XML document;  if I'm not wrong,  cac:Signature/cbc:ID is mandatory when cac:Signature is present. Taking this into account, if we put in cbc:ID the ID associated with ds:Signature the link is unique and unambiguous, so we can avoid to have cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI with the #xpointer as it is redundant and, I agree with you, does not add any additional information.
  

The problem with comparing the cac:Signature/cbc:ID with the ds:Signature/@Id  is that we are comparing an element with an attribute.
As reported below the uniqueness is checked only on xml:id attributes and not elements.
Into UBL the ID elements are of kind udt:IdentifierType and are based on a normalizedString.

---------------------------------------------------------------------------------
http://www.w3.org/TR/xml-id/

An xml:id processor should assure that the following constraint holds:

• The values of all attributes of type “ID” (which includes all xml:id attributes) within a document are unique.

---------------------------------------------------------------------------------
The above considerations explain why there is not a strict relationship between the cac:Signature/cbc:ID and the ds:Signature/@Id, and the outcome is that developers will be constrained to write a specific code to support the enveloped signature with UBL (a trick!)

It could be enough to ask developers to know the cac:Signature aggregate and XML technologies...

If you do not like xpointer there is a cleaner alternative comparing:

cac:Signature/cbc:ID               (mandatory)

ext:UBLExtensions/ext:UBLExtension/cbc:ID         (optional)

In this case both are UBL IDs o type udt:IdentifierType and it is more acceptable to ask implementers to provide a general knowledge of UBL IDs to their software.

Anyway, by the software development point of view, I think the use of xpointer(...xpath...) is more straightforward to indicate the precise location of the enveloped signature, and xpointer can be used as an URI.

273DACE4-A786-40E6-98A8-FFE813ED7523@studiocaccia.com" type="cite">

About SignatoryParty I think the important information is to identify what is the party that is signing: the seller, the buyer or a third party. This is specially important if the signed document is an invoice. I'm not an UBL expert but as SignatoryParty it's better to have an identifier that is meaningful from the business point of view: in this sense we can also avoid to use the Subject DN (it is likely that it is a parameter you get from the signature verification process as part of the result). So my idea is to let the implementor the freedom to insert here what could be relevant as identification of the signing entity at the business/legal processing level.
  

For parties already specified into the document it is possible to provide just the cac:Party/cac:PartyIdentification/cbc:ID, otherwise the party can be compiled more deeply.

273DACE4-A786-40E6-98A8-FFE813ED7523@studiocaccia.com" type="cite">

I propose to use the optional cbc:Note field available inside cac:Signature to bring the mandatory note you have to mention if the invoice is not signed by the seller (i.e. "issued on behalf of the seller" or whatever the regulation of the seller country mandates).

  

Not very robust, but it is correct for the purpose you decribe (see xsd annotation: "...Free form text about the signature or the circumstances where the signature has been used.")

273DACE4-A786-40E6-98A8-FFE813ED7523@studiocaccia.com" type="cite">

As this document is derived from an original idea (and document) provided by Oriol and as I wrote a good part of the document I think that both of us should be mentioned as Editors, as correctly reported in the document sent by Roberto.
  

I agree

273DACE4-A786-40E6-98A8-FFE813ED7523@studiocaccia.com" type="cite">

Best regards,
Andrea Caccia

____________________________________
Ing. Andrea Caccia - Studio Caccia
Via Bellingera 3 - 21052 Busto Arsizio - Italy
T. (+39) 0331 633523 - F. (+39) 02 700426959
M. (+39) 392 1890070 - SkypeID: a.caccia

Il giorno 24/nov/2009, alle ore 10.23, Julián Inza ha scritto:

  

Dear friends,

Here is the last iteration of the document.

In yellow is marked what I think needs further discussion.

Originally the reference  to the element <ds:Signature> in  <cac:Signature> was done through  cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI  using Id (unique identifier) from  <ds:Signature>.

Now there are two references
-          cac:Signature/cbc:ID using Id (unique identifier) from  <ds:Signature>.
-          cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI  using a  #xpointer to  ds:Signature

I think this adds complexity and I don´t understand why could be useful.

I have made a small change in the specification of SignatoryParty

Originally it was stated that, being optional, if exists PartyIdentification, its  cbc:ID must be signer  subjectDN . This is not bad. But other identifiers can exists, as an example, the issuer VAT number.  
So, in this versión, if there are elements  PartyIdentification, one must contain attribute  schemaID=”X509SubjectName” in  cbc:ID, y (signer cert).

I foresee your comments.

Sorry for the delay.

Best regards,

Julián Inza

<UBL-XAdES-Profile 1.0.doc>
    

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com 
Versione: 8.5.426 / Database dei virus: 270.14.86/2533 -  Data di rilascio: 11/28/09 19:34:00

    

--

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

PPlease consider the environment before printing this email.