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.

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.