[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: [spam] Re: [ubl-security] Questions regarding the XAdES Profile
I think we do nto have to create limits to current UBL documents expecially legal documents like CoO and Invoice, instead we should provide the instrument/methodologies to let implementers build more specific profiles driven by business rules. The way UBL is it is streightforward to support business requirements and XAdES for legal signature-related things. If we remove the problem of applying more signatures (see my previous mail) why we need scaffolding ? The cac:Signature can be used as it is intended for metadata related to business and to satisfy practices like those in CoO. The cac:Signature in the root context can still be the metadata for document-wide signatures (and now you can insert as many metadata you want. I proposed an alternative way to use existing UBL mechanisms. This mode is no more constraining the cac:Signature, the number of signatures, the time when it is applied. Also XAdES has nothing less and can be used fully into UBL Extensions. Cheers, Roberto > I wad working on this in parallel to last proposal from Roberto. > > This is a simplification in line with the "scaffolding approach": I think > we should firstly make a decision if: > 1) staying with the old approach with some allowed ways to fit additional > requirements by loosening some security feature on exceptional basis > 2) staying with the scaffolding approach, possibly simplifying it (an > example is hereafter) > 3) privilege only flexibility but loosing a lot of security features that > I feel can be unacceptable in some circumstances (that we cannot assess in > a very short timeframe) > > My personal view is to go with 1) and possibly move to 3) (or 2))if we > find a sound rationale for it, possibly based on the comments we'll > receive in public review. > > Andrea > > > Il giorno 27/ago/2010, alle ore 09.44, Oriol Bausą Peris ha scritto: > >> >> El 26/08/2010, a las 23:06, G. Ken Holman escribió: >> >>> At 2010-08-26 16:49 -0400, Jon Bosak wrote: >>>> Sorry if this is something that should be obvious to me, but I'm >>>> not understanding the need for multiple signatures on UBL >>>> CertificateOfOrigin. >>> >>> This sample from Roberto illustrates the multiple signatures on the one >>> form: >>> >>> http://www.export911.com/e911/export/docFormA.htm#docFormA >> >> I am sorry but I think the sample from Roberto shows that the CoO is >> signed by two different people. So it is a single group (using your >> terminology) of two signatures. They are signing the whole document, not >> parts of it, so there is not need for identifying which part of the >> document they are signing. > > I'd like to clarify a point here: the signed object is always the whole > document. The ID mechanism is just for having a logical association, a > sort of pointer between a signature [group] and a part (a section) of the > document. > I'd like to add also that I'd like to avoid that this logical association > is necessairly to a cac:Signature: I think this element should be always > optional and that it should be possible to logically associate a signature > to whatever element that has an <cbc:ID>. This way we can be very flexible > without having to modify the core syntax for any local legal requirement > that has to be met > > Reading the last comments from Roberto it is not clear to me if there is > always a single document signature associated to the document, and having > the cac:Signature just a reference, or if the document has multiple > signature [groups]. > > I think we can have a simpler structure: > > <sig:SignatureInformation> > <sig:SignatureGroups> (one or more) > <cbc:ID> </cbc:ID> (an optional pointer to a section of the UBL > document; if absent it is a generic signature [group] applied to the > whole document) > <sig:SignatureGroup> > <ds:Signature> </ds:Signature> (zero or more signatures associated > to the same cbc:ID) > </sig:SignatureGroup> > </sig:SignatureGroups> > </sig:SignatureInformation> > > At the time first signature has to be added, an example of the required > scaffolding is: > <sig:SignatureInformation> > <sig:SignatureGroups> > <sig:SignatureGroup> > </sig:SignatureGroup> > </sig:SignatureGroups> > > <sig:SignatureGroups> > <cbc:ID>CertificateOfOriginApplicationID</cbc:ID> > <sig:SignatureGroup> > </sig:SignatureGroup> > </sig:SignatureGroups> > > <sig:SignatureGroups> > <cbc:ID>IssuerEndorsementID</cbc:ID> > <sig:SignatureGroup> > </sig:SignatureGroup> > </sig:SignatureGroups> > > <sig:SignatureGroups> > <cbc:ID>EmbassyEndorsementID</cbc:ID> > <sig:SignatureGroup> > </sig:SignatureGroup> > </sig:SignatureGroups> > > <sig:SignatureGroups> > <cbc:ID>InsuranceEndorsementID</cbc:ID> > <sig:SignatureGroup> > </sig:SignatureGroup> > </sig:SignatureGroups> > > </sig:SignatureInformation> > > Any xxxID content of cbc:ID is just used to clarify for the example > purposes what is meant to be associated to the signature[group] in the COO > example. > Not all pointers are needed if it is already known in advance that some > are not required; in case it is not known in advance if a > sig:SignatureGroups element could be present even if, at the end, no > ds:signature is really inserted. > > > > --------------------------------------------------------------------- > 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]