RE: Michael Mahan's initial thoughts on privacy

A couple of points here.

1) Yes, Privacy use cases and requirements have been addressed 
   as part of WSA Requirements. If there are special privacy
   requirements that need to be addressed for choreographed
   message exchanges then we should coordinate that with WSA.
   Francis discussion w.r.t. privacy context is interesting
   and extends the privacy discussions currently captured
   in WSA.

2) Federated identity management certainly intersects with
   Liberty as well other WS Security specifications. E.g., 
   OASIS WSS, recently made public WS-Federation spec from 
   Microsoft and IBM.

3) Eventually, I see that WS-I will have to take up the work
   to develop interoperability profiles for securing 
   choreographed message exchanges although in the short-run
   the expectation is that they will produce some basic
   security profiles for transport and message level security
   using SSL/TLS and OASIS WSS. 
   (See http://news.com.com/2100-1012-994938.html )



Zahid Ahmed
Web Services Architect
eBay, Inc.




-----Original Message-----
From: Monica J. Martin [mailto:monica.martin@sun.com]
Sent: Wednesday, July 09, 2003 10:32 AM
To: Francis McCabe
Cc: public-ws-chor@w3.org
Subject: Re: Michael Mahan's initial thoughts on privacy



Frank,
In looking at this privacy draft, I have a few comments and/or questions:

    * Does this not define a potential dependency for choreography - for
      privacy and identity (such as federated network identity, and work
      in other sections like Liberty)?
    * If so, is it within our scope to expand on this and/or provide
      input to WSA?
    * This may also involve quality of service. Has this been considered?
    * Other mechanisms exist beside WS-Policy such as WS-PolicyLanguage
      which is already within a standards body (OASIS, XACML I believe).

Perhaps as we continue these discussions, we can early on identify what 
is within our scope or findings we need to pass to other groups/entities.

Thanks.

Francis McCabe wrote:

>
>   WSA Privacy Section (draft)
>
> Michael Mahan
>
> The Web services architecture must address privacy in two separate 
> contexts. One context is the assurance of confidentiality during 
> message transmission between the service requestor and the service 
> receiver. This includes messages that are processed by one or more 
> intermediary processors before arriving at its ultimate receiver. 
> Privacy, in this context, is addressed by message confidentiality 
> technologies and this is one of the facets of Web services security 
> and is address in section x.x.x.x.
>
> The second privacy context addresses data protection. Information 
> privacy is the management of sensitive information that may be 
> obtained by any of processing nodes during a Web services message 
> exchange. Central in this context is the end user’s right to know how, 
> when, and to what extent their personal or sensitive information will 
> be used by the Web services processing nodes. Protected usage includes 
> the sharing of personal or sensitive information obtained by a 
> processing node with any third party. Also central is that these 
> practices should be exposed by the processing nodes prior to a service 
> invocation, allowing a service requestor to factor a processing node’s 
> privacy practices in the decision to use a particular Web service or 
> to follow a particular message route. Hence, the publishing and 
> accessibility of a Web service processor’s privacy practices will aid 
> an end user to retain control over his personal information. This is 
> contingent on the compliance to the published privacy by the Web 
> service processor and is outside of the scope of technology solutions.
>
> Sensitive information provided by a Web service requester and obtained 
> by a processor may include identify information such as name, physical 
> address, email address, social security number (in the U.S.), driver 
> license number, etc. Personal, yet non-identify information such as 
> age, gender, account numbers, affiliated organizations, hardware 
> capabilities, and user preferences may also be transmitted during a 
> Web service invocation. A user’s or institution’s financial 
> information is probably the most sensitive of data – immediate and 
> direct harm results if this information is not properly protected. In 
> addition to storing directly provided information, a service provider 
> or even a message intermediary can capture service trends about the 
> user or the service requester. Correlated data is often sold to third 
> parties and should be subject to privacy protection.
>
> Legislation is a major driver of privacy requirements in some 
> countries such as the U.S. and in some global organizations, such as 
> the E.U. Hence, it will be mandatory that some Web service processors 
> make its privacy practices available to service users, dependent on 
> the relevant local regulatory environment.
>
>
>     Privacy policies
>
> Privacy policies apply to any and all entities that collect or collate 
> personal information during Web service messaging. Privacy policies 
> encapsulate the rules that govern the usage, management, and potential 
> dissemination of collected or collated personal information. Privacy 
> policies define how, when, to whom, and for how long personal 
> information is available to the Web service processors.
>
> <More on privacy policies and maybe WS-Policy>
>
> <P3P described>
>
> <example P3P usage in Web services>
>
>
>   Identity Management
>
> Anonymity is often used to ensure privacy. Anonymity in the Web 
> services context is a mechanism to ensure that the identity of a user 
> is not disclosed during a Web service invocation. Hence, information 
> supplied to the Web services provider will be free of values that can 
> be used to identify the user. A Web service provider’s 
> identity-oriented fields might only get a pseudonym. This is a simple 
> form of identity management and architecturally requires an 
> application intermediary that is inside the user’s trust boundary. The 
> application intermediary will relay the user request to the ultimate 
> receiver after stripping out user sensitive information and replacing 
> any required data with intermediary-oriented data, including the 
> pseudonym.
>
> Web service providers often require an identifier for each user. This 
> identifier requirement originates from the provider’s user 
> authentication mechanism. The provider then uses each identifier as 
> the key to stored sensitive data relating to an individual service user.
>
> A Web service user will typically interact with many Web service 
> providers. Hence, each Web service user will need to maintain many 
> identifiers, regardless of whether the user use specialized 
> application Web service clients, a general application Web services 
> client (i.e. browser-based) or some mixture of these two client types. 
> Service providers often capture the same sensitive information, such 
> as address, personal preferences, and financial data. This duplicated, 
> distributed data is apt to become stale, as each user’s sensitive 
> information may be volatile.
>
> A solution to these issues is to provide Web service users a federated 
> network identity. A federated network identity will provide a Web 
> service user a single repository for all online identities and 
> sensitive information including preferences and purchasing habits. 
> Architecturally, an identify provider fulfils the role of a federated 
> network identity. Each Web service user can then administer his 
> multiple identities. The identity provider will then securely share 
> Identity and sensitive information with Web service providers 
> discriminately.
>
> <Include required Identity Management architectural entities and 
> relationships>
>
>
>
> Privacy *is* going to be addressed by the WSA. It is not currently had 
> a huge amount of progress since this was posted at the beginning the May.
>
> Frank

Received on Wednesday, 9 July 2003 14:32:03 UTC