[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [spam] Re: [ubl-security] Questions regarding the XAdES Profile
The CoO is most of the time issued by a Chambre of Commerce to evidence
the origin of the goods.
Depending of several factors it could be presented into diffeent ways
(e.g. according a Letter of Credit) so it could be required to be signed
by different actors (on paper there were seals) into different times.
The CoO document is a single one even if it should always be provided with
the exporter’s invoice plus other relevant back-up information as
required.
It means that a reference could be sufficient but also attachments
(incorporated) could be useful as well.
It is difficult to predict how the electronic CoO will be required (as the
legal requirements are not our domain)
Here there is a good summary about the CoO:
http://www.export911.com/e911/export/document.htm
After saying that I think we should provide an open way of using the CoO
as it is really subject to different laws and it is very important.
We should ask the International Chambre of Commerce to come on board or
have a temporar or stable liaison.
Sorry I can't help more.
Roberto
>
> El 26/08/2010, a las 02:36, G. Ken Holman escribió:
>
>> At 2010-08-25 18:24 +0200, Oriol Bausà Peris wrote:
>>> > No full agreement is reached as Oriol reported some concern on the
>>> scaffolding structure:
>>> > http://lists.oasis-open.org/archives/ubl-security/201008/msg00031.html
>>>
>>> Why do you need SignatureGroup inside SignatureInformation? Is it not
>>> enough with sig:SignatureInformation as a container for all signatures?
>>
>> Because there could be many groups of signatures, one group for each of
>> the signature business objects in the Certificate Of Origin document.
>> Without the SignatureGroup element, all of the signatures would be mixed
>> ... I don't know if that would impact on workflow or not. But, I feel
>> the association is important to express ... though it is only the
>> Certificate Of Origin for now, future document types might need multiple
>> groups of signatures with each group associated to a different signature
>> business object.
>
> I am not pretty sure about the business process related with the CoO. I
> really don't know if this document is intended for different actors start
> signing different parts of a structured message whenever it is compiled, I
> tend to think that the CoO is a collection of documents, some of them can
> be signed and others not, but I cannot see people signing parts of the
> document.... What I mean is that we are getting to something too complex
> to fulfill a business process that (at least for me) is unclear. If I am
> wrong and the CoO requires different actors signing the same CoO (or
> different parts thereof), then the solution could be fine.
>
>>
>>> > 2) only for documents where more than a single cac:Signature for
>>> different purposes can be present (at present just COO) the
>>> scaffolding can include an ID to reference to the relevant UBL
>>> document part that the signature refers to:
>>> > <sig:SignatureInformation>
>>> > <sig:SignatureGroup> (one, if needed)
>>> > <ds:signature>…</ds:signature> (one or more)
>>> > </sig:SignatureGroup>
>>> > <sig:IdentifiedSignatureGroup> (one or more, if needed)
>>> > <cbc:ID></cbc:ID>
>>> > <sig:SignatureGroup>
>>> > <ds:Signature> … </ds:Signature> (one or more)
>>> > </sig:SignatureGroup>
>>> > </sig:IdentifiedSignatureGroup>
>>> > </sig:SignatureInformation>
>>> >
>>>
>>> why we cannot simply use the identifier attribute from the ds:Signature
>>> element as such signature identifier?
>>
>> Because the declared type of that attribute named "Id" is "ID" which is
>> a *source* attribute ... it isn't an IDREF or a *reference* attribute.
>> It is uniquely identifying each individual signature. All instances of
>> that attribute must be unique in the XML document. The semantic that is
>> needed is an association of a group of signatures to a particular
>> signature business object.
>>
>> Thus, if there are two signatures for one business object with
>> <cbc:ID>x</cbc:ID>, they cannot both have Id="x" because of the schema
>> constraint that says all <ds:Signature Id="?"> attributes must be
>> unique. There would be a validation error. The structure I proposed
>> creates the <sig:IdentifiedSignatureGroup> associated with the
>> <cac:Signature> business object through the <cbc:ID>x</cbc:ID> child,
>> and then the one group of all <ds:Signature> signatures for that
>> association. No validation errors.
>>
>> Also if the signing software wants to add unique identifiers to those
>> signatures, it can do so without interfering with UBL semantics because
>> we will have avoided changing or co-opting anything from the W3C
>> specification for our own purposes ... which on its own is, I think, a
>> compelling reason.
>>
>> So, I'm of the opinion the current attributes and elements in
>> <ds:Signature> cannot give us the association pointer we need to the
>> <cac:Signature> business object. Therefore, after considering your
>> proposal I still think we need the structure I've proposed.
>>
>> *BUT* thinking about the response to your email, something came to mind.
>> I'll start a new thread with my question.
>>
>
> Again, i think all this comes from an unclear business process related to
> the Certificate of Origin, but maybe it is only unclear to me.
>
> Best regards,
> Oriol
>
>
>> . . . . . . . . . . . Ken
>>
>>
>> --
>> XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01
>> Vote for your XML training: http://www.CraneSoftwrights.com/o/i/
>> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
>> G. Ken Holman mailto:gkholman@CraneSoftwrights.com
>> Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc
>> Legal business disclaimers: http://www.CraneSoftwrights.com/legal
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
* JAVEST by Roberto Cisternino
*
* 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
mobile: +39 328 2148123 begin_of_the_skype_highlighting +39
328 2148123 end_of_the_skype_highlighting
skype: roberto.cisternino.ubl-itlsc
[UBL Technical Committee]
http://www.oasis-open.org/committees/ubl
[UBL Online Community]
http://ubl.xml.org
[UBL International Conferences]
http://www.ublconference.org
[UBL Italian Localization Subcommittee]
http://www.oasis-open.org/committees/ubl-itlsc
[Iniziativa divulgativa UBL Italia]
http://www.ubl-italia.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]