Re: [ubl-security] New draft (UBL-XAdES-Profile 1.0-20100321)

[Andrea Caccia <andrea.caccia@studiocaccia.com>]

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

> 
>>> 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? 
Another option is to have it just recommended, being mandatory only if cac:Signaure is not present.

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

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