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 13:20:38 UTC