>Thus, we are back to my suggestion that we need to wrap
ds:Signature with an aggregate in order to associate a cbc:ID with
>ds:Signature.
In the attached mail I propose to reference the enveloped signature by
using the existing UBLExtension ID:
cac:Signature/cbc:ID ---------reference--------->
ext:UBLExtensions/ext:UBLExtension/cbc:ID
Is it acceptable ?
We already use internal references between payment terms and payment
means, so I think this is viable.
Cheers,
Roberto
---
JAVEST by Roberto Cisternino ha scritto:
4B126604.6030800@javest.com" type="cite">
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 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
|