[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: Sample instances
I agree as well
> 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
>>
>
>
> ---------------------------------------------------------------------
> 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]