OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Discussion issue regarding electronic signatures for BDE

Fellow BDXR TC members,

In working draft 02 of committee specification draft 01 announced this evening on the list you will see that I have proposed putting the XML digital signatures at the end of the document element.

This is in contrast to the approach used in UBL and we have to decide whether to continue the way I've drafted or to use the UBL way.

The formal requirement for UBL digital signatures came after UBL 2.0 was finalized. In order to create a signature environment that works both for UBL 2.1 and UBL 2.0, the common approach was to exploit the document extension point and create extension scaffolding in which to place the digital signature information. Moreover, the <ds:Signature> element is not a CCTS-modeled construct and so thematically it goes into the extension point rather than with the CCTS-modeled children of the document element.

And it works well for both UBL 2.0 and UBL 2.1 ... though I had to write custom UBL-aware code in order to properly inject the signatures. I made that digital signature software freely available here:


But it isn't what I saw in the wild for other XML documents when I was creating the UBL extensions. Apparently, the signature is just tacked on to the end of the XML document (not that I can find the same evidence tonight!). And just tacking the signature at the end requires no knowledge of BDE scaffolding ... another vendor familiar with digital signature software would be able to add a signature at the end of a BDE document with no knowledge of the BDE vocabulary being used. This evening I've made such vocabulary-agnostic digital signature software freely available here (I used this to create the examples in the BDE distribution):


With BDE we are starting from scratch without backward-compatibility issues. And in anticipation of our users, I have modeled an extension point in BDE because we don't know what envelope semantics our users might need that we have not accommodated and so we have provided them a place where they could go. That will still be useful to our users whether or not we choose to put signatures in as extensions.

So ... the issue we have to discuss:

We could choose the UBL approach of using the BDE extension point as a home for digital signatures. This makes our BDE document CCTS-pure, with every child of the document element being CCTS-modeled and non-CCTS signatures under the extension point. But it requires the signature tool to know about BDE in order to create the extension point scaffolding in which to place the signature.

Or we could continue with the approach I've drafted into CSD01WD02 where digital signatures are tacked on the end of the document breaking the "only CCTS rule" for children of the document element. But users may be able to use off-the-shelf signature tools that can tack on signatures to the end of the document element because that software would need know nothing about BDE.

And, to be pedantic, the extension point, itself the first child of the document element, is also not CCTS-modeled. So we'll have two such non-CCTS constructs as children of the document element: an optional first (the extension point) and an optional last (the signature).

What is your opinion on this issue?

Can you please ask your users or colleagues what their opinion is on this issue?

Thank you for your feedback in this regard.

. . . . . . . . Ken

Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/o/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |

This email has been checked for viruses by Avast antivirus software.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]