- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Mon, 20 May 2002 17:23:03 -0600
- To: www-ws-arch@w3.org
- Message-ID: <9A4FC925410C024792B85198DF1E97E4032B8F4D@usmsg03.sagus.com>
-----Original Message----- From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com] Sent: Monday, May 20, 2002 6:16 PM To: 'Champion, Mike'; www-ws-arch@w3.org Subject: RE: Non-Repudiation - A Lower Level? If there is a need for web services standards for non-repudiation (in the looser sense in which I am using the term) or auditing (perhaps in a stricter sense than the term is often used?) so that such applications can interoperate, then shouldn't that be part of the web services architecture we define? As I see it, there is a strong requirement that the web services architecture define the pieces that would implement "non repudiation" in the weak sense that there is an audit trail that either an application or some humans can use to resolve issues such as "you didn't pay" "yes we did." I was objecting to getting down to the details, e.g. "Below a certain dollar amount of transaction, there is no need for third party overview for non-repudiation." I see that as the job of some vertical industry standards group, or maybe some business process standards such as ebXML, but not the web services infrastructure. I have no STRONG objections if others want to put this sort of thing in our requirements, but I fear that we will be bogged down in details and never produce anything if we require ourselves to define everything.
Received on Monday, 20 May 2002 19:23:37 UTC