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 06:58:07 UTC