RE: D-AR006.6 proposal

+1, I can support the new wording with or without 'of origin and receipt',
but prefer it with.

Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572


"Joseph Hui" <Joseph.Hui@exodus.net>@w3.org on 06/10/2002 12:27:21 PM

Sent by:    www-ws-arch-request@w3.org


To:    "Christopher Ferris" <chris.ferris@sun.com>, <www-ws-arch@w3.org>
cc:
Subject:    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
> >>
> >
> >
>
>
>