| Hi Andrea and all,
I think you have made a good summary of our discussion, and I agree with it.
Thank you! Oriol El 06/04/2010, a las 00:35, Andrea Caccia escribió: I try to summarize, so I am able to update the draft:- for enveloper signatures, there are will be 2 RECOMMENDED places for the URI defined by this SC: - in cac:Signature/cbc:SignatureMethod , and - in ext:UBLExtensions/ext:UBLExtension/ExtensionURI
at least one MUST be present. If both are present and not equal the verification fails. - for detached signatures cac:Signature/cbc:SignatureMethod MUST be present - for enveloped signatures ext:UBLExtensions/ext:UBLExtension/ext:ExtensionReasonCode MAY contain an identifier for the purpose of the signature. A code list qualified with attributes: agency, version
--> I ask Roberto to provide some text here
I'm expecting also some comments from Ken and the correct xpath from Juan Carlos, if these come in the next few days there is the chance I can produce a new draft by the end of this week considering all the contributions.
About adding some unsigned information, I suggested to use signature unsigned properties (inside the signature) as it is already a standard place to put any user defined content and is not signed, so it can be added after the signature without invalidating it (an example is when a timestamp attribute on the signature is added, of course after the document is signed). If the data we do not want to sign is part of the UBL document it is more complicated as this requires to modify the xpath. I think we need a very good reason to proceed this way as it raises a lot of problems about how to make aware the user on what portion of the document is signed and what is not, and this could be very tricky to implement.
Andrea
Il giorno 06/apr/2010, alle ore 00.02, JAVEST by Roberto Cisternino ha scritto:
Oriol Bausą Peris ha scritto:
B7DCB287-8E71-474B-8EB4-998FFC182CCB@invinet.org" type="cite">
Hi all,
El 05/04/2010, a las 13:43, Andrea Caccia escribió:
Hi Oriol and Roberto,
Il giorno 05/apr/2010, alle ore 12.46, Oriol Bausą Peris ha scritto:
Hi Roberto,
El 05/04/2010, a las 12:33, JAVEST by Roberto Cisternino escribió:
Oriol Bausą Peris ha scritto:
Hi Andrea,
We have been working with the document in CODICE and there are some issues that I've tried to arise in the release I am currently attaching to this document.
1) When using enveloped signature, it is not mandatory using a cac:Signature element. You can optionally provide for it, but you are not mandated to do so.
This is requested by CODICE in Spain ?
It is not a request from CODICE , it is just common sense, we should not use something just because is there, we need to think if it makes sense or we need to rethink about it.
I think it makes sense that an UBL application has a standard place to look for to quickly understand if a document is signed and how.
What about:
- recommending cac:Signature for enveloped signatures. If there is a good reason not to use it it can be omitted but, n this case, ext:ExtensionURI MUST be set (see above).
- keeping it mandatory for detached signatures, as there is no other way to mark it as signed
I can agree with this approach, this means that the cac:Signature is optional for enveloped signatures and required for detached signatures.
ok, but this is an "IF" and thus not a consistent, unique way of
indicating signatures... but I am fine.
B7DCB287-8E71-474B-8EB4-998FFC182CCB@invinet.org" type="cite">
This means that you will be able to sign with this profile any kind of UBL document, despite the fact modellers added this structure to the document model. I mean that one thing is the data model of the document, and another thing are the legal provisions that require a signature to be placed there. That's why I recommend to change MUST for MAY when talking about enveloped signataure and cac:Signature element.
if we follow any local request we will end to be unable to obtain interoperability.
The reason we provide an UBL profile for signatures is to achieve interop.
If CODICE do not want to use the UBL profile then it will be not interoperable with other implementers.
Yes, we are all trying to build the UBL profile to achieve interoperability, and CODICE wants to use the UBL profile to sign their documents, and that's why there are some concerns arising in this early phase, when trying to implement the points of the recommendation. I think that our considerations should be taken into account to improve the recommendation, and make it easier for implementors to follow and adopt.
Any feedback is very welcome, we should be as open as possible avoiding any interoperability issue
I told Andrea to use the ext:ExtensionURI to indicate the UBL Profile URI on the extension, so maybe we can say the cac:Signature is not necessary if the ext:ExtensionURI is valorized.
That's ok with me.
I apologize but there is a mistake, I thought it was done but the text in 4.1 is not updated while the example in the same paragraph is.
The idea is to avoid any constraint on "cbc:ID" inside the UBL extension and set ext:ExtensionURI as shown in the example, i.e. with the URI:
http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/enveloped
Do you see any problem to have this as mandatory?
Mandatory in the profile not in the schema (of course)
So if this is mandatory in the UBL profile, this is a consistent way of
driving implementers to achieve interoperability.
B7DCB287-8E71-474B-8EB4-998FFC182CCB@invinet.org" type="cite">
Another option is to have it just recommended, being mandatory only if cac:Signaure is not present.
another "IF" which is something to code in the software....... but I am
fine.
B7DCB287-8E71-474B-8EB4-998FFC182CCB@invinet.org" type="cite">
I would prefer the second option
ext:ExtensionReasonCode could be also used if necessary to identify the purpose of the signature: payment authorization (for direct Debit) or the signature of the invoice issuer.
I also agree with this point.
It's a good idea but can we restrict (or suggest) a list of possible codes here?
Definetly we should provide a list of possible codes here, if we want to use that item of information.
I agree, we know a set of values that could be used here.
B7DCB287-8E71-474B-8EB4-998FFC182CCB@invinet.org" type="cite">
2) I think there are some mistakes, talking about enveloping instead of enveloped signatures during the document.
Thanks for pointing this out
3) I haven't added nothing about this yet, but there is a requirement for unsigned data, a placeholder where people can add stuff after having signed the document. I'll come back to you with this issue later on.
Can we use unsigned properties inside the signature(s)? This way we can rely on an already defined processing model and we do not have to define anything new.
Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com
Versione: 8.5.437 / Database dei virus: 271.1.1/2791 - Data di rilascio: 04/04/10 18:32:00
--
JAVEST by Roberto Cisternino
<Javest-Logo-1.1.gif>
* 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
PPlease consider the environment before
printing this email.
|