- From: Dilber, Ayse, ALASO <adilber@att.com>
- Date: Sat, 8 Jun 2002 16:00:03 -0400
- To: "Christopher Ferris" <chris.ferris@sun.com>, <www-ws-arch@w3.org>
Although I registered and bought my ticket to join the meeting next week, due to a family emergency I will not be able to attend. Ayse -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@sun.com] Sent: Saturday, June 08, 2002 6:55 AM To: www-ws-arch@w3.org Subject: Re: D-AR006.6 proposal Alrighty then:) What do others think about Joe's counter-proposal which is effectively; leave D-AR006.6 where it is (under D-AC006) and change it to read: D-AR006.6 The security framework SHOULD support Non-repudiation between transacting parties I could also see replacing "support" with "enable" since that's the meaning of "support" that I think we mean in this context. I could also see adding in the "of origin and receipt" as in my previous proposal (see below). Comments? Cheers, Chris Joseph Hui wrote: > 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 Saturday, 8 June 2002 16:00:46 UTC