RE: D-AR006.6 proposal

I have no objection to adding the "of origin and receipt"
in Chris's proposal.

Joe Hui
Exodus, a Cable & Wireless service
=====================================

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Saturday, June 08, 2002 3: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 Monday, 10 June 2002 12:26:39 UTC