Re: [ubl] Re: Making references

[Enric.Staromiejski.Torregrosa@everis.com]

If admitedly this is a legal question,
not a technical one, then we should not forget that many (?) countries
accept dettached signature as a legal solution (Spain does). So, i wonder
if it is really vital or necessary making all this fuzz about how to "embed"
external namespaced concepts in UBL when other possible solutions are legally
and technically provided?

(Sorry if i missed any important details
that invalidates my opinion...i just over-read the thread and had no time
to get into details yet).

Regards

Jon Bosak <bosak@pinax.com>

01/12/2009 18:07

To	Universal Business Language <ubl@lists.oasis-open.org>
cc	Oriol Bausà <ORIOL@INVINET.ORG>, "G. Ken Holman" <gkholman@CraneSoftwrights.com>, JAVEST by Roberto Cisternino <roberto@javest.com>, Andrea Caccia <andrea.caccia@studiocaccia.com>, Juliá n Inza <julian.inza@albalia.com>, ubl-security@lists.oasis-open.org
Subject	Re: [ubl] Re: Making references

Hello everyone,

For better management of this discussion, the TC agreed today to
move further correspondence regarding this issue back onto the
Security SC list.  Ken Holman has been added to the Security SC as
a member to allow him to participate on the subcommittee mail list.

Anyone wishing to monitor the discussion can follow it on the
Security SC archive at

http://lists.oasis-open.org/archives/ubl-security/

Jon

Oriol Bausà wrote:
> Hi Ken,
> 
> Just for clarifications:
> 
> El 01/12/2009, a las 13:38, G. Ken Holman escribió:
>>>
>>> Then you would only require to place the signature in an Extension
>>> and no requirements on Signature placeholders for UBL (that's
the 
>>> case BTW of the invoice, required in some legislations in
Europe but 
>>> without the Signature Component in the Invoice structure)
>>>
>>
>> Sorry, I'm not sure what you mean by that ... we already have
a 
>> requirement in cac:Signature that it have a mandatory identifier.
 
>> Please forgive my confusion.
>>
> 
> I meant getting rid of the Signature element in UBL and just explaining
> how to use Extensions as placeholders for enveloped XAdES Signatures.
> This way you do not have to provide for the usage of Signatures in
> business documents, it is a legal issue, not a document model issue.
> 
>>
>>> Another possible way of solving this would be to have a Signature
>>> component with a "anyType" structure inside to be
used as a signature 
>>> placeholder, but getting rid of all the components about signature
>>> (such as Canonicalization Method or Signature Algorithm) and
all the 
>>> reference problems.
>>>
>>>
>>> <cac:Signature>
>>>
>>> <cac:SignatureAttachment>
>>>
>>> <ds:Signature>
>>>
>>> ...
>>>
>>> </ds:Signature>
>>>
>>> </cac:SignatureAttachment>
>>>
>>> </cac:Signature>
>>>
>>
>> Unfortunately not because the schema constraints for cac:Attachment
do 
>> not provide for XML markup ... it must be a base64-encoded item,
and I 
>> think we want <ds:Signature> to be in clear text.  The
way 
>> cac:Attachment works would require:
>>
>>
>>   <cac:Signature>
>>
>>     <cac:DigitalSignatureAttachment>
>>
>>       <cbc:EmbeddedDocumentBinaryObject>
>>
>>         .....binary data in base64 format....
>>
>>       </cbc:EmbeddedDocumentBinaryObject>
>>
>>     </cac:DigitalSignatureAttachment>
>>
>>   </cac:Signature>
>>
> 
> Sorry for the unfortunate sample, I was meaning a new 
> SignatureAttachmentType, something like
> 
>   <xsd:complexType name="SignatureAttachmentType">
>     <xsd:sequence>
>       <xsd:any namespace="##any" minOccurs="0"
maxOccurs="1" 
> processContents="skip"/>
>     </xsd:sequence>
>   </xsd:complexType>
> 
> 
> I know this is not allowed in UBL except for the extension points
> but.... this was my point.
> 
> 
>>
>> .... and you can see that not only we would "lose sight"
of the fact 
>> that it is <ds:Signature> but that processing applications
looking for 
>> <ds:Signature> would not find it.
>>
> 


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




AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y
confidencial y va dirigida exclusivamente a su destinatario. everis informa
a quien pueda haber recibido este correo por error que contiene información
confidencial cuyo uso, copia, reproducción o distribución está expresamente
prohibida. Si no es Vd. el destinatario del mismo y recibe este correo
por error, le rogamos lo ponga en conocimiento del emisor y proceda a su
eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.This message and the information contained
in or attached to it are private and confidential and intended exclusively
for the addressee. everis informs to whom it may receive it in error that
it contains privileged information and its use, copy, reproduction or distribution
is prohibited. If you are not an intended recipient of this E-mail, please
notify the sender, delete it and do not read, act upon, print, disclose,
copy, retain or redistribute any portion of this E-mail.