RE: D-AG006 Security

Joseph,

	Good questions. I will take it upon me to detail the points
raised. Let me take a couple of days to think thru and elaborate the
various aspects and present a first cut. Will try to do examples as
well. BTW, I did not mean to take AuthC and AuthZ out. We need them
both.

	But I do not think non-repudiation is within our domain. It is a
business artifact and has a lot of legal and business impacts. 

	For example legally we need to keep records for 7 years and what
happens if advances in cryptography makes the old way of securing is no
more valid ? Non-repudiation cannot be solved purely by
technology/infrastructure. 

	What is your definition of accessibility ? Would it be covered
by AuthZ and privacy ?

	I do think privacy is important. Anonymity is part of it, other
part is not to allow visibility because of a set of
circumstances/capabilities/side effects; yet another part is the freedom
to decide how much can be visible under what circumstances. How it
manifests itself is for us to figure out.

cheers


 | -----Original Message-----
 | From: www-ws-arch-request@w3.org 
 | [mailto:www-ws-arch-request@w3.org] On Behalf Of Joseph Hui
 | 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
 | >  | 
 | >  | 
 | > 
 | > 
 | 
 |

Received on Friday, 8 March 2002 17:11:18 UTC