Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS

[Trevor Perrin <trevp@trevp.net>]

Channelling Ed again:

>Date: Wed, 09 Jul 2003 22:59:55 -0400
>From: Edward Shallow <ed.shallow@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:trevp@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