The growth of web services has been accompanied by sharing more and more users' personal information with service providers, which has raised concern about possible malicious or accidental unauthorized abuse of user information. This paper focuses on how we can give the user a deep sense of safety, privacy and certainty about service invocations in the diverse and heterogeneous computing environment. We present Transparent privacy-enhanced Identity Management of Web Services (TPIM), a privacy-enhanced personal Identity Management architecture for web services users. TPIM is an extension of SOAP speci¯cation, which provides a sense of \circle of trust" in the identity management during the collaborations of web services. It enables that user's identity or personal data to adapt to be accessible only to whom they trust. In other words, a user can put his or her personal information on any web services and maintain privacy in di®erent user-de¯ned security level (including up to unconditional anonymity) as well.
People are expected to remember di®erent organization-speci¯c user names and passwords in the online world. Identity management systems seek automated solutions for managing their identities by making them transferable across organizational boundaries. However, an increasing sharing personal information with service providers concerns the user with risks to privacy. Aside from the endusers' privacy, if the system is perceived as privacy infringing, it will endanger the reputation of involved service providers, which may lead to loss of pro¯ts in the long run.
Research has shown that how to manage the identities in web services and maintain user's privacy is really a challenge. Many e®orts are made at \domaincentric" identity management, in which users have no control, and su®er from the identity theft or fraud. So scientists shift focus onto the dimensions of users control, where there is no universal agreement to date. ? This work was performed during the author's scienti¯c visit at Department of Computing, Macquarie University, Australia.
In this paper we investigate a transparent privacy-enhanced Identity Management (TPIM ), which enables the users have total control over the management of their identities. In order to enhance users' privacy, the SOAP standard is extended and a TPIM framework supporting \Single sign-on"(SSO) is proposed, which allows the user to access multiple sets of resources after being authenticated just once. It provides users with a more seamless user-experience when accessing di®erent user accounts on the Internet.
To sum up, this paper makes the following main contributions: { Id-based Ring signature is introduced and adapted to support unconditional anonymity. Even if ID information is leaked later on, the user can not be identi¯ed. Meanwhile the control of privacy preserving shifts from the third party to users themselves, which greatly increases users' con¯dence and promotes privacy. { The SOAP architecture is extended to enhance privacy in web services. The user can manage her own pro¯les and have a total control on her identities. The user can set di®erent levels of security identity. For example, a user may use a set of credentials or id name to access her blog with security level 1, a second set to discuss work with her colleagues with security level 2, a third set to purchase goods online with security level 3. Besides, a novel rule model is presented to exploit the privacy policies on both the organizational and execution levels. 2
Privacy in general has been exploited for years. However, privacy in web services
is still under development. Research to date has been focused on developing
privacy languages. Rezgui et al. [
In cryptography, Sharmir [
Keys Public Store(BBS) Keys Ring signature creation
Ring signature verifcation Identity Generator
Identity verification SOAP Head handler
SOAP Head Handler Message Body service SOAP Client
SOAP Engine Client Agent
Server Agent
The general idea of unconditional anonymity in TPIM is to hide the user's identity in a group S during service invocations. Figure 1 illustrates the architecture for our TPIM framework. In order to be convenient for leveraging applications software, our framework does not break any existing services by acting as add-on components, which guarantees easy integration with existing web-based applications. Speci¯cally, TPIM agents will probe in the network layer and snatch SOAP packages during the monitoring. Once identity related packages are intercepted, they are forwarded to user space to reconstitute the conversation for further judgement. After identity veri¯cation, the packages are either dropped or injected back to network layer. All the procedure are well encapsulated and executed in the background, making it completely transparent to the end-user.
We extend SOAP speci¯cation to support security and privacy features discussed in this paper. The <wsse:security> head blocks are designed to carry privacy related attributes: { ValueType: A string identi¯cation label de¯nes the value space and type of the encoded binary data. The value we have chosen for our anonymous group identi¯cation security token is \IdBasedRingSignature". { EncodingType: It de¯nes the encoding format of the binary data. In our protocol it is set to \wsse:Base64Binary" to denote a base64 encoding. { NameID: This element describes the group S which the user choose to hide in. To promote privacy, make sure the members within their lifespan during the period of invoking. We can use colon (:) marks to concatenate all the identi¯ers of individuals in the group S. For instance, if such group includes three persons: Alice, Bob and Lily, the NameID should be \Alice:Bob:Lily". { Conditions: Conditions must be evaluated when assessing the validity of the assertion. NotBefore and NotOnOrAfter, together with IssueInstant de¯ne the exact lifetime of the assertion. { AttributeSatement: It asserts a multi-valued attribute associated with the authenticated principal. In the response assertion, all the group public keys information is linked by colon (:) with each other in the same order of NameID element. For instance, the attribute values for Alice, Bob and Lily may be \XD6s. . . :ZCCA. . . :ors. . . ". In addition, the correspondent life expectancy is further supplied to assure the validity of each individual.
An example of a SOAP header containing anonymous group identi¯cation is presented in Figure 2. This extension gives rise to an additional payload required for encoding anonymous identi¯cation tokens in SOAP request that is proportional to the size of the group the user belongs to.
During the invocation, when the user issues a SOAP request toward Web services, the message is implicitly intercepted and processed by the client agent. This handler invokes the identity generator module and prepends the resulting identi¯cation token together with a timestamp to the SOAP header blocks of the outgoing request. The identity generator will comply with user's directive and bind the request to corresponding identity pro¯le. For example, in the highest security user pro¯les, the Id-based ring signature is produced to attain unconditional anonymity.
Whenever the service provider receives a SOAP request from client agent, the server side agent is implicitly invoked to determine whether the request should be accepted or not. If the request is for an authorized Web Services and no grouprelevant identi¯cation information are provided then it is rejected by raising a SecurityTokenUnavailable SOAP fault. In the case that the timestamp reported Envelope <xmls:env>
Header Wsse:Security
BinarySecurityToken Body Signature
< >
Element Attribute
Privacy Process lifecycle
No
Local Additional
Process Extract ring signature s Verification e
Y Passed Label! o
N Abort Organizational level Profile
Activity
View
Duration Organization context Execution level Subject
Action
Disclose to
Time in the request is older than a ¯xed security time interval the request is rejected with FailedAuthentication SOAP fault. Otherwise, the identi¯cation request is processed by identity veri¯cation module. If the veri¯cation is successful then the service request is executed and the response is returned to the application client. Otherwise, a FailedAuthentication SOAP fault is sent back to the requesting client. A representation of the privacy process life-cycle is depicted in the Figure 3. In order to avoid the °ow peak in SOAP header request, we forward privacy process to other available server agents for load-balancing. As shown in Figure 4, a rule model is designed to facilitate user's privacy policy setting under web service circumstances. Each security policy is de¯ned for and by an organization. Thus, the speci¯cation of the security policy is completely parameterized by the organization so that it is possible to handle simultaneously several security policies associated with di®erent organizations. The model is not restricted to identity permissions, but also includes the possibility to specify other identity related information such as priorities.
The rules are context sensitive, so the policy could be expressed dynamically at two di®erent levels. 1. Organizational level : The users de¯nes privacy rules through abstract entities (pro¯le, activity, view, duration) without worrying about how each organization implements these entities. 2. Execution level : When a user login in other organization, the execution authorizations are granted (or not) to him according to the execution rules. TPIM maps from organizational level to execution level for further elaborate control.
The derivation of invocation policies can be formalized as : Rule ¡ = P ermission£ ¨ £ H while P ermission(s; ®; d; t; c) is de¯ned as 8 subject s 2 S; performs action ® 2 A, login on to disclose-to service d 2 V; at time t 2 D.
{ Pro¯les S: A set of identity pro¯les in di®erent security levels. { Activity A: A set of aims of identity requests. { View V: a set of other services whom the identity information can be disclosed to. { Duration D: A set of durations of validity with regard to identity information. { Privacy level ¨ : The identity information should be protected at di®erent privacy level such as whether it allows service providers to store user's identity information. { Handling H: Once the identity information is breached, what approaches should be issued to notify the user of the risk, such as sending an email or an alert. The event-based approach is well suited for services' distributed environments. Apart from the regular infrastructure, the design will facilitate measures to integrate accounting and noti¯cation support. 4
We have introduced Id-based ring signature into web services and extended the SOAP standard to achieve privacy enhancement. The user can have su±cient control on her privacy. It provides a more user-friendly and e±cient ways of managing digital identities and enables people to assert their privacy rights in the online world. As future work, we will develop a tool to simulate the rule model and perform con°ict detection to help the designer to re¯ne rules.