RE: D-AR006.6 proposal

Sounds good to me.  I think we would be remiss to ignore NR entirely, and I
think that everything Joe says below makes good sense.  It seems to me that
although there may be a component of NR that is logically in "business
function", putting it there entirely might send a message to some that we
think it's outside W3C scope, which I don't think would be good.
  
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com] 
Sent: Saturday, June 08, 2002 5: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 13:05:15 UTC