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 Friday, 7 June 2002 22:48:51 UTC