Re: Michael Mahan's initial thoughts on privacy

My initial take was that it was out of scope.

Maintainence of privacy policies and preferences is especially important 
when interacting with a service or a choreography that forwards requests 
to other services, which may not be visible (a facade or composition 
pattern).

There are proposals that address this. For example, the combination of 
SAML + XACML can convey security and access information across multiple 
web service interactions. IBM & Microsoft have also outlined a proposed 
WS-Privacy spec, which I don't think has been published yet.

IMO the mechanisms for this are below the choreography level but we may 
want to include a note indicating that such technologies exist, or are 
emerging, and that there are cases where they are needed to meet privacy 
requirements.

I think the previous discussion of privacy in the list has more to do 
with hiding information about interactions themselves (not necessarily 
the data content of interactions), which is a different set of issues.

--Jon

Monica J. Martin wrote:
> 
> 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:51:26 UTC