15 messages in org.oasis-open.lists.dssFwd: RE: [dss] Fwd: RE: UPU CPC EPM P...| From | Sent On | Attachments |
|---|---|---|
| Trevor Perrin | Jul 9, 2003 9:59 am | |
| Trevor Perrin | Jul 9, 2003 10:38 am | |
| Trevor Perrin | Jul 9, 2003 7:55 pm | |
| Trevor Perrin | Jul 9, 2003 9:41 pm | |
| Gray Steve | Jul 10, 2003 12:17 am | |
| Nick Pope | Jul 10, 2003 1:49 am | |
| Trevor Perrin | Jul 10, 2003 2:03 am | |
| Trevor Perrin | Jul 10, 2003 2:11 am | |
| Nick Pope | Jul 10, 2003 2:33 am | |
| Trevor Perrin | Jul 10, 2003 9:49 am | |
| Trevor Perrin | Jul 10, 2003 12:07 pm | |
| Trevor Perrin | Jul 10, 2003 2:57 pm | |
| Nick Pope | Jul 11, 2003 1:46 am | |
| Gray Steve | Jul 11, 2003 8:53 am | |
| Trevor Perrin | Jul 11, 2003 11:20 am |
| Subject: | Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS | |
|---|---|---|
| From: | Trevor Perrin (tre...@trevp.net) | |
| Date: | Jul 9, 2003 7:55:25 pm | |
| List: | org.oasis-open.lists.dss | |
Channelling Ed again:
Date: Wed, 09 Jul 2003 22:59:55 -0400 From: Edward Shallow <ed.s...@rogers.com>
Trevor, ( please post to list )
I believe labelling a TimeStamp a Sign does not do the TimeStamp justice and confuses. The verbs are already getting over-loaded, which is why you're stuck. Why the reticence to add new operations. Strictly from a clarity perspective, the world understands cryptographic timestamping in genreal. Just add a TimeStamp operation. You are already into operations stacking ... A place we were at 2 years ago. We simply added options to the primitives that themselves could be primitives. That is why a Verify with a Timestamp option, or a Verify preceded by a Decrypt (I know ... Scope) opertation, or a Sign preceded by a VerifyCertificate (there's one you could add) operation are all viable. I fail to see the need in trying to stick to just a Sign and a Verify. Loosen up, let the use-cases take you were they take you. Much too much constriction so early in the game. Besides, even if you don't do it now, your protocol will be infinetelty more flexible moving forward.
I don't like any of the options. Again, I recommend you add extensible option directives to every primitive. Options themselves can be primitives. Combinations of options and primitives can constitute your profiles. Only in this manner can you truly keep the protocol insulated from the profiles.
Ed
-----Original Message----- From: Trevor Perrin [mailto:tre...@trevp.net] Sent: July 9, 2003 2:45 PM To: Edward Shallow Cc: Gray Steve
At 02:17 PM 7/9/2003 -0400, Edward Shallow wrote:
Are you saying we agree ?
Well, in one respect, at least :-). Lest you think I buy into this whole non-repudiation business..
But I think we'll need to agree to disagree on certain things like that which are simply outside the scope of the protocol. At least, once we agree on what the scope of the protocol is.
To that end, Steve's latest post, and the conversation that results from that, should be helpful.
Bravo ! It sure took a lot of eMails to get to. This is exactly what the Government of Canada is doing.
Any references? I'd be curious to read about it. Are they using EPM External Sign?
More importantly, do you think DSS's Sign operation would satisfy EPM's External Sign needs? Do we need to change our requirements here to accomodate EPM?
I'd still like to produce another requirements draft before the next meeting, so anything on the above you could post to the list would be helpful.
Here's the status of EPM's suggested requirements, as I recall: - You proposed an "Ability to tie multiple business transaction lifecycle events together under a common key", I made a proposal to add this to the Requirements, I haven't heard back - http://lists.oasis-open.org/archives/dss/200307/msg00021.html - In the same mail I pushed back on many other things you suggested, as a matter of scope, and I guess we're still discussing that. - EPM's Verify/ApplyPostmark poses a unique challenge for DSS, since it combines both our Verify and Signing operations. It's a very interesting use case, and I'm glad you guys have contributed it. Here's my latest proposal for handling this - http://lists.oasis-open.org/archives/dss/200307/msg00045.html
Other things you want to suggest?
An enormous endevor which put it at the top of the eGovernment heap. However, this still recludes gernerally available Web Service offerings which espouse to sign on your behalf and still be legally binding. This we cannot condone.
To my way of thinking, whether a service is: - "generally available", or available only within an organization, and - legally binding or non-legally-binding
are issues outside the scope of the protocol. You could take a service that implements the protocol and run it inside a corporation or outside. You could move it from one legal regime to another.
The code for the server, and thus the protocol it implements, would not change in the slightest. Yet in some cases it would be "generally available", in some cases it wouldn't, in some cases it would be "legally binding", in some cases it wouldn't.
My point is, these questions of who runs the service, and what legal guarantees it provides, are issues of deployment and of the legal/business context DSS is being deployed within. DSS should concern itself only with sending a document and getting back a signed document, and let other people like EPM design "whole systems" that tackle these issues, and which will incorporate DSS as only a small part.
Trevor