OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]