FW: EPM postmark

[Gray Steve <steve.gray@upu.int>]

 

-----Original Message-----
From: Ed Shallow [mailto:edwardshallow@yahoo.ca]
Sent: Thursday, July 03, 2003 6:08 PM
To: Trevor Perrin; Edward Shallow; 'Gray Steve'; dss@lists.oasis-open.org
Cc: roger.mccune@canadapost.ca
Subject: RE: EPM postmark

Thanks for focusing the question for me.

 

Please post to the list on my behalf ...

 

Here goes ...

 

The comment you quoted in the WSDL referred to the "old" "VerifyPostMark" SOAP verb which was replaced with a cleaner "Verify" verb with the newly introduced "ApplyPostMark" option. This was just an evolution of the WSDL SOAP EPM protocol to something more flexible and straighforward.

 

That is all that the comment was highlighting. Both old and new verbs produce a totally standard RFC3161-compliant timestamp token.

 

Now about the added meaning ...

 

Having said that, an EPM (or DSS) implementation can state whatever it wants to with respect to the contractual binding of signer identity to data to time to terms and conditions. This is accomplished through the use of a SignaturePolicy document (ref ETSI 101 733/903 and RFC3126). This SignaturePolicy document can express whatever the service provider deems is appropriate for their service. Again I invite you to consult the OASIS references to the ETSI work in this area. Please follow link below to both the XAdES standards as well as the newer XML-based SigaturePolicy standards.

 

http://xml.coverpages.org/ni2002-04-24-a.html    

 

The CommitmentRules within the SignaturePolicy document whose hash, also, and ID is placed into a conforming signature can express all sorts of rules which both parties agree to abide by.

 

In the Postal case, we just decided to have the ApplyPostMark on a Verify represent attestation of successfull verification. An implementor can do whatever they want under the SignaturePolicy model.

 

Nothing is non-standard about that.

 

Again, what is DSS proposing to address that is not already addressed by the existing body of standards in the digital (electronic) signature space ?

 

On another note, where I see DSS departing from mainstream, I would like to draw your attention to the hotly contested topic of "delegated signing". The stringent requirements surrounding the "signing ceremony" in a non-repudiation setting immediately preclude any delegation if one is attempting any sort of binding comitment. I believe the scope and intent of "delegated signing" to a DSS Web Service has to be revised or at least clarified in terms of scope, objectives, and intent. In non-repudiation circles, this is taboo. One cannot achieve things: like 2-factor authentication, what-you-see-is-what-you-sign, mutually accepted time, and signing intent (i.e. context) in the delegated model. The ability to repudiate a signature created without the signator's active involvement would be simple, and therefore non-binding. 

 

What is the ultimate objective of "delegated signing". If it is solely to eliminate the need for client-side certificates, this is not an objective. Certianly not in a non-repudiation setting. Is non-repudiation in or out of DSS's scope ?

 

The EPM can address this requirement very simply with its Lifecycle support. Consider this scenario which utilizes nothing special.

 

1) As the first event in a new EPM Lifecycle with a specific TransactionKey or Identifier, Alice of sound mind signs a "Power of Attorney" allowing Bob to sign on her behalf. The Sign of this document is "Verified" by the EPM and optionally PostMarked and logged as the first event in this Lifecycle.

 

2) Given that Alice and Bob have clearly participated in the above, Alice invites Bob to pickup the signed "Power of Attorney" and countersign it. Bob does that using the same TransactionKey that Alice used. This represents the 2nd event in this lifecycle.

 

3) With the first 2 events out of the way, Bob commences electronic activities involving the use of Alice's "Power of Attorney" and clearly states his intent as that "Power of Attorney" using the "intent phrase" and/or SignaturePolicy facilites within the EPM.

 

4) Bob closes out this particular lifecycle thus concluding this clearly "contexted" sequence of delegated signing events. All this is peformed with starightforward Sign and Verify actions that have been tied together under the auspices of an EPM Transaction Lifecycle.   

 

We asked that things like Lifecycle be considered in the DSS requirements document. We have not heard back as yet.

 

I must now ask you to help me, because I am getting confused with DSS's intent, objectives, and scope in the following areas:

 

- how is DSS different than existing published standards in this area, most notably ETSI 101-733/903 ?

 

- is non-repudiation within the scope of DSS ?

 

- is there any binding assumptions about the signatures produced by a DSS service ?

 

- how does DSS propose to extend value to the Web Service subscriber community ?

 

Ed 

Trevor Perrin <trevp@trevp.net> wrote:

 

---

Post your free ad now! Yahoo! Canada 
Personals