RE: Non-Repudiation - A Lower Level?

I didn't quite understand this.  Maybe I should ask the obvious:  Exactly
what is auditing?  If it is simply making lists of what has happened that
can be viewed later, I don't think that's exactly what is required here.  As
I think is illustrated in the first message in this thread, what you need is
the ability to generate a "convincing" (but not necessarily completely
legally invulnerable) display that shows something like:
 
1 - Here is the message we sent on Mar 23.  It has the following envelope
and contains the following data.
2 - Here is your confirmation that you received the message on Mar 23, and
it is clear that your confirmation refers to the same message as displayed
in step 1 and that the confirmation actually came from you.
 
When I say "not necessarily completely legally invulnerable" I guess I mean
that it is not necessary to be able to prove that it is absolutely
impossible that the displays discussed above were forged by some criminal
with huge computing resources.  It probably is necessary, however, for the
demonstration to be pretty convincing.  That is, the person who receives the
demonstration should be able to look at it and say something like, "Yup,
that's our signature all right, and because this number on the confirmation
is the same as that number on the original message, I can see that the
confirmation really does refer to that message".
 
One other thing.  I suppose that if you had various auditing listings one
could say something like, "OK, if you compare this list to that list and
cross-reference this other list, you will find that ..."  Maybe there is
some sort of complex process like that -- but you need a way to make a
SIMPLE, convincing display -- because these goofups happen ALL THE TIME!
 
-----Original Message-----
From: Edgar, Gerald [mailto:gerald.edgar@boeing.com] 
Sent: Monday, May 20, 2002 12:24 PM
To: 'Krishna Sankar'; www-ws-arch@w3.org; 'Cutler, Roger (RogerCutler)'
Subject: RE: Non-Repudiation - A Lower Level?


Krishna - What Rodger was discussing is more than auditing. There needs to
be a mechanism, not only to track (as in auditing) but to require a process
that has some controls over it to provide the business some assurance that a
request was not made by accident. This would be similar to simply signing a
document. Below a certain dollar amount of transaction, there is no need for
third party overview for non-repudiation. Mutually agreed business
relationships between companies would able them to use web services, as long
as there is the technical means to verify the origin of the request. Without
some means for conscious (process by people or system by design) notation
that a request was made, we not not have anything that would enable common
business processes to operate using web services.
 
I am not sure I articulated this very well, but I think you get the idea.

Gerald W. Edgar <Gerald.Edgar@Boeing.com>
Architecture support, BCA Architecture and e-business
425-234-1422

Mailing address:
The Boeing Company, M/S 6H-WW
PO Box 3707, Seattle, WA 98124-2207
USA

  

-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Sunday, May 19, 2002 18:10
To: www-ws-arch@w3.org
Subject: RE: Non-Repudiation - A Lower Level?


Roger,
 
    What you are articulating is auditing and I think it is in scope of
security. But auditing to support (legal) non-repudiation is not. Also
auditing for IDS purposes is also in scope of security.
 
cheers

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Cutler, Roger (RogerCutler)
Sent: Saturday, May 18, 2002 8:54 AM
To: www-ws-arch@w3.org
Subject: Non-Repudiation - A Lower Level?



The last con call had some discussion of non-repudiation in which Joe
emphasized that non-repudiation is about convincing a third party that
something happened involving the two direct participants in a transaction,
and others talked about the legal aspects -- such as problems guaranteeing
legal validity over a seven year period in the face of evolving technology.
And a rather complete discussion of non-repudiation has been posted but for
some reason I don't seem to be able to find it at the moment.  (Sigh.)

I would like to suggest a different understanding of non-repudiation that I
think is useful in a lot of business cases.  In fact, beyond "useful" to
"crucial".  Perhaps it is confusing to call it the same thing, but I don't
know what else to name it. Quoting from the EDI-like usage case I am
drafting, 

	Non-Repudiation is of particular importance, although in practical
terms less in terms of a legal process than simply the ability to say, "You
got this invoice on March 24, and here is your signed confirmation of
receipt".  That is, by far the most common scenarios that require
non-repudiation involve people in both companies trying, in good faith, to
sort out what has gone wrong in some screwed up transaction.  What is
required in these cases is an unambiguous record, not rock-solid legal
proof.  Taking these issues to court is a very rare occurrence given an
ongoing trading relationship between businesses. 

I believe that it is fair to say that in practical, EDI-like transactions
this sort of "unambiguos record" doesn't just satisfy the 80-20 but more
like the 99.9.  There is NO WAY that any technology or standards are going
to prevent screwups and confusion in business transactions, which in
practice happen all the time.  "You didn't pay us."  "Yes we did."  Or "We
ordered this but didn't receive it."  There are a bazilion things that can
go wrong which have nothing whatsoever to do with the web services or
business protocols, and have nothing to do with anybody taking anything to
court.

Now one might well say, "Well, if one satisfies the more rigorous, legally
motivated requirements of non-repudiation, one also satisfies this lower
level requirement".  That's OK, but what I am concerned about is that the
higher level of non-repudiation may be difficult to achieve.  I believe that
there is a genuine and immediate need for the sort of non-repudiation
described above, and perhaps it could be useful to get quickly to such an
understanding.

Or am I perhaps talking about what some people are calling "auditing"?  I'm
afraid I have not been entirely clear what people have meant by that.  Am I
really asking for clarification of terminology rather than a different
understanding of requirements?