[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
Sorry if this is something that should be obvious to me, but I'm not understanding the need for multiple signatures on UBL CertificateOfOrigin. I thought our document was just the *application* for a COO. Did I get that wrong? Jon Roberto Cisternino wrote: > 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 >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]