[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: Sample instances
I like the sig:SignatureGroup concept. The rule for XPath is that "everything inside sig:SignatureGroup is unsigned". This way you can add and delete signatures as required by the workflow. If there is the need to "approve", i.e. sign another signature, the standard way to do it is a countersignature, but I see very limited use for this. I think that in a workflow signatures are added and deleted as needed e.g. by business approval rules; at the end the document can just have a final signature replacing all intermediate ones. And signatures applied by some authority are applied to the document content I guess. A countersignature becomes an unsigned property inside a signature, meaning that you can add whatever countersignatures you want without breaking anything. The only drawback with countersignatures is that someone has to countersign a document with more than one signature, he/she has to countersign each signature. A countersignature, being the signature of a signature, confirm at the same time a signature and the data signed by the signature to which the countersignature applies. This should be enough general for any business need, keeping in mind thai, in the great majority of cases, we'll have one or more signatures applied to a document and, in this case, the scaffolding becomes very simple: <sig:Signatures> <sig:SignatureGroup> <ds:signature>…</ds:signature> (one or more) </sig:SignatureGroup> </sig:Signatures> For the remaining questions, I have no specific comments and UBL TC has to choose to better align this with design rules. Andrea Il giorno 15/ago/2010, alle ore 14.28, G. Ken Holman ha scritto: > At 2010-08-15 11:25 +0200, Andrea Caccia wrote: >> I agree with the "scaffolding approach" and the solutions found. > > Thank you for making the time to comment. > > Two issues come up with your post: > >> If we still need to relate signature with parts of the UBL document I suggest to use this scaffolding in the UBL extension: >> <ublsig:document-signatures> >> <ds:signature>…</ds:signature> >> ... >> <ublsig:IdentifiedSignature> >> <cac:ID>…<cac:ID> >> <ds:signature>…</ds:signature> >> </ublsig:IdentifiedSignature> >> ... >> </ublsig:document-signatures> > > I like distinguishing between those signatures with an ID and those without. > >> I think a schema can be implemented with a sequence of choices so that inside a ublsig:document-signatures container could be found a sequence of <ds:signature> or <ublsig:IdentifiedSignature> in any order and quantity. > > In order to better follow the UBL modeling concepts we need to think of: > > (a) - "document-signatures" should be either "DocumentSignatures" or, > since some of the signatures do not have document scope, perhaps > just "Signatures" > > (b) - the arbitrary mixing of order breaks one of the modeling instructions > so we have to have an order > > (c) - I wonder if we need a UBL container for all <ds:signature> since it > already is, itself, a container, but I think this will be a better > instruction to software implementers: without an identifier find > or create the <sig:UnidentifiedSignatures> element and put the > <ds:signature> in it > - the problem with this is that it has to be a singular noun, not > plural, so perhaps <sig:UnidentifiedSignatureSet> > > (d) - I realized my earlier suggestion was mixing two namespaces as siblings > which is fine for <cbc:*> and <cac:*> but is it acceptable for the > <ds:*> non-UBL namespace? > >> The <ublsig:IdentifiedSignature> element can refer to a specific section of the UBL document via the cac:ID if this is required to disambiguate the reference and, as most of the UBL documents have just the document-wise signature, in this case there is no need to do any preparation work, they will contain just the simple scaffolding we already defined: >> <ublsig:document-signatures> >> <ds:signature>…</ds:signature> >> <ds:signature>…</ds:signature> >> … >> </ublsig:document-signatures> >> >> For other documents it should be quite easy to add something like: >> >> <ublsig:document-signatures> >> <ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … (these are the document-wise signature(s) ) >> <ublsig:IdentifiedSignature> >> <cac:ID>…<cac:ID> (ID of cac:CertificateOfOriginApplication when required) >> <ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … >> </ublsig:IdentifiedSignature> >> <ublsig:IdentifiedSignature> >> <cac:ID>…<cac:ID> (ID of cac:IssuerEndorsement when required) >> <ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … >> </ublsig:IdentifiedSignature> >> <ublsig:IdentifiedSignature> >> <cac:ID>…<cac:ID> (ID of cac:EmbassyEndorsement when required) >> <<ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … >> </ublsig:IdentifiedSignature> >> <ublsig:IdentifiedSignature> >> <cac:ID>…<cac:ID> (ID of cac:InsuranceEndorsement when required) >> <ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … >> </ublsig:IdentifiedSignature> >> ... >> </ublsig:document-signatures> > > I like the above (repairing cac: with cbc:) if Tim approves of mixing <cbc:*> with <ds:*> ... so it would read as follows: > > <sig:Signatures> > <ds:signature>…</ds:signature> > (these are the document-wise signature(s) ) > <ds:signature>…</ds:signature> > <sig:IdentifiedSignature> > <cbc:ID>…</cbc:ID> (ID of cac:CertificateOfOriginApplication when required) > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:IdentifiedSignature> > <sig:IdentifiedSignature> > <cbc:ID>…</cbc:ID> (ID of cac:IssuerEndorsement when required) > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:IdentifiedSignature> > <sig:IdentifiedSignature> > <cbc:ID>…</cbc:ID> (ID of cac:EmbassyEndorsement when required) > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:IdentifiedSignature> > <sig:IdentifiedSignature> > <cbc:ID>…</cbc:ID> (ID of cac:InsuranceEndorsement when required) > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:IdentifiedSignature> > ... > </sig:Signatures> > > If we want to not mix <ds:*> and UBL namespaces as siblings, and also tell implementers that in UBL there is only ever one parent of <ds:signature> elements and it is named <sig:SignatureGroup>, then we could have: > > <sig:Signatures> > <sig:SignatureGroup> > <ds:signature>…</ds:signature> > (these are the document-wise signature(s) ) > <ds:signature>…</ds:signature> > </sig:SignatureGroup> > <sig:IdentifiedSignatureGroup> > <cbc:ID>…</cbc:ID> (ID of cac:CertificateOfOriginApplication when required) > <sig:SignatureGroup> > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:SignatureGroup> > </sig:IdentifiedSignatureGroup> > <sig:IdentifiedSignatureGroup> > <cbc:ID>…</cbc:ID> (ID of cac:IssuerEndorsement when required) > <sig:SignatureGroup> > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:SignatureGroup> > </sig:IdentifiedSignatureGroup> > <sig:IdentifiedSignatureGroup> > <cbc:ID>…</cbc:ID> (ID of cac:EmbassyEndorsement when required) > <sig:SignatureGroup> > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:SignatureGroup> > </sig:IdentifiedSignatureGroup> > <sig:IdentifiedSignatureGroup> > <cbc:ID>…</cbc:ID> (ID of cac:InsuranceEndorsement when required) > <sig:SignatureGroup> > <ds:signature>…</ds:signature> > ... > <ds:signature>…</ds:signature> > </sig:SignatureGroup> > </sig:IdentifiedSignatureGroup> > ... > </sig:Signatures> > > Both of the above preserve the rule of "the absence of information does not convey meaning". And since we cannot have choice, we put all of the <sig:SignatureGroup> elements before the <sig:IdentifiedSignatureGroup> elements. > > I can go with either of the above, but I do like that the second example does not mix a foreign namespace with a UBL namespace as siblings, and I like telling implementers that <ds:signature> has only a single parent in UBL. It also reminds UBL users that a set of electronic signatures is applicable to both the entire document or to any identified signature. Someone new to UBL might not realize that a repeating <ds:signature> is allowed for a single signature concept in UBL. > > Actually, I'm talking myself into the second example more and more with that explanation. I don't worry about the amount of scaffolding (the length of the element names or the number of them) ... I'm more worried about what our users need to think about and how to convey the concepts to our users. While <ds:signature> is implicitly repeated, it doesn't convey to the UBL user that the signatures are grouped. > > But does the above grouping have an impact on the XPath address of what is signed and what is not? My thought here is that a signature group is a self-contained set of signatures and that the signatures in the group apply to everything outside of the group. This would limit any group of signatures being closed once another group of signatures has started. > > Or do we simply have an XPath that says anything that is outside of the ancestor <sig:Signatures> is what is signed and everything under <sig:Signatures> is out of bounds? I'm not sure I like that because I might want to sign the document-wide signature with the targeted signatures as part of my signature because I've approved what someone else has approved. > > So, I'm back to making it a workflow issue: once a group of signatures is started, every signature for that group must be added before another group of signatures is started. Then the workflow leaves the document-wide signatures for when all of the other signatures are added, and the document is complete. And the scope of a signature, then, is everything outside of the parent of the <ds:signature> element being created. > > But overriding all, I think, is conveying to the UBL user that there can be many <ds:signature> elements as siblings, all representing the same content being signed. So this promotes the concept of a <sig:SignatureGroup>. > > Tim, what about the ancestor element named <sig:Signatures> ... this isn't a singular noun it is plural. Should it be: > > <sig:SignatureInformation> > > to follow the naming and design rules? > >> For detached signatures I think it's better to avoid any scaffolding other than the standard <ocf:signatures>…</ocf:signatures> container to allow standard packaging. With detached signatures we do not solve all the possible issues but we still have an useful tool for packaging i.e. an invoice, its stylesheet(s), the signature(s) and whatever element we need for a human readable object ready to be archived long term. >> >> Another useful signature field is the Commitment Type. This is an URI that can be defined by the user but it's better to stay with the types already defined in XAdES (and CAdES), i.e.: >> • Proof of origin indicates that the signer recognizes to have created, approved and sent the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfOrigin. >> • Proof of receipt indicates that signer recognizes to have received the content of the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfReceipt. >> • Proof of delivery indicates that the TSP providing that indication has delivered a signed data object in a local store accessible to the recipient of the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfDelivery. >> • Proof of sender indicates that the entity providing that indication has sent the signed data object (but not necessarily created it). The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfSender. >> • Proof of approval indicates that the signer has approved the content of the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfApproval. >> • Proof of creation indicates that the signer has created the signed data object (but not necessarily approved, nor sent it). The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfCreation. >> >> Staying aligned with these definitions allow us to be compatible with CEFACT security project rules. About this point, we can explicitly recommend to comply with the CEFACT recommendation as soon as it is published (this can be done later during the public review of our document, when the CEFACT one will be officially published). >> >> About XAdES itself, it is under standardization in ISO/TC154 as the format for long term signatures for business documents, so it is not limited to Europe. The fact that XAdES, CAdES and PAdES are the only technical implementation in the CEFACT recommendation, even if in a not normative annex, is another reason to sustain its use. > > For detached signatures I agree with doing anything that promotes the reuse of existing approaches. > > Thanks, Andrea! I look forward to your comments on the above. I am delayed this morning from continuing my work because of problems with the main schemas, so I have a few hours today for us to think about this and consider the best names that follow the UBL conventions. > > Tim McGrath is not subscribed to the SecuritySC, so please copy him on your responses. > > . . . . . . . . . . . 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]