RE: D-AG006 Security

Some responses:

1. I agree we need to address both transfer of credentials
(i.e., authentication data) and transfer of assertions
(the results of authentication and authorzation), e.g.,
via SAML components.

2. I also agree we need to address authentication
and authorization as it relates to web services.

3. I don't think we need to address transfer of (security)
context between web services if we are already factoring
in how assertions should be included as part of SOAP
message being received/transmitted by web services.

4. We need to distinguish between confidentiaility and
privacy. So, perhaps a definition will help:

Confidentiality : protection of information against disclosure 
to parties that are not authorized to know or access 
Privacy : protection of sensitive, individually identifiable
information against disclosure without the subject's consent

In my opinion privacy policies is web services application
dependent and is part of the domain of the web services
operation environment. Confidentiality policies need to be
addressed between a web services producer and consumer.

---Zahid



-----Original Message-----
From: Joseph Hui [mailto:jhui@digisle.net]
Sent: Friday, March 08, 2002 10:35 AM
To: www-ws-arch@w3.org
Subject: RE: D-AG006 Security


(My apology to those who might have received this as a duplicate
to "FW: D-AG006 Security".  I want to maintain the "RE:" part in
the subject line to preserve the thread's lineage.  Joe)

> From: Krishna Sankar [mailto:ksankar@cisco.com]
[snip]
> 	I think the requirement is a little too general. I would prefer
> it to be spelled at some point. So summarizing your message, may be we
> could say :
> 
> 	AG006.1 : Address Integrity
> 	AG006.2 : Address confidentiality.
Agreed.  (The two were included in the first msg of the thread.)

> 	AG006.3 : Address transfer of context between web services
The transfer of security context?
Can you expand this a bit, preferably with an example?

> 	AG006.4 : Address transfer of credentials between web services
I take it that you mean key exchange, such as using asymmetric key
encryption to exchange symmetric keys.  
Please clarify if you mean something else, or something more than
that, like the delegation of one Wes's credential to another.  

> 	AG006.5 : Address exchange of assertions between web services
> (This is SAML's domain. I think it will be good for us to address this
> at the architecture level)
Can you expand this a bit, preferably with an example?  
Do you mean the WS-Arch should also allow for robust yet anonymous
transactions, e.g. sellers and buyers don't know and don't care
who they're doing business with, yet nobody gets cheated in transactions?
Off cuff, I can only think of SAML as a language (from OASIS) for
"assertions," which allows for anonymity of transacting parties,
as opposed to "credentials,"  where identities are known and
authenticated.  

> 	AG006.6 : Address trust models (Everything has a trust model -
> either explicit or implicit. We might as well address this. BTW, trust
> model is what we could influence the most)
Ok.  So I count you in among those who favor including trust in
security.  I think you're in good company :-)


Now onto the other.

I do not agree with deleting Accessibility.
(Do you care to reason why it should be deleted?)
Someone, sorry I forgot who, said in another thread the other day
that we should add Accessibility in security to the "five security
aspects" (Authentication, ..., Non-repudiation) I proposed that we
should address; and I responded by saying we should include it
only in the form of a Security Consideration.  On second thought,
I realize we may as well go for broke and do them all, because it
can be done.  (I can go into the how2 details, but I won't at the
moment, because the WG's charter has ruled mechanism out of scope.)

I do not agree with deleting Authentication.
(Do you care to reason why it should be deleted?)
Most commercial entities won't transact with parties that can't
be authenticated.  (There's indeed the cybercash scenario where
transacting parties prefer anonymity.  But it's only a corner case.)

I do not agree with deleting Authorization.
(Do you care to reason why it should be deleted?)
Most commercial entities only transact with authorized parties.
WS endpoints should be able to control access to their resources,
by means of ACL, single-sign-on, licensing, etc.  

I do not agree with deleting Non-repudiation.
(Do you care to reason why it should be deleted?)
Non-repudiation is a very powerful tool for ensuring robust
transactions.  To that end, people have gone through much
trouble inventing digital signature and passing laws to
institute its legitimacy.  We'll be remiss in our WS-Arch
design if WS providers can't benefit from those achievements.


> 	AG006.7 : Address Privacy 
We need to pin down what Privacy is supposed to mean in our
WS-Arch first.  Was it tided over from P3P?

I'm of the opinion that Privacy should be separate from Security.

Mindful of a privacy role in commercial transactions, I've
tabulated a set of scenarios where "privacy" is synonymous with
"anonymity," i.e. hiding one's identity from others.  (Note that
hiding one's data/message from other is Confidentiality, which
we already address in the Security section.)

Here's a web service model involving Alice as the provider and
Bob as the consumer.  Alice is aka "A" to the public and "a" to Bob.
Bob is aka "B" to the public and "b" to Alice.  Both Alice and Bob
are members of the public.

A privacy tabulation:

   AaBb: no anonymity (ACLU's nightmare ;-)
         The IDs of Alice and Bob are publicly known.
         Alice and Bob know each other's IDs.

   Aaxb: partial anonymity
         Alice's ID is publicly known.
         Bob's ID is not publicly known.
         Alice and Bob know each other's IDs.

   xaxb: partial anonymity
         Alice's ID is not publicly known.
         Bob's ID is not publicly known.
         Alice and Bob know each other's IDs.

   xaxx: partial anonymity
         Alice's ID is not publicly known.
         Bob's ID is not publicly known.
         Bob's ID is not known to Alice.


   xxxb: partial anonymity
         Alice's ID is not publicly known.
         Bob's ID is not publicly known.
         Alice's ID is not known to Bob.
         (Buyer doesn't know seller.  Escrow may be needed.)
         Bob's ID is known to Alice.  (Seller knows buyer.)

   xxxx: total anonymity (drug dealers' dreams come true ;-)
         Alice's ID is not publicly known.
         Bob's ID is not publicly known.
         Bob's ID is not known to Alice.  (Seller doesn't know buyer.)
         Alice's ID is not known to Bob.  (Buyer doesn't know seller.)

My math says I can make (4**2) sixteen combinations out of AaBb.
I've only picked out what I think the interesting ones in this
rough cut.  Please feel free to add.

If we're on track with the privacy definition (in our WS-Arch
context), then we may start picking some from the tabulation to
throw into a "bucket," so later we can use them for requirements.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
============================================



> 
> cheers
> 
>  | -----Original Message-----
>  | From: www-ws-arch-request@w3.org 
>  | [mailto:www-ws-arch-request@w3.org] On Behalf Of Joseph Hui
>  | Sent: Thursday, March 07, 2002 5: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
>  | 
>  | 
> 
>