WO2005050422A1

WO2005050422A1 - Apparatus for providing a service in an identity federation framework

Info

Publication number: WO2005050422A1
Application number: PCT/SE2004/001559
Authority: WO
Inventors: Carolina Canales Valenzuela; Maria Esther Bas Sanchez; John Michael Walker
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2003-11-18
Filing date: 2004-10-26
Publication date: 2005-06-02
Also published as: SE0303057D0

Abstract

A apparatuses (SP1, Idp) for providing a service to a referencing user (User 1) which consumes an attribute of an identity service for a referenced user (User 2). An SP apparatus comprise means to request a second contact information in relationship with a private identifier of a referenced user, means to obtain a second resource offering in relationship with said second contact information, and means to request a service action on behalf of the referencing user for an attribute in relationship with said second resource offering. An Idp apparatus comprises means to store contact information in relationship with a plurality of federated pseudonyms for a referenced user, means to store a private identifier of said first user in relationship with said contact information, means to receive a request for said contact information comprising said private identifier to provide a service to a second user in a Service Provider, and means to provide said contact information at reception of said request.

Description

APPARATUS FOR PROVIDING A SERVICE IN AN IDENTITY FEDERATION FRAMEWORK

FIELD OF THE INVENTION

The present invention relates to the provision of services in an identity federation framework and, more precisely to the apparatuses involved in said provision.

BACKGROUND The Internet is a growing network wherein services are provided by different organisations generally known as service providers (hereinafter SPs) . Many SPs allow users the possibility to have accounts with them. Indeed, depending on the service offered, it is often required to have a service account at a given SP. The access to a given SP may require users to authenticate themselves towards that SP. In other words, users must be able to prove who they are. This commonly achieved by providing an "identity" to each user; wherein said identity can comprise credentials for authentication and identification purposes (e.g. an identifier, such as a username, to identify said user and a password) . Once a user is authenticated in a SP (e.g. by entering his username and password) , he is allowed to access a requested service provided in or through said SP . The identity of a user in a given SP can further comprise some additional attributes which can be, for example, needed to shape or characterize the content of a given service to said user (e.g. a record of user preferences and settings), and/or personal or profile data related to said user (e.g. particular address, e-mail identifier, employer name, title, etc) which the SP can request to the user when his account is created.

A given user may have service accounts at a plurality of SPs, wherein, as stated above, each SP has an identity for said user which comprises information related to said user which can be confidential and/or which could not be used or disclosed without the user's consent. Among the information related to an identity of a user in a SP that is intended to be confidential are, for example, the credentials used to authenticate said user in said SP (e.g. his password or the combination of his username and password) .

The advent of Internet services (e.g.: services that can be accessed through a web browser) has brought with them a new service that allows users to access said services in an easy and convenient manner, the so-called "Simplified Sign-On" (also called "Single Sign-On" ) SSO. The current principle behind SSO states that users shall be able to authenticate once and then shall be given access to all their subscribed services that accept such level of authentication. This principle (SSO) enables a user to access different services without explicitly authenticating for each particular different service. SSO is commonly accomplished by authenticating a user once at a given entity (hereinafter referred as "Identity Provider" IdP) , and making the resulting authentication valid for entrance to other SPs. In other words, the purpose of SSO is to allow users to securely access different services and applications, which can be accessed through SPs that can be even dispersed across different network domains, without being authenticated every time. An example of an standardized framework to provide SSO is currently known from "Liberty Alliance Project " LAP (http://www.pro ectliberty.org/). It shall be notice that some LAP specific terms and procedures can be referred across this application, being those references given just to illustrate, by way of example, a well known identity federation framework. Thus, the skilled person would readily identify equivalent specific frameworks and the equivalent terms and functional procedures in those equivalent frameworks. LAP is an is an industry forum founded in 2001 to establish an open standard for federated network identities; wherein the term network identity refers to the global set of attributes that are contained in an user's various accounts with different SPs, namely, the global set of attributes contained in the individual "identities" said user has across a plurality of SPs. In a first stage, LAP released a set of specifications to allow the, so called, "Identity Federation Framework" ID-FF in a, so called, "Circle of Trust" CoT; wherein a CoT comprises an IdP and a plurality of SPs which can share, for a given user, a set of linked (federated) identities of said user through said IdP. It shall be noticed here that a given user may or may not have a service account on each SP of a CoT; so, a given SP can offer a service to a user who does not have a previous service account with it provided that, for example, said SP delegates the authentication of said user to an IdP and the IdP asserts said authentication to this SP. Also, it shall be noticed that, in the LAP vocabulary, the term "principal" is used to refer to an entity that can acquire a federated identity, wherein a "principal" can be: a human user, a group of human users, a corporation, a legal entity, etc. Since all those types of "principals" are actually "users" of the identity federation, the term "user" shall be used in this application to refer indistinctly to a user of the identity federation, regardless his/its type.

An example of SSO accomplishment shall now briefly be described. A user first access to a given SP ,e.g. via a web browser, and request a given service said SP provides. Then, the user's browser is redirected from the SP to the corresponding IdP. Once in the IdP, and if he had not previously be authenticated, or if a previous authentication for this user is not yet valid (e.g. it has elapsed), the user is authenticated using his normal credentials at said IdP (e.g. by means of user identity and password) . In either case: if the user has successfully authenticated now, or if the user already had a previous valid authentication, his browser is redirected back to the SP. Said redirection comprises a reference to said authentication (called "artifact" in LAP terminology) that can be used by the SP to further obtain some data (called "assertion" in LAP terminology) from the IdP related to said authentication so as to allow said user to access the service he has requested; although, alternatively, the IdP can include directly the "assertion" in the redirection.

In an identity federation scenario as described heretofore, a given user can have one or more service accounts in various SPs of a CoT, can be identified by a different identifier on each of said SPs. However, it is only his IdP the only entity that keeps the information that relates the plurality of identifiers associated to said user in a plurality of SPs, being this achieved by means of a service account federation process. In short, the account federation process for an account of a user in an SP comprises an interaction between the SP and the IdP, in which an alias to reference said user is agreed. Commonly, said alias is not the identifier that is assigned to said user in said SP, but a kind of identifier usually known as "pseudonym". For example, a given user can be identified in the SP "SPl" by an identifier such as "John_Doe@SPl" , and be identified with "JonnyD@IdPa" in the IdP "IdPa", whilst a pseudonym such as "mr3Tj#455a" can be used between SPl and the IdPa to identify to (refer to) this user. Therefore, in an identity federation scenario, for a given user, an IdP stores all the pseudonyms which can be utilized to refer to said user by the plurality of SPs in a CoT where said user has a service subscription that has been federated; therefore, the identity of a user in a SP is unknown for another SPs where said user can have a service account.

In addition to the mere provision of a SSO service, an identity federation framework (as the one disclosed by LAP) also envisages the, so called, "identity services", which, in short, are services that consider the consumption of attributes of federated identities of users across SPs. Accordingly, a given SP can offer a given service to a user which might need the consumption of an attribute of the (network) identity of said user (e.g. his credit card number, data about his calendar, etc) that can be stored, for example, in another SP. Said "consumption" can comprise, not only the retrieval and/or updating of said attributes, but also the performance of some action on the benefit of an identity (e.g.: an attribute of an identity of a user in a SP comprises his mobile phone number, being the action to send a Short Message to this number from this SP) .

In particular LAP regards this aspect in its "Identity Web Services Framework" ID-WSF. The ID-WSF provides, together with an standardized description of the identity services and the method to access them, the so called "Discovery Service" DS which allows a given SP (e.g. "SPl") to dynamically discover a user's registered identity services. To accomplish this, the entity providing the DS (that can be an IdP or a specific SP) stores, per user, information about the SPs hosting identity services for this user, as well as the references that are usable in each of said SPs to point out to said identity services (i.e.: in a particular SP this reference is usable to find out the attribute (s) of an identity of said user that can be shared for other services) . It shall be noticed that the identity attributes of a user can be stored, not only in SPs (as described here by way of example as identity services providers) , but in another kind of entities which acts as mere identity data providers .

The information stored for a given user in the DS shall be referred hereinafter as the "resource offering" RO for said user. In practical terms, it can be considered that there can be a plurality of resource offering entries for a given user in the DS, one per identity service of said user, wherein each entry can contain information about the SP hosting the corresponding attribute (s) , as well as the aforementioned reference usable to find out said attribute (s) in said SP. In addition to the plurality of pseudonyms federated for a user through a plurality of SPs, to accomplish with ID-WSF the IdP also stores, in relationship with said federated pseudonyms, an information (hereinafter referred as "contact information") usable to address in the DS all the RO of said user; being the "contact information" of a user delivered from the IdP to an SP when a SSO process is run in said SP for said user (e.g.: delivered within the "assertion" for said user) . Also, to accomplish with ID-WSF, the DS is arranged to receive discovery look-up operations from an SP which ask for information to find the entity (e.g. another SPs) which hosts a given identity service for a user who has requested a service in said SP, and to answer back with the corresponding RO entry which can be used by said requesting SP to request the pertinent service action that needs the consumption of an attribute which is in relationship with said RO (e.g. to obtain from another SP the identity attribute(s) it needs, to modify it, etc).

For example, a given user (e.g. user-X) can have an account with a SP (e.g.: SPl) which is a bank that holds data about his credit card account. This user also has a calendar service with another SP (e.g.: SP2) where he stores his calendar appointments, meetings, etc. In this example scenario, another SP (e.g.: SP3) offers a flight booking service with payments using credit cards and that further comprise (e.g. as an extra optional feature) the checking and/or updating of the user's calendar (e.g. verifying user's availability marking the flying time as "unavailable", setting a task to pick the ticket, etc.), or the checking of the user's calendar data to verify whether a given flight can be convenient. When user-x access to SP3 , the DS contact information for user-x is obtained by SP3 from the IdP as a part of the SSO authentication procedure which takes place for this user-x between SP3 and the IdP. Then, when user-x request the flight booking service in SP3, said contact information is used to query from SP3 to the DS to obtain the RO that corresponds to the "credit card" service and to the "calendar service" of user-x. Once obtained, SP3 contacts with SPl and e.g. obtains the credit card number for this user. SP3 can also contact with SP2 and e.g. obtains user availability information and/or sets an appointment on his calendar and/or marks the flying time as "unavailable" . An identity framework as the one defined by ID-FF and ID-WSF regards mechanisms for protecting user privacy that, as cited earlier, include the use of pseudonyms when two parties (e.g. two SPs, a SP and a IdP, etc) interact regarding a user; such that the user's actual identifiers (either: pseudonyms or user identifiers) at either party is not known to the other party. In particular, for the identity services, a SP (such as "SP3" in the example above) that consumes attributes of a given user stored in another SP (such as "SPl" in the example above) does not get to the user identifier of this user in the IdP, nor any user identifier or pseudonym of this user in any other SP or IdP. For example in the case cited above, SP3 only gets a reference usable in the DS to point out the corresponding RO of the user in the DS, and a reference usable to point out the corresponding attribute (s) in SPl and/or in SP2.

Accordingly to these privacy mechanisms, the identity services model works well when a user is doing things on his own behalf. Namely, this known framework regards only a situation wherein a given user accesses a SP that provides a service which needs to consume (e.g. retrieve, update, etc) an attribute of the identity of this user which is stored e.g. in another SP. On the other hand, it can be envisaged the offering of services which can involve, not only to the user who requests the service, but another user (or users) , and thus, which can involve the consumption of attributes of said another user(s). However, the known privacy mechanisms in this federation scenario would preclude this kind of services, since, otherwise, a given SP could relate some data of a given user (e.g. his calendar data, or his visa number) with an identifier of this user in another SP or on his IdP, and, for example, use this relationship later to make unauthorized profiling of this user, or use it for any other unauthorized purpose.

Therefore, it should be desirable an identity federation framework that, without breaking the necessary user privacy, allows these kind of services to be offered.

SUMMARY OF THE INVENTION

The aforementioned object is achieved by an apparatus for providing a service from a Service Provider as claimed in claim 1, in cooperation with an Identity Provider apparatus as claimed in claim 6. A detailed control in the provision of the resource offering pertaining to a given user and concerned for a service which is going to be served to another user is achieved by an apparatus as claimed in claim 14 in cooperation with a Service Provider as claimed in claim 1.

In one aspect the invention relates to an apparatus for providing a service from a Service Provider in an identity federation framework. The apparatus has: means to receive a service request from a first user requesting a service, means to obtain a first resource offering in relationship with an identity service of said first user by using first contact information associated to said first user obtained as a result of his authentication by an Identity Provider, and means to provide said service to said first user. According to the invention, and in order to provide a service to said first (referencing) user which involves the consumption of identity attributes of a second (referenced) user, the apparatus for providing a service from a Service Provider further comprises: means to request a second contact information in relationship with a private identifier of a second user, means to obtain a second resource offering in relationship with said second contact information, and means to request a service action for an attribute in relationship with said second resource offering.

In order to hide the knowledge of the private identifier of a second user, the means to request said second contact information in relationship with said private identifier can vary according to various embodiments. In a first embodiment, said means to request said second contact information comprise means to redirect said second user to an Identity Provider to enter said private identifier in said Identity Provider. In a second embodiment, said means to request said second contact information comprise means to receive said private identifier encrypted in a service request from said first user, and means to send an acquaintance request to an Identity Provider comprising said received encrypted private identifier. The second contact information obtained in either case (in a new redirection from the Identity Provider, or in an acquaintance response) can be utilized to send a discovery look-up to a Discovery Service server entity to obtain the corresponding second resource offering.

In another aspect, the invention relates to an Identity Provider apparatus in an identity federation framework having: means to store a plurality of pseudonyms of a first user federated through a plurality of Service Providers, means to store contact information in relationship with said plurality of federated pseudonyms and usable to obtain a resource offering for an identity service of said first user, and means to authenticate said first user when accessing a Service Provider and to provide said contact information to said Service Provider as a result of said authentication. In order to allow the provision of a service to a second (referencing) user which involves the consumption of identity attributes of said first

(referenced) user, an Identity Provider apparatus according to the invention further comprises: means to store a private identifier of said first user in relationship with the contact information of said first user, means to receive a contact information request requesting the contact information in relationship with said private identifier of said first user in order to provide a service to a second user in a Service Provider, and means to provide said contact information at reception of said request.

The means to receive the contact information request and the means to provide said contact information at reception of said request can vary according to various embodiments. In a first embodiment, and in order to hide the knowledge of the private identifier of a referenced first user to a Service Provider, the Identity Provider apparatus comprise: means to receive a redirection of said second user from the Service Provider which provides a service to said second user, means for receiving said private identifier from said redirected second user, and means to redirect said second user back to said redirecting Service Provider; wherein said redirection comprises the requested contact information corresponding to the referenced first user. In a second embodiment, the Identity Provider apparatus comprise: means to receive an acquaintance request containing said private identifier from a Service Provider which provides a service to said second user, and means to send an acquaintance response back to said Service Provider which comprises said contact information. The Identity Provider apparatus can further comprise means to decrypt a received encrypted private identifier . According to a further embodiment, an Identity Provider apparatus further comprises means to send an acquaintance request to another Identity Provider apparatus containing a private identifier received, either: in a redirection of a second user, or in an acquaintance request, if no contact information is stored in this Identity Provider apparatus in relationship said private identifier.

A private identifier of a given user can be stored in an Identity Provider apparatus according to various embodiments. In one embodiment, a private identifier of a given user can be provisioned by an operation and maintenance operation as one more user's related data in the Identity Provider apparatus. In a further embodiment, an Identity Provider apparatus can further comprise means to receive said private identifier from an identity service registration from a Service Provider providing an identity service to said user. In yet a further embodiment, an Identity Provider apparatus can further comprise means to receive a private identifier for a user entered in said Identity Provider apparatus from said user.

According to another embodiment, an Identity Provider apparatus according to the invention can further store the private identifier of a first user in relationship with one or more identifiers of: one or more allowed Service Providers, one or more allowed second users, and one or more identifiers of services which can be provided to said allowed second users which are allowed to obtain the corresponding contact information stored in relationship with said private identifier. Thus, according to this embodiment, the Identity Provider apparatus can be further arranged to check whether or not to provide said contact information by checking one or more conditions concerning: the Service Provider which is going to serve a service to a second user, the identity of said second user, and the concrete service that is going to be served to said second user. These identifiers of allowed Service Providers, users and services can be stored in the Identity Provider apparatus according to any of the storage alternative embodiments related earlier.

In a further aspect, the invention relates to an apparatus for providing a Discovery Service in an identity federation network having: means to store a resource offering in relationship with an identity service of a first user, means to receive a discovery look-up request from a Service Provider to provide a service to said first user, and means to provide said resource offering at reception of said discovery look-up request. In order to control the provision of said resource offering when provided for serving a service to a second user, said resource offering is further stored in relationship with various identifiers selected from: the identifiers of the Service Providers allowed to request said resource offering for providing a service to a second user, and the identifier of the allowed second users. Thus, according to this embodiment, the apparatus for providing a Discovery Service can be further arranged to check whether a Service Provider sending said discovery look-up request is an allowed Service Provider, and/or whether said second user is an allowed second user; to determine whether or not said resource offering can be provided.

In virtue of the characteristics and cooperation of the apparatuses as described therein, in an identity federation framework can be offered identity services which need not to be limited to those exclusively related to the user who makes the service request, but to another referenced user or users, while, at the same time, maintaining the necessary privacy concerning the various and distinct identifiers of the referenced users across various Service Providers.

BRIEF DESCRIPTION OF DRAWINGS

Figure 1 shows a schematic view of two Service Providers, an Identity Provider and a Discovery Service server entity in a identity federation framework.

Figure 2 shows a similar view as shown in Fig.l, but showing a situation wherein the two users are federated in different Identity Providers.

Figure 3 shows a simplified signaling flow for the setting according to one embodiment of the invention of a private identifier of a user in an Identity Provider.

Figure 4 shows a simplified signaling flow for the provision of a service to a referencing user which needs to consume an identity service of a referenced user, wherein, as in Fig.l, only one Identity Provider is involved.

Figure 5 shows various acquaintance embodiments to obtain the contact information for a given referenced user from an Identity Provider which does not contain said contact information.

Figure 6 shows a first embodiment of an equivalent flow as the one shown in Fig.4, wherein more than one Identity Provider are involved.

Figure 7 shows a second embodiment for the flow shown in Fig.6. Figure 8 shows, by way of a simplified signaling flow, an embodiment to allow a referenced user to federate in the Service Provider of an allowed referencing user through an intermediate Service Provider.

DETAILED DESCRIPTION

Some exemplary embodiments of the invention shall now be described in detail with references to figures 1 to 8.

Figure 1 shows a schematic view of two SPs, one IdP and one DS in a identity federation framework. Fig.l also shows generic data structures handled by the IdP and by the DS for two users. It shall be noticed that a given service provider can have a plurality of apparatuses for providing services; similarly, within a Circle of Trust CoT, there can be a plurality of apparatuses acting as Identity Providers for a plurality of users as well as a plurality of apparatuses providing a Discovery Service. However, for a clearer understanding of the invention, the SPs IdPs and DSs depicted in the figures illustrating this invention, it can be assumed each of them to represent the particular apparatus providing respectively the corresponding function. Also, for the sake of a greater simplicity a "human user" appears to be depicted as a "user" in some figures referenced in this detailed description. However, it shall be understood that said "user" intends to refer to an entity (e.g. such as a "principal" in LAP terminology) which, as stated earlier, is not necessarily a human user in cooperation with a user terminal, although this can be considered as an example case. In the particular example case shown in Fig.l, a user (User 2) has a service account in SP2 which offers him a particular identity service (IdServx) and has federated this service account to his IdP. As a result of this, IdP stores for User 2 a pseudonym (Alias2) which both, the IdP and the SP2 , shall use to refer hereinafter to this user. This pseudonym is stored in relationship to User 2's data in the IdP together with other pseudonyms which can be related to this user in another SPs (SPm: Aliasm) . The particular service that SP2 offers to User 2 can be, for example, the master storage of his calendar data as well as their corresponding access and updating. User 2 has also consent to register (101) SP2 within his IdP and DS for this identity service; and, as a result, the DS stores one resource offering RO entry (IdServx/SP2/RefSP2 ) which contains information about the SP hosting this identity service (SP2 in this case) , as well as a reference usable in said SP to point out the identity attribute (s) of said identity service which can be consumed by other SPs. This entry is stored in the RO of this user (103) in the DS in addition to any other RO entry (IdServz/SPn/RefSPn) eventually stored in relationship with another identity service of this user. In turn, the IdP stores the corresponding DS contact information for this user (DSUser2) which points out (102) the corresponding RO of this user in the DS.

Another user (User 1) has accessed to another SP (SPl) e.g. wishing to access a service SPl provides. User 1 may or may not have previously a service account in SPl and, for example, SPl can provide a given service to User 1 if said an authentication of said user can be asserted from the IdP (e.g. : User 1 has been previously authenticated in another SP and this authentication is considered still valid) . In either case (User 1 having a previous service account in SPl or not) , as a result of the assertion of the authentication of User 2 from the IdP to SP2 (i.e.: SSO process). As a result of this, IdP stores for User 1 a pseudonym (Aliasl) which both, the IdP and the SP2, shall use to refer hereinafter to this user. The particular service offered by SPl to User 1 can be, for example, the booking of a flight and the updating of another user's calendar (e.g.: User 2's calendar) for marking the flying time of this flight as busy.

The scenario shown in Fig.2 considers the same case as the one explained with reference to Fig.l, wherein both users have federated through different IdPs (IdPA and IdPB) . This scenario shall be later used to detail some acquaintance embodiments wherein more than one IdP is involved.

In a situation as the ones depicted in figures 1 or 2 , User 1, acting as requesting/referencing user, can request a service which needs the consumption of attributes of an identity service that e.g. another SP (e.g. SP2 ) hosts for another user (referenced user; e.g. User 1). According to the invention, User 1 does not need to know the SP hosting said service (SP2), nor the pseudonym used between said SP and the IdP (Alias2) for the referenced user, nor other pseudonym federated for the referenced user through other SP. As mentioned earlier, it shall also be noticed that, according to the invention, if a given user (requesting user) accesses an SP that provides a service which, for its accomplishment, needs to consume an attribute of the identity of another user (referenced user) , does not necessarily need to have a service account with said SP and, for example, the SP can provide said service if the IdP can asserts the authentication of this requesting user. In particular, according to the invention, a private identifier for a user that can be referenced by another referencing/requesting user is stored in relation with an identity service of said referenced user. In the example case shown in figures 1 and 2, a private identifier (PrivateID2) is stored in relationship with the data stored for User 2 on his IdP. The actual format of the private identifier of the referenced user is irrelevant to the invention. Either structured and standardised identities (e.g. domain names, e.164 numbers, Uniform Resource Identifiers URIs, etc) as well non-structured and/or non- standardised name identifiers (e.g. any alphanumeric string) can be used.

The provision of the private identifier for a user in an IdP can be accomplished by different methods. For example, it can be set by usual data provisioning processes (e.g. current operation and maintenance processes that allow to set or modify data in a given apparatus) . Another alternative solution can be to assign said private identifier to a user dynamically; for example, when the user federates an identity at first time or at first log-in of this user in the IdP. In this latest case, the IdP can e.g. prompt the user for entering a private identifier or assigns him one automatically. It shall be noticed that, although the storage of only one private identifier has been depicted in the examples shown in figures 1 or 2 for User 2 , more than one private identifiers can be assigned per user, wherein each one can, for example, be usable for a given identity service of this referenced user.

A particular alternative shall now be described with reference to Fig.3. In a first step (301) User 2 access SP2 and consents it to register the identity service it provides (IdServx). In a second step (302), SP2 sends to the DS a registration request for this user and this service, wherein the registration request contains a private identifier in relationship with said user and, optionally, with said service. The registration request can further contain policy rules that state, for example, what users can reference this user by utilizing this private identifier, from what SPs, and for what particular referencing service. In a third step (303) the DS sends the received private identifier to the IdP to be stored in relationship with the data of User 2. The registration request can be further acknowledged back in further steps (304, 305). As a result of this process, a private identifier of User 2 has been set in the IdP in relationship with the contact information which addresses the RO of User 2 in the DS, while the DS keeps one RO entry which contains information about that SP2 hosts this identity service, as well as a reference usable in SP2 to point out the identity attribute (s) of said identity service which can be consumed by services provided by other SPs.

Independently of the provisioning mechanism used to set a private identifier of a user in a IdP, there can be policy rules defined for controlling the access to the RO and/or to the contact information said private identifier relates. In particular, said rules can be implemented in a IdP to control whether the corresponding contact information can be provided depending on the origin of the request (i.e.: SP that is serving a given service to a given referencing user, a given referencing user, the particular service being served, etc.). In particular, an IdP can store one or more identifiers of one or more SPs which are allowed to serve a given service which consumes an attribute which can be obtained by first using this contact information. Also, an IdP can store identifiers of one or more referencing users who can be served with a service which consumes an attribute which can be obtained by first using this contact information, as well as identifiers of said services. Thus, before the IdP is going to provide back said contact information, it can check an identifier of the origin of the request (e.g.: requesting user and/or SP) as well as the identifier of the service to be provided to said origin; wherein some of those identifiers (or all) can be obtained from the IdP on its interaction with the requesting entity (requesting user and/or SP) . Similar policy rules to control the access to a RO for a given referenced user and a given service can be held in a DS apparatus. Thus, when the DS receives a discovery look-up operation from a SP, it can check whether the corresponding RO data can be provided back by checking the identifier of the requesting SP, the identifier of the particular requested service and, if available, an identifier of the requesting/referencing user.

Some exemplary embodiments for allowing the provision of a service to a referencing user (e.g. User 1), wherein said service needs to consume an identity service of a referenced user shall now be given with regard to the simplified flows depicted in figures 4 to 7. The simplified signaling flows which occurs between the entities depicted in said figures (SPs, DSs, IdPs and users) can be accomplished utilizing well known protocols utilized to provide web services today (such as HTTP or FTP) which, in turn, can embed further protocols (such as Simple Object Access Protocol, SOAP) used to envelope and data encoding to communicate information and requests across the Internet.

Fig.4 considers an scenario wherein one IdP is the IdP of both: the user who request the service (User 1) , and the user who is referenced by said service (User 2) . In step 401 SPl detects that for giving the required service to Userl related to another user, SPl needs some data or service from the other user and asks Userl to introduce the private identifier of said user. Userl introduce the private identifier of User2 and the SPl sends in step 402 an acquaintance request to the IdP to obtain the corresponding contact information. The private identifier provided by User 1 to SPl can be encrypted so as to hide its content to SPl, while allowing its decryption by the IdP (e.g.: encrypted using a public key of the IdP or a secret shared key between User 2 and the IdP) . Accordingly, the IdP can be provided with well-known means to decipher the received private identifier so as to find the corresponding contact information stored in relationship with it, and to answer back with said contact information in step 403. Alternatively, and for hiding the content of the private identifier to SPl, SPl can in step 402-1 redirect to User to enter the private identifier into the IdP; then the IdP can redirect back to User 1 to SPl in step 403-1, wherein said redirection comprises the corresponding contact information.

Once the requested contact information is available in SPl, SPl sends in step 404 a discovery look-up operation to the DS which comprises the received contact information and can also comprise the wanted RO for the needed identity service of User 2. The DS responds in step 405 to SPl with the necessary information to contact to SP2 and to point out there the necessary attribute (s) of said identity service. In step 406 the SPl ask to SP2 to perform the required service action. Said action, which can consume one or more of said attributes can comprise, for example, the retrieval or updating of some attributes (e.g. retrieval or updating of some calendar data of User 2), as well as the performance of some further service actions using them (e.g. sending of a Short Message or an e-mail to User 2 using an identity attribute stored in SP2 , such as his mobile phone number or e-mail URI, which notifies User 2 about, for example, an update on his calendar) . Finally, SP2 can return in step 407 a response to SPl, wherein said response can convey, depending on the requested service actions data about some concerned attribute (s) or, merely, a service acknowledgement .

Fig.5 shows various acquaintance embodiments to obtain the contact information for a given referenced user from an Identity Provider which does not contain said contact information. Before User 1 actually sends the referenced user's identifier to SPl, User 1 may wish to encrypt or cipher the referenced user's identifier. The encryption is carried out in such a way that only the requesting user and his IdP (or a similar centralised service like a DS) are involved on his knowledge; thus as a shared encryption key, public key infrastructure, or other can be utilized. This ensures that the referenced user's identifier (i.e.: his private identifier) is never understood by the requesting entity (e.g. an SP) for privacy reasons. This is advisable if the referenced user's identifier has a routable or addressable or meaningful value. The actual encryption dialogue and mechanism between the requesting user and the identity provider (or discovery service) can occur before the initiating contacts the requesting entity; it can be achieved via any of the current state-of-the-art procedures.

Once SPl, as requesting entity, has received the referenced user's private identifier from User 1 in a request (for instance, to perform a certain operation on referenced user's data such as update their calendar or contact book services) , SPl triggers the first step of the acquaintance profile mechanism towards the IdP with which the requesting entity has an agreement (IdPA) . The object is to determine if the IdP is acquainted with the private identifier that represents the referenced user and if so to additionally return an appropriate data for the referenced user and service at a given SP. Note that if the referenced user's identifier is encrypted or ciphered, this can be indicated in the message with a flag sent by the requesting user (User 1) to the requesting entity (SPl) and included in the acquaintance request along with a name identifier of the requesting user at the requesting entity. This would be enough information for the IdP to resolve the value to an unencrypted private identifier of the referenced user. If the original IdP (IdPA) that received the acquaintance request is not acquainted with the received private identifier, then it triggers the second step of the acquaintance process. The second step of the acquaintance profile requires the original IdP to send the acquaintance request towards other IdPs. The mechanism can be carried out by either of the following ways: sending the acquaintance request to all identity providers, either: in a sequential manner, or in a broadcast manner, or send the acquaintance request to a centralised Acquaintance Server that is able to determine the correct IdP that stores the DS contact information for the received private identifier. This implies that the Acquaintance Server is able to determine the referenced user's IdP by inspecting the private identifier of the referenced user received in the acquaintance request; it also implies that it has been provisioned in some way with this data.

Provisioning of identifiers of referenced user's in their IdP may occur in the manner described in Liberty ID-FF or via other means (e.g. user via SP requests identifiers to be created and provisioned in the IdP as explained earlier with reference to Fig.3). If a centralised approach is considered via an Acquaintance Server (or a pool of the latter) then each IdP can notify the Acquaintance Server whenever a new private identifier for a user is created, along with the IdP responsible for that identifier. The Acquaintance Server can thus only match a private identifier (such as an alphanumeric string) with an IdP but may not infer anything more about what the identifier represents. Although any notification mechanism will do (e.g. via fax, phone call, email, automated provisioning message) it would be beneficial to use a standardised a message for this purpose similar to the Register Name Identifier mechanism currently used between an IdP and an SP in LAP, although in this case used between the an IdP and Acquaintance Server.

From here on, and with reference to signaling flows depicted in figures 6 and 7, the IdP that sends the acquaintance request shall be referred as IdPA and the IdP that responds affirmatively as IdPB. Signaling flows 1 to 3 in Fig.6 are equivalents as the same described with reference to Fig.5. Once the acquaintance request reaches in flow 3 the correct identity provider (i.e. IdPB), the actions that occur could be as described next. IdPB determines the referenced user's discovery service (from here on DS-B) by inspecting the received private identifier of the referenced user and returns a value to the requesting entity SPl via IdPA in flows 4 and 5, that represents both the referenced user as well as his contact information in discovery service DS-B

(note: LAP calls this value a "ResourcelD" ) . In this flow 4, IdPB may need to include an authorisation token (issued by either IdPB or DS-B itself) back that authorises the requesting entity SPl to use a discovery service in dP-B's circle of trust (i.e. a discovery service with which the requesting entity has a priori no relationship) . The requesting entity SPl will then contact DS-B in flows 6 and 7 in a manner described by LAP to later on establish a relation with the referenced user's service provider or attribute provider (SP2) in IdP-B's CoT (as described previously with reference to steps 404 and 405 with reference to Fig.4). In this case, the requesting entity SPl would contact SP2 in flow 8 and include an obfuscated referenced user identifier received from DS-B which is usable to address the corresponding attribute (s) of the referenced user in SP2. As shown in Fig.6, the performance of the pertinent service action in SP2 can require User 2 ' s consent. The requesting entity SPl can store the returned obfuscated identifier of the referenced user to be used whenever it contacts SP2 on behalf of the requesting user User 1. Flows 8 and 9 in Fig.6 are then equivalent to flows 406 and 407 detailed earlier with reference to Fig.4.

Alternatively, instead of sending back a response to IdPA as shown in Fig.6, IdPB can contact DS-B and later to SP2 on behalf of requesting entity SPl. In this case IdPB can query DS-B regarding the service provider (or attribute) provider (SP2) for a given service or set of operations to be carried out on the referenced user (originally requested by the requesting user) , contacts said SP2 on behalf of the requesting entity and asks if the latter may execute a service or set of operations concerning the referenced user that involves SP2 that has been requested by the requesting user (this, as in the previous described case, might require consent from referenced user) . If the response is affirmative, IdPB can generate a pseudonym (if not already generated) that represents the referenced user and shares this pseudonym with SP2. Only IdPB and SP2 can correlate this pseudonym to who the referenced user is. IdPB finally returns an affirmative response (that is, these operations requested by the requesting user to be carried out on the referenced user are allowed) , the generated pseudonym and the address of SP2 back to the requesting entity, via IdP-A, in the acquaintance answer. The requesting entity SPl can then store the returned pseudonym of the referenced user User 2 to be used when contacting SP2 to carry out the operations demanded by the requesting user User 1 (and in this case alone, that is, a different requesting user value would return a different pseudonym value for the same referenced user at the same SP-B for the same set of operations) .

It shall be noted that either mechanism can be applied when User 2 is a group of users. Additionally, the flows only show the answer provided by the IdP that is acquainted with the name identifier that represents the referenced user. Erroneous answers are not shown but can be returned by either the Acquaintance Server or by each IdP. The acquaintance profile also provides a means for users to port their identities and identifiers between different IdPs without suffering any loss of service or any need to reconfigure their identifiers at the new IdP. It shall also be noticed that this solution does not consider porting identifiers between SPs although the idea can be extended to this. If a centralised Acquaintance Server is used that matches a given private identifier with an IdP, then it would suffice for a receiving IdP (the IdP that ported the user) to request that an identifier (or set of them) be updated to match the receiving IdP instead of the donor IdP. This operation could require explicit authorisation from the donor IdP. Otherwise a donor IdP could directly interact with a receiving IdP to carry out the identifier portability process. This mechanism is just as valid as the previous mechanism although a third party, such as a centralised Acquaintance Server (even if only used for administrative purposes) , can facilitate the portability process between IdPs. The actual porting of identifiers could be carried out via an existing message (such as Register Name Identifier) or a new message for this purpose. In any case the acquaintance profile relieves any requesting IdP to store any information about an unknown referenced user, thus it doesn't restrict user choices when selecting a new IdP.

An acquaintance flow representing an alternative embodiment of the one detailed with reference to Fig.6 is shown in Fig.7. Once User 1 requests in SPl a service which needs to consume User 2's attributes, User 1 is redirected in flow 1 to IdPA from SPl. Once in contact with IdPA, User 1 introduces a User 2's private identifier in step 3. Flows 3 and 4 of this figure are equivalent to flows 3 and 4 previously detailed with reference to Fig.6. Once the corresponding contact information for the DS-B is available, User 2 is redirected with this information back to SPl. Subsequent flows 6 to 9 are equivalent to flows having the same numeral and previously detailed with reference to Fig.6.

The signaling flow shown in Fig.8 exemplifies an embodiment to allow a referenced user User 2 to federate in the SP of an allowed referencing user User 1 (e.g. SPl) through an intermediate Service Provider. Although User 2 could federate directly into SPl, so as to allow SPl to provide an identifier to User 2 usable to identify said user in case of User 1 invokes a service which involves the consumption of attributes of an identity service hosted in e.g. SP2 , it could be desirable in some cases that User 2 does not contact directly to SPl. Thus, the idea behind this embodiment is to reduce the required interaction by User 2 (referenced user) with, for example, an undesired and/or non-trusted SP (e.g. SPl) simply for the purpose of communicating or interacting with User 1 (initiating user) in the context of an identity federation framework scenario providing identity services. This embodiment uses a SP as a dummy service provider (Dummy-SPl) that is in charge of technically enabling interaction between User 1 (initiating user) and User 2 (referenced user) in this context. Fig.8 depict the more general case in which both users, User 1 and User 2 are subscribed to different CoTs including different IdPs (IdP2 for User 2, and IdPl for User 1 and also for User 2 when federating through SP2) and DSs and have (or create) service accounts at different service providers (SPl and SP2) for the purpose of executing or receiving a common service or set of operations that involves both users. To put it in short, one could say that the dummy SP is in someway analogous to an interconnection service as it provides the necessary means for User 1, via SPl, to interact with SP2 when referencing User 2. The dummy SP can have a widely accepted and known URL (e.g. dummyservice.com or interconnectionservice.com) so that users registering there are not deterred from registering. Additionally, any cookie left by the dummy service provider to User 2 would be useless afterwards, as User 2 could no longer need to access the dummy SP after they have registered the first time.

Flows 1 and 2 in Fig.8 are standard federation flows of a user (User 2) through a SP (Dummy SPl) in an IdP (IdPl) . Once this federation is accomplished, both, IdPl and Dummy- SPl share a pseudonym to refer to User 2 (User2xyz) . Later as shown in flow 3, IdPl federates User 2 with IdP2 , and also, as a result of this further federation both: IdPl and IdP2, share a pseudonym to refer to User 2 (User2abc) . Next, in flows 3 and 4, Dummy-SPl register an identifier of User 2 in SPl (Pepita) . Later, in the subsequent flows illustrated in Fig.8, this identifier is utilized by the requesting user User 1 as a private identifier to refer to User 2 as described in any of the previous examples wherein the requesting user User 1 is not redirected from a SP to an IdP; however, although not shown in Fig.8, other flows wherein User 1 is redirected to an IdP, and redirected back to SPl can equally take place, as previously detailed with reference to figures 4 or 7.

The invention has been described in respect to some exemplary embodiments in an illustrative and non-restrictive manner. Variations can be readily apparent to those of ordinary skill in the art. For this reason, the invention is to be interpreted and limited in view of the claims.

Claims

1. An apparatus for providing a service from a Service Provider in an identity federation framework having: means to receive a service request from a first user requesting a service, means to obtain a first resource offering in relationship with an identity service of said first user by using first contact information associated to said first user obtained as a result of his authentication by an Identity Provider, and means to provide said service to said first user; CHARACTERIZED in that, for providing a service to said first user, it further comprise: means to request a second contact information in relationship with a private identifier of a second user, means to obtain a second resource offering in relationship with said second contact information, and means to request a service action for an attribute in relationship with said second resource offering.

2. The apparatus of claim 1, wherein said means to request a second contact information comprise means to redirect said user to an Identity Provider to enter said private identifier in said Identity Provider.

3. The apparatus of claim 2, wherein the means to obtain said second resource offering comprise: means to receive said second contact information from said user further redirected from said Identity Provider, and means to send a discovery look-up operation to a Discovery Service using said second contact information.

4. The apparatus of claim 1, wherein said means to request a second contact information comprise: means to receive said private identifier encrypted in a service request from said first user, and means to send an acquaintance request to an Identity Provider comprising said received encrypted private identifier.

5. The apparatus of claim 4, wherein the means to obtain said second resource offering comprise: means to receive said second contact information from Identity Provider as a result of said acquaintance request, and means to send a discovery look-up operation to a Discovery Service using said second contact information.

6. An Identity Provider apparatus in an identity federation framework having: means to store a plurality of pseudonyms of a first user federated through a plurality of Service Providers, means to store contact information in relationship with said plurality of federated pseudonyms and usable to obtain a resource offering for an identity service of said first user, and means to authenticate said first user when accessing a Service Provider and to provide said contact information to said Service Provider as a result of said authentication; CHARACTERIZED in that, for providing a service to a second user which can consume an identity service of said first user, it further comprises: means to store a private identifier of said first user in relationship with said contact information, means to receive a contact information request requesting the contact information in relationship with the private identifier of a first user to provide a service to a second user in a Service Provider, and means to provide said contact information at reception of said request.

7. The apparatus of claim 6, wherein said means to receive said contact information request comprise means to receive a redirection of said second user from a Service Provider which provides a service to said second user, and wherein said private identifier is received from said second user redirected from said redirecting Service Provider.

8. The apparatus of claim 7, wherein said means to provide said contact information comprise means to redirect said second user back to said redirecting Service Provider, said redirection comprising said contact information.

9. The apparatus of claim 6, wherein said means to receive said contact information request comprise means to receive an acquaintance request containing said private identifier from a Service Provider which provides a service to said second user, and wherein said means to provide said contact information comprise means to send an acquaintance response back to said Service Provider which comprises said contact information.

10. The apparatus of claim 9, wherein said private identifier is received encrypted in said acquaintance request, further comprising means to decrypt said encrypted private identifier.

11. The apparatus of any of claims 6 to 10, wherein said means to provide the contact information in relationship with the private identifier of a first user further comprise means to send an acquaintance request containing said private identifier to another Identity Provider.

12. The apparatus of any of claims 6 to 11, wherein the means to store a private identifier of a first user further comprises means to receive said private identifier from an identity service registration from a Service Provider providing an identity service to said first user.

13. The apparatus of any of claims 6 to 12, wherein a private identifier of said first user is further stored in relationship with at least one identifier selected from: an identifier of at least one allowed Service Provider, an identifier of at least one allowed second user, an identifier of at least one allowed given service, and wherein said means to provide said contact information to provide a service to a second user, further comprise means to check at least one condition among : whether a Service Provider sending or redirecting said request for a second user is an allowed Service Provider, - whether said second user is an allowed second user, whether a service to be provided to a second user is an allowed service, to determine whether or not said contact information can be provided.

14. An apparatus for providing a Discovery Service in an identity federation network having: means to store a resource offering in relationship with an identity service of a first user, means to receive a discovery look-up request from a Service Provider to provide a service to said first user, and means to provide said resource offering at reception of said discovery look-up request; CHARACTERIZED in that, to control the provision of said resource offering for providing a service to a second user, said resource offering is further stored in relationship with at least one identifier selected from: an identifier of at least one Service Provider allowed to request said resource offering for providing a service to a second user, an identifier of at least one allowed second user, and said means to provide said resource offering further comprise means to check at least one condition among: whether a Service Provider sending said discovery look-up request is an allowed Service Provider, whether said second user is an allowed second user, to determine whether or not said resource offering can be provided.

15. The apparatus of claim 14, wherein said means to store a resource offering in relationship with an identity service of said first user further comprise: means to receive an identity service registration from a Service Provider providing said identity service for said first user, said service registration comprising a private identifier for referencing said identity service of said first user, and means to send said private identifier to an Identity Provider in relationship with the contact information of said first user.