Next in thread → Next in month →

RE: [ubl] The business case for signatures - is it really there?

From
"Lama, Lamarudin Cin Sambi"
Date
2005-12-13T09:05:40+00:00
ID
Thread
RE: [ubl] The business case for signatures - is it really there?
Hi Mikkel,
The requirement from the UBL TSC is for the Certificate of Origin document to be digitally signed. We have been in discussion with Peter on this. See attached.

As for the business case from a real domain, well CrimsonLogic has implemented the world's first Electronic Certificate of Origin system. It involves multi-party approval workflow. The CoO document is signed by the exporter signatory party, followed by chamber, embassy and possibly insurance party.

The UBL TSC has actually included the Peter's proposed SignatureReference ASBIE in the CoO document to ensure that we align other group's work into our work.

If there is any changes to that, please keep us updated. We are targeting to submit our work to UBL TC on the week of 26 Dec 05.

Regards
Kama
UBL TSC Chair

-----Original Message-----
From: Mikkel Hippe Brun [mailto:] 
Sent: Tuesday, December 13, 2005 3:44 PM
To: ''
Subject: [ubl] The business case for signatures - is it really there?

Dear all,

A signature class is now being proposed to be a part of all UBL documents.

The following business case for this class has been explained to me: Prior
to the exchange of a UBL document, authorized persons may have been required
to digitally approve internal process steps. For an electronic order this
could be the flow:

1. An employee in Big Inc. (Mrs. Imonitorstock) discovers that the stock of
pencils is critically low and sends a request to the purchasing department.
This request is digitally signed.
2. An employee (Mr. Underdog) in the purchasing department creates an Order
and sends it to his boss Mr. Imakethedecision. The signature part of the
Order contains metadata about the signature applied by Mrs. Imonitorstock.
The order is off course signed by Mr. Underdog.
3. Mr. Imakethedecision verifies the signature applied by the order by Mr.
Underdog, adds another ten pencils to the order. The signature metadata of
Mr. Underdog is added to the order and the order is digitally signed by Mr.
Imakethedecision and sent to the supplier.

The above example demonstrates that the signature part proposed to all UBL
messages contains information about previous signatures and approvals
involved in the internal workflow of the organization sending a message. It
is not an attempt to store metadata about the signature applied to the
message on its way from sender to receiver. (This would off course also be
impossible unless you only signed a subset of the document).

The need for the Signature class has come up in the Transport group and
probably for a good reason. I propose that we do not add the Signature class
to documents where we have not seen a strong business case from a real
domain. Academic arguments stating that it would be "nice to have" do not
carry the same weight.

Let's keep UBL on the 80/20 track.

- mikkel

Mikkel Hippe Brun 
Chief Consultant, M.Sc. 
Phone: +45 3337 9220 
Cell: +45 2567 4252 
E-mail:  

National IT and Telecom Agency 
Office of IT Strategy 
Holsteinsgade 63 
DK-2100 Copenhagen Ø 
Denmark 
Phone: +45  3545 0000 
Fax: +45 3545 0010 
www.itst.dk 
 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread → Next in month →