- From: Steven A. Monetti <smonetti@att.com>
- Date: Mon, 10 Jun 2002 08:43:50 -0400
- To: "Joseph Hui" <Joseph.Hui@exodus.net>, <chris.ferris@sun.com>
- Cc: <www-ws-arch@w3.org>
+1 for the proposal: "The security framework SHOULD support Non-repudiation between transacting parties." steve -----Original Message----- From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On Behalf Of Joseph Hui Sent: Friday, June 07, 2002 10:49 PM To: chris.ferris@sun.com Cc: www-ws-arch@w3.org Subject: Re: D-AR006.6 proposal I'm inclined to suggest we either fish or cut bait: NR or no NR, because relocating NR to the business goals section is unlikely to change the cause for the "non-closure," which I surmise is to large extent the trepidation that if we take on NR, we may not see the end of it. If we must stake out an NR requirement in the doc, then perhaps we could downgrade the "must" in the current goal to "SHOULD" and maybe even tag a "wherever feasible" safety clause at the end of the statement, lest we over-extend ourselves. While at it, we may also change the word "include" to "support" so it reads like: "The security framework SHOULD support Non-repudiation between transacting parties [wherever feasible]." With the intro paragraph for the six security aspects under D-AR006.1 thru D-AR006.6 removed per previous consensus, I think "support" reads better than "include" does. As for seeing NR as a business function, it may well be true; but it's the security stuff that makes NR tick! Come to think of it, if NR were under D-AC017 now, strong arguments could be made to relocate it back to security: the implementation of NR needs digital signature, which is a security primitive; it also needs a public key infrastructure, which is also a security thing; some implementations may even employ challenge-response procedures to authenticate signers (i.e. to reasonably ensure the signer is not using a stolen private key), which is yet another security gig; ... That is, on the balance, security pertinent issues are very likely to outweigh the non-security ones at the end of the day, so far as NR in web services is concerned. Cheers, Joe Hui Exodus, a Cable & Wireless service =================================================== > -----Original Message----- > Date: Thu, 06 Jun 2002 10:04:27 -0400 > From: Christopher Ferris <chris.ferris@sun.com> > To: wsawg public <www-ws-arch@w3.org> > Subject: D-AR006.6 proposal > > > D-AR006.6 reads: > The security framework must include Non-repudiation > between transacting parties. > > This one hasn't been discussed much lately (much of the > discussion around NR was focused on the authentication of > data D-AR006.2.2) but it occured to me that maybe by relocating > this item to the business goals (D-AC017) section, that > we might be able to come to closure on this. > > My understanding of NR is that it is a business function, not a > security function. NR may leverage security mechanisms, but it isn't > part of a security framework (again, IMO). Clearly, NR places > specific requirements on the technologies, policies and processes > that enable it. > > I would propose that we relocate D-AR006.6 under D-AC017 > and rephrase it something like: > > "The Web Services Architecture must support(enable?) > non-repudiation > of both origin and receipt between transacting parties" > > Comments? > > Cheers, > > Chris >
Received on Monday, 10 June 2002 08:41:52 UTC