RE: D-AG006 Security : Proposal for a task force for writing the Security WG Charter

RE: D-AG006 Security : Proposal for a task force for writing the Security WG
CharterYes, I agree we should develop a charter for a security WG, based on
the outline of topics in one of David's emails:

- specify a trust model for end to end security
> - authentication - some issue about which types of authn
> - message integrity - some issues about whether just soap or
> attachments
> - confidentiality.
>

The major categories of security work, AFIK are integrity/confidentiality,
represented by various forms of encryption and signature verification, and
authentication/authorization, which controls the identity of those accessing
resources.

I'm not sure we need more than a few simple statements to define the work.
The rest is probably W3C boilerplate.

Eric
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Abbie Barbir
  Sent: Tuesday, May 07, 2002 4:38 PM
  To: David Orchard; 'Dilber, Ayse, ALASO'; 'Joseph Hui'; 'Edgar, Gerald';
'Allen Brown'
  Cc: www-ws-arch@w3.org
  Subject: RE: D-AG006 Security : Proposal for a task force for writing the
Security WG Charter


  David,

  the secenario/req is the way to start.

  however, i still think we need the task force ASAP. Otherwise, u will
resend the same e-mail back to the list in two month stating why we still do
not have a charter for the security WG. (So, here I am saving you the
frustration.)

  abbie



  -----Original Message-----
  From: David Orchard [mailto:dorchard@bea.com]
  Sent: Tuesday, May 07, 2002 4:28 PM
  To: 'Dilber, Ayse, ALASO'; Barbir, Abbie [CAR:1A00:EXCH]; 'Joseph Hui';
  'Edgar, Gerald'; 'Allen Brown'
  Cc: www-ws-arch@w3.org
  Subject: RE: D-AG006 Security : Proposal for a task force for writing
  the Security WG Charter



  I'd like to suggest the following approach:

  1. Review the usage scenarios and requirements, and suggest
  additions/changes or +1 them.  Of course remembering that we want to hit
an
  80/20 point.

  2. We separately start creating charter template.  Once we agree upon #1,
  then we copy the requirements in.

  So imo we don't really need a separate task force yet, we just need to do
  the work of reviewing the scenarios and reqs.  I'd like to suggest that we
  discuss the usage scenarios and requirements, and if the traffic gets too
  high, then we can split into a task force.

  Cheers,
  Dave

  > -----Original Message-----
  > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
  > Behalf Of Dilber, Ayse, ALASO
  > Sent: Tuesday, May 07, 2002 1:06 PM
  > To: Abbie Barbir; David Orchard; Joseph Hui; Edgar, Gerald;
  > Allen Brown
  > Cc: www-ws-arch@w3.org
  > Subject: RE: D-AG006 Security : Proposal for a task force for writing
  > the Security WG Charter
  >
  >
  > I will work with you to write the charter.
  > Ayse
  >
  > -----Original Message-----
  > From: Abbie Barbir [mailto:abbieb@nortelnetworks.com]
  > Sent: Tuesday, May 07, 2002 4:00 PM
  > To: David Orchard; Dilber, Ayse, ALASO; 'Joseph Hui'; 'Edgar,
  > Gerald'; 'Allen Brown'
  > Cc: www-ws-arch@w3.org
  > Subject: RE: D-AG006 Security : Proposal for a task force for
  > writing the Security WG Charter
  >
  >
  >
  >
  > David, chris,
  >
  > I agree with you, we should write the charter in a month or so.
  >
  > Here, I propose to start a task group that could do that.
  >
  > Chris,
  >
  > can we have a task force that write the charter for the Security WG.
  > I do volunteer to be the editor for that activity.
  >
  > abbie
  >
  >
  > -----Original Message-----
  > From: David Orchard [ mailto:dorchard@bea.com]
  > Sent: Tuesday, May 07, 2002 3:46 PM
  > To: 'Dilber, Ayse, ALASO'; 'Joseph Hui'; 'Edgar, Gerald';
  > Barbir, Abbie
  > [CAR:1A00:EXCH]; 'Allen Brown'
  > Cc: www-ws-arch@w3.org
  > Subject: RE: D-AG006 Security
  >
  >
  > I think there's some irony that almost 100% of the group
  > knows or agrees
  > that we will have a web services security working group, that
  > it's perhaps
  > our highest priority, but yet we can't quite seem to bash
  > through some
  > details and kick out a charter.
  >
  > I seriously think if we said something like:
  >
  > - specify a trust model for end to end security
  > - authentication - some issue about which types of authn
  > - message integrity - some issues about whether just soap or
  > attachments
  > - confidentiality.
  >
  > About 75% of the working group would roughly agree.  We
  > actually understand
  > these usage scnarios pretty well.  The usage scenarios lists,
  > though don't
  > go into detail, these scenarios with a priority of high.
  >
  > Reality is, I think we could write a charter for that WG in
  > very short
  > order.  Heck, we could probably have a charter in front of
  > the WSACG in less
  > than a month on this with some focus.
  >
  > Our methodology all along is that we ought to focus on a few
  > WGs, including
  > security, and kick them off as quickly as possible.
  >
  > I am fully prepared to do whatever work is necessary to
  > expedite this.
  >
  > Cheers,
  > Dave
  >
  > > -----Original Message-----
  > > From: www-ws-arch-request@w3.org

  > mailto:www-ws-arch-request@w3.org]On
  > > Behalf Of Dilber, Ayse, ALASO
  > > Sent: Tuesday, May 07, 2002 12:10 PM
  > > To: Joseph Hui; Edgar, Gerald; Abbie Barbir; Allen Brown;
  > > David Orchard
  > > Cc: www-ws-arch@w3.org
  > > Subject: RE: D-AG006 Security
  > >
  > >
  > > to have a separate WG to deal with security issues.
  > > ayse
  > >
  > > -----Original Message-----
  > > From: Joseph Hui [ mailto:Joseph.Hui@exodus.net]
  > > Sent: Tuesday, May 07, 2002 2:55 PM
  > > To: Dilber, Ayse, ALASO; Edgar, Gerald; Abbie Barbir; Allen
  > > Brown; David
  > > Orchard
  > > Cc: www-ws-arch@w3.org
  > > Subject: RE: D-AG006 Security
  > >
  > >
  > > What exactly is the proposal here?
  > >
  > > Joe Hui
  > > Exodus, a Cable & Wireless service
  > > =============================================
  > >
  > > > -----Original Message-----
  > > > From: Dilber, Ayse, ALASO [ mailto:adilber@att.com]
  > > > Sent: Monday, May 06, 2002 8:57 AM
  > > > To: Edgar, Gerald; Abbie Barbir; Allen Brown; David Orchard
  > > > Cc: www-ws-arch@w3.org
  > > > Subject: RE: D-AG006 Security
  > > >
  > > >
  > > > i support this proposal.
  > > > Ayse
  > > >
  > > > -----Original Message-----
  > > > From: Edgar, Gerald [ mailto:gerald.edgar@boeing.com]
  > > > Sent: Monday, May 06, 2002 11:49 AM
  > > > To: 'Abbie Barbir'; Allen Brown; David Orchard
  > > > Cc: www-ws-arch@w3.org
  > > > Subject: RE: D-AG006 Security
  > > >
  > > >
  > > > I second this...
  > > >
  > > >
  > > > Gerald W. Edgar <Gerald.Edgar@Boeing.com>
  > > > Architecture support, BCA Architecture and e-business
  > > > 425-234-1422
  > > >
  > > > Mailing address:
  > > > The Boeing Company, M/S 6H-WW
  > > > PO Box 3707, Seattle, WA 98124-2207
  > > > USA
  > > >
  > > >
  > > >
  > > > -----Original Message-----
  > > > From: Abbie Barbir [ mailto:abbieb@nortelnetworks.com]
  > > > Sent: Friday, March 15, 2002 6:29
  > > > To: Allen Brown; David Orchard
  > > > Cc: www-ws-arch@w3.org
  > > > Subject: RE: D-AG006 Security
  > > >
  > > >
  > > >
  > > > Allen,
  > > >
  > > > i do second your remark.
  > > > The discussion on security clearly indicate that there is the
  > > > need for having a WG that sepcifically deals with the subject.
  > > >
  > > > I think that the birth of the security group should come out
  > > > as a result of the WG work.
  > > >
  > > > abbie
  > > >
  > > >
  > > > > -----Original Message-----
  > > > > From: Allen Brown [ mailto:allenbr@microsoft.com]
  > > > > Sent: Thursday, March 14, 2002 3:10 PM
  > > > > To: David Orchard
  > > > > Cc: www-ws-arch@w3.org
  > > > > Subject: RE: D-AG006 Security
  > > > >
  > > > >
  > > > > Dave,
  > > > >
  > > > > Indeed, this is exactly the sort of thread I'd expect to
  > > evolve in
  > > > > chartering, setting goals for, and setting requirements
  > for a Web
  > > > > Services Security WG.
  > > > >
  > > > > I'd add to your qualitative facets of security: supporting
  > > > end-to-end
  > > > > security for both seeking and providing Web Services.
  > > > >
  > > > > Allen
  > > > >
  > > > > -----Original Message-----
  > > > > From: David Orchard [ mailto:david.orchard@bea.com]
  > > > > Sent: Monday, March 11, 2002 1:52 PM
  > > > > To: www-ws-arch@w3.org
  > > > > Subject: RE: D-AG006 Security
  > > > >
  > > > >
  > > > > This discussion is getting into requirements, WSA process,
  > > > artifacts,
  > > > > etc. and not goals.
  > > > >
  > > > > Why not keep the security goals pretty simple, like listing
  > > > > the typical
  > > > > facets of authentication, authorization, etc?  And say that
  > > > > the security
  > > > > facets apply to web service message exchange, interface
  > > > definition and
  > > > > discovery?
  > > > >
  > > > > Remember, goals not requirements.
  > > > >
  > > > > Cheers,
  > > > > Dave
  > > > >
  > > > >
  > > > >
  > > > > > -----Original Message-----
  > > > > > From: www-ws-arch-request@w3.org
  > > > > [ mailto:www-ws-arch-request@w3.org]On
  > > > > > Behalf Of Joseph Hui
  > > > > > Sent: Monday, March 11, 2002 11:04 AM
  > > > > > To: Damodaran, Suresh; www-ws-arch@w3.org
  > > > > > Subject: RE: D-AG006 Security
  > > > > >
  > > > > >
  > > > > > Hi Suresh,
  > > > > >
  > > > > > So there's the apparent agreement that listing use cases
  > > > > exhaustively
  > > > > > is not the way to go, i.e. a few well thought-out
  > > > examples will do.
  > > > > >
  > > > > > In my view the system boundaries may indeed vary between
  > > > > applications.
  > > > >
  > > > > > In fact, in some cases, say XML-Encryption, the notion
  > > of system
  > > > > > boundaries in the tradition sense is immaterial, and may
  > > > > even get in
  > > > > > the way.  Perhaps in WSsec the notion of "system
  > > > > boundaries" should be
  > > > >
  > > > > > re-invented to be "security boundaries," which will
  > enclose the
  > > > > > security policies of the union of (the sets) of
  > > security policies
  > > > > > of all WS endpoints involved in a transaction.  Note that
  > > > > > in WSsec each WS endpoint can have its own security policy.
  > > > > >
  > > > > > I agree we should indeed try not to delve into too
  > much detail,
  > > > > > especially mechanisms -- none at all if possible at this
  > > > > juncture.  So
  > > > >
  > > > > > we can stay focused on our more immediate objectives.
  > > > > >
  > > > > > For the long term, there's a set of steps I'm thinking of
  > > > > > to approach this WSsec deal methodically:
  > > > > >   1) develop a WS-Arch security policy -- the policy
  > > > > >      of all policies (of all WS endpoints);
  > > > > >   2) develop a model that captures the policy;
  > > > > >   3) translate the model into WS architectural elements,
  > > > > >      aka "modules" in WSAWA charter's nomenclature; and
  > > > > >   4) implement the modules with mechanisms.  (Note that
  > > > > >      a WS endpoint only needs to implement/deploy a subset
  > > > > >      of the modules according to its own security
  > > > policy.) (Steps 1
  > > > > > through 3 are the WSAWG's gig.  Step 4 will be left to the
  > > > > > implementers/vendors.) Does this sound reasonable to you?
  > > > > And to the
  > > > > > group?
  > > > > >
  > > > > > BTW, do you find the D-AG006 goal statement as-is
  > > > > acceptable? (I do,
  > > > > > BTW.)  Care to share any thoughts on it?
  > > > > >
  > > > > > Cheers,
  > > > > >
  > > > > > Joe
  > > > > > =================
  > > > > > > -----Original Message-----
  > > > > > > From: Damodaran, Suresh
  >
  > > mailto:Suresh_Damodaran@stercomm.com]
  > > > > > > Sent: Monday, March 11, 2002 9:12 AM
  > > > > > > To: Joseph Hui; www-ws-arch@w3.org
  > > > > > > Subject: RE: D-AG006 Security
  > > > > > >
  > > > > > >
  > > > > > >
  > > > > > > Joseph,
  > > > > > >
  > > > > > > More comments below.
  > > > > > > I have some additional thoughts that I will send
  > > > separately, when
  > > > > > > ready. This is a hard topic, and it is a challenge for us
  > > > > to get the
  > > > >
  > > > > > > right "stuff" done for the WS-Sec
  > > > > > >
  > > > > > > -----Original Message-----
  > > > > > > From: Joseph Hui [ mailto:jhui@digisle.net]
  > > > > > > Sent: Friday, March 08, 2002 8:11 PM
  > > > > > > To: Damodaran, Suresh; www-ws-arch@w3.org
  > > > > > > Subject: RE: D-AG006 Security
  > > > > > >
  > > > > > >
  > > > > > > > -----Original Message-----
  > > > > > > > From: Damodaran, Suresh
  >
  > > > mailto:Suresh_Damodaran@stercomm.com]
  > > > > > > [snip]
  > > > > > > > 2. You have described the techniques one may use
  > to secure
  > > > > > > > *any* web service usage scenario. It would be
  > useful to see
  > > > > > > > whether there are categories of usage scenarios
  > where some
  > > > > > > > specific combination of techniques will make sense. For
  > > > > example,
  > > > > > > > should accessing a "weather info service," be
  > secured using
  > > > > > > > authorization, authentication? Should the
  > > > > > > > weather info be ensured to be authentic and unaltered?
  > > > > > > Whether should or should not depends on the weather info
  > > > > > > WS provider and consumer.  It'll be their choice.
  > > > > > > We should only concern ourselves with the "can" factor
  > > > -- can our
  > > > > > > WSsec ensure the weather info to be authentic and
  > > > unaltered?  By
  > > > > > > obligating ourselves to address authc, authz, and
  > > > > integrity, we can
  > > > > > > say: "yes, the WS-Arch can." Just to ensure potential
  > > > > skeptics who
  > > > > > > may think the "can" is easier said then done, I'm
  > > > giving concrete
  > > > > > > answers to your two questions, replacing "should"
  > with "can".
  > > > > > > For the first Q, the provider needs to keep an ACL,
  > then the
  > > > > > > two can either use Kerberos or SSL/TLS with client
  > > > > > > authentication to take care of the Authz part.  For
  > > > > > > the Auchc part, use HMAC.
  > > > > > > For the second Q, HMAC will also do nicely.
  > > > > > >
  > > > > > > <sd>
  > > > > > > I agree with "can" part. We might document this
  > > thought in the
  > > > > > > proposal for clarification. Indeed, my suggestion for
  > > > > categorization
  > > > > > > was to lead to a "proof" that WSA cannot foresee
  > all possible
  > > > > > > scenarios, and would possibly have to limit to suggesting
  > > > > > > "toolkit standards" (i.e., standards that are applicable
  > > > > > > for generic techniques, say signing). Is this an agreeable
  > > > > > > thought to all? One possible class of exceptions to this
  > > > > > > rule is a set of combinations of techniques that are
  > > > > > > widely useful in the applications that use WS-Arch.
  > > > > > > E.g., Ensuring confidentiality and integrity of
  > > > > > > a message send from point-to-point (i.e., when there is no
  > > > > > > intermediary),
  > > > > > > WSSec may suggest signing/encryption sequence with
  > > appropriate
  > > > > > > security considerations. At this time, I am not even
  > > > > > > sure we need to get to this level. Others might have
  > > > some opinions
  > > > > > > on this, especially since different application
  > > > > > > domains/products may choose
  > > > > > > to do these differently.
  > > > > > > </sd>
  > > > > > >
  > > > > > > > Same questions for sending in a bill payment to a
  > > bank from a
  > > > > > > > customer. If there are many categories, then we may
  > > > see how to
  > > > > > > > satisfy all of them in a generic way. Alternately, we
  > > > > may suggest
  > > > > > > > techniques that may be generically adopted.
  > > > > > >
  > > > > > > The use case list doesn't have to be exhaustive.
  > > > > > > We only need exemplary cases to show the need for
  > > > addressing the
  > > > > > > security concerns being brought forward. Hopefully
  > > > > someone on this
  > > > > > > mailing list would pitch in some as we progress.
  > > Regardless, I
  > > > > > > believe limited empirical input will not stop us from
  > > > > coming up with
  > > > > > > a well designd WSsec.
  > > > > > >
  > > > > > > <sd>
  > > > > > > As you would agree, given the combinations possible,
  > > keeping an
  > > > > > > exhaustive use case list will be pretty hard, if not
  > > > > theoretically
  > > > > > > impossible. The hard part is in showing that the use
  > > > > cases we have
  > > > > > > are sufficient. </sd>
  > > > > > >
  > > > > > > > 3. It would be good to define the "end points" of
  > whatever
  > > > > > > > scenarios we are securing. What are the boundaries of
  > > > > whatever we
  > > > > > > > are securing?
  > > > > > >
  > > > > > > Indeed.  I believe there are well established
  > definitions in
  > > > > > > existence.  We just have to scrounge for them going
  > > > forward. The
  > > > > > > endpoint has to be understood to be the WS provider and
  > > > > consumer.
  > > > > > > (There can be intermediaries, of course, which complicate
  > > > > to great
  > > > > > > extent the end-to-end argument that most security models
  > > > > assume.)
  > > > > > > Boundary, or the sense of it that calls out for
  > > > Accessibility and
  > > > > > > Authorization, is relatively less significant in
  > > WSsec than in
  > > > > > > system security. Nonetheless, it'd be good if one can be
  > > > > vigorously
  > > > > > > defined for WS.
  > > > > > >
  > > > > > >
  > > > > > > > Is it from a s/w client to the web service?
  > > > > > >
  > > > > > > It's the WS implementer's choice, e.g. client sends
  > plaintext
  > > > > > > request and gets encrypted response in return. The
  > > > WSsec doesn't
  > > > > > > care.  It doesn't have to, as long as its security
  > > > semantics are
  > > > > > > complete, thus its repertoire of security primitives --
  > > > symmetric
  > > > > > > key encryption for bulk data, asymmetric key encryption for
  > > > > > > symmetric key exchange and for digital signature,
  > > > message digest,
  > > > > > > just to name a few -- can be sufficient to deal with
  > > just about
  > > > > > > the most challenging WS use case anyone may come up with.
  > > > > > >
  > > > > > > <sd>
  > > > > > > Are you saying that the implementer of the web service
  > > > > decides the
  > > > > > > boundary? I am a bit intrigued by the term "security
  > > > > semantics are
  > > > > > > complete" (This idea does sound promising) What does it
  > > > > mean to you?
  > > > > > > Can we define security semantics to any scenarios, or even
  > > > > > > abstract security semantics?
  > > > > > >
  > > > > > > Friendly ASIDE:
  > > > > > >   As for the repertoire of security primitives being
  > > > sufficient to
  > > > >
  > > > > > > deal
  > > > > > >   with WS- use cases, I would say, in theory yes, but
  > > > in practice,
  > > > > > >   to achieve "interoperable security" the parties
  > > > involved have to
  > > > > > >   go through a "hell of a journey" to make it work.
  > > WS-Sec may
  > > > > > >   safely stay away from that hell by only prescribing
  > > > primitives.
  > > > > > > </sd>
  > > > > > >
  > > > > > > > Or, is it from the human client to the web service
  > > provider?
  > > > > > >
  > > > > > > The human factor should be kept to a minimum, say
  > > > confining human
  > > > > > > involvement in WS endpoints to no more than private key
  > > > > > > storage/retrieval, e.g. a system administrator may be
  > > > > needed to type
  > > > >
  > > > > > > in a password to retrieve and decrypt an encrypted
  > > private key
  > > > > > > needed for public key ciphers during a WS server start-up.
  > > > > > >
  > > > > > > <sd>
  > > > > > >
  > > > > > > If the boundary is defined by the implementer, may be
  > > > it doesn't
  > > > > > > matter, because, the implementer would have defined the
  > > > roles of
  > > > > > > humans and their actions within the scenario.
  > > > Otherwise, it would
  > > > > > > make sense to define the role of humans and security
  > > > > > > implications in WSSec.
  > > > > > > </sd>
  > > > > > >
  > > > > > > Cheers,
  > > > > > > -Suresh
  > > > > > >
  > > > > > > Cheers,
  > > > > > >
  > > > > > > Joe Hui
  > > > > > > Exodus, a Cable & Wireless service
  > > > > > > ==============================================
  > > > > > >
  > > > > > >
  > > > > > >
  > > > > > > >
  > > > > > > > Cheers,
  > > > > > > > -Suresh
  > > > > > > >
  > > > > > > > -----Original Message-----
  > > > > > > > From: Joseph Hui [ mailto:jhui@digisle.net]
  > > > > > > > Sent: Thursday, March 07, 2002 7:40 PM
  > > > > > > > To: www-ws-arch@w3.org
  > > > > > > > Subject: D-AG006 Security
  > > > > > > >
  > > > > > > >
  > > > > > > > Hi all,
  > > > > > > >
  > > > > > > > As the volunteered "champion" (during today's
  > telecon) for
  > > > > > > one of the
  > > > > > > > WSAWG goals, "AG006 -- addresses the security of web
  > > > > > services across
  > > > > > > > distributed domains and platforms," I wish to solicit
  > > > > > your interest
  > > > > > > > in starting and sustaining a "spirited" discussion on
  > > > > web services
  > > > >
  > > > > > > > security.  The primary objective (of the discussion) is
  > > > > to confirm
  > > > >
  > > > > > > > the stated goal by *rough* consensus, and refine it
  > > > > (the goal, not
  > > > >
  > > > > > > > the consensus ;-) if necessary.  The secondary
  > > > objective is to
  > > > > > > > harvest the upshot of the discussion and turn it into
  > > > > something we
  > > > >
  > > > > > > > can use in near term for identifying "Critical Success
  > > > > Factors" --
  > > > >
  > > > > > > > whatever that may mean to you -- and requirements.
  > > > > Hopefully, by
  > > > > > > > being mindful of the objectives, we can keep this thread
  > > > > > > > reasonably focused.  However, please don't let the
  > > objectives
  > > > > > > > adversely constrain your will to express.  You're
  > > welcome to
  > > > > > > > disregard the objectives and throw in whatever you see
  > > > > fit in the
  > > > > > > > spirit of doing good for web services security.
  > > > > > > >
  > > > > > > > To get the ball rolling, let me start with the goal
  > > > > > > statement itself:
  > > > > > > >
  > > > > > > >    AG006 -- addresses the security of web services across
  > > > > > > >             distributed domains and platforms.
  > > > > > > >
  > > > > > > > Q to all: Is the goal set to your satisfaction?
  > > > > > > >           Too broad, too narrow, too ...?
  > > > > > > >
  > > > > > > > Answers/comments?
  > > > > > > >
  > > > > > > >
  > > > > > > > To flesh out AG006 a bit more in terms of its
  > > > > implications, we can
  > > > >
  > > > > > > > give it another whack at what addressing the web
  > > > > services security
  > > > >
  > > > > > > > (WSsec) should entail in the architecture
  > > > > > > > WS-Arch) to be designed.  Based on some previous
  > > discussions
  > > > > > > > fragmented across several threads in
  > www-ws-arch@w3.org, an
  > > > > > > > assertion can be made that attaining goal AG006 entails
  > > > > addressing
  > > > >
  > > > > > > > six security aspects in computing:
  > > > > > > >    1) Accessibility;
  > > > > > > >    2) Authentication (of ID and data/messages);
  > > > > > > >    3) Authorization;
  > > > > > > >    4) Confidentiality;
  > > > > > > >    5) (data) Integrity; and
  > > > > > > >    6) Non-repudiation.
  > > > > > > >
  > > > > > > > Comments?
  > > > > > > >
  > > > > > > >
  > > > > > > > Closely related to security is (the issue of) "trust."
  > > > > > > > We shall have a security framework alright. The
  > > question is:
  > > > > > > > should we include trust modeling as a part of the
  > > framework's
  > > > > > > > design, (e.g.. what trust model(s) to recommend or
  > > > adopt for web
  > > > > > > > services,) thus trust is a part of AG006; or should we
  > > > > > deem "trust"
  > > > > > > > outside the scope of AG006, thus we may need a
  > > separate goal?
  > > > > > > >
  > > > > > > > Answers/comments?
  > > > > > > >
  > > > > > > >
  > > > > > > > Also, there was the mention of "privacy" in the
  > > > charter, right
  > > > > > > > next to security.  Privacy can mean different things in
  > > > > different
  > > > > > > > contexts, ranging from preventing one's home address
  > > > > disclosed to
  > > > > > > > a web merchant from being sold to junkmailers to
  > > > > keeping one's ID
  > > > > > > > anonymous in transactions. I wasn't at the WS workshop
  > > > > last April,
  > > > >
  > > > > > > > so have no clue what that was about.  Can someone shed
  > > > > some light
  > > > > > > > on what the "privacy" is supposed to mean in our
  > > > > WS-Arch context,
  > > > > > > > so we can determine whether it will be appropriate to
  > > > > lump it into
  > > > > > > > AG006, or set a separate goal for it, or whatever?
  > > > > > > >
  > > > > > > > Answers/comments?
  > > > > > > >
  > > > > > > >
  > > > > > > > Please chime in.
  > > > > > > >
  > > > > > > > Thanks,
  > > > > > > >
  > > > > > > > Joe Hui
  > > > > > > > Exodus, a Cable & Wireless service
  > > > > > > >
  > > > > > >
  > > > > >
  > > > > >
  > > > >
  > > > >
  > > >
  > > >
  > >
  > >
  >
  >