Identity based service system

Abstract

An identity based service system is provided, in which an identity is created and managed for a user or principal, such that at least a portion of the identity is available to use between one or more system entities. A discovery service enables a system entity to discover a service descriptor, given a service name and a name identifier of the user, whereby system entities can find and invoke the user's other personal web services. The discovery service preferably provides a translation between a plurality of namespaces, to prevent linkable identity information over time between system entities.

Description

FIELD OF THE INVENTION

The invention relates to the field of network based services and structures. More particularly, the invention relates to identity creation, management, authentication, and authorization structures for enhanced network services.

BACKGROUND OF THE INVENTION

At the present time, the identity of an individual or user in a network environment, such as the Internet, is comprised of a large number of pieces of information, which is collected and recollected by a large number of entities. Some basic information regarding an individual, such as but not limited to name information, address information, identification information, financial information, profile information, and or preference information, is repeatedly collected and stored at a large number of system entities. Additional information, such as a user name and password, is created, as necessary, such that the individual or user can sign on and/or gain access to a service provider.

A large number of pieces of an individual's business and personal identity are therefore scattered across an increasing number of system entities, such as but not limited to commercial entities, banking and investment institutions, credit card companies, service providers, and/or educational institutions.

Individuals are therefore required to repeatedly enter much of the same information, in the process of numerous professional and/or personal endeavors. Furthermore, as the information for an individual changes, the stored information becomes increasingly impractical to manage and/or update. In addition, the numerous user names and passwords associated with an individual quickly becomes unwieldy, such that users often forget or lose track of the information they need to access services and/or accounts.

Several structures and methods have been described for identity and proxy-based networks, such as:

• E. Gabber, P. Gibbons, Y. Matias, and A. Mayer, System and Method for Providing Anonymous Personalized Browsing by a Proxy System in a Network, U.S. Pat. No. 5,961,593, 05 Oct. 1999, describes a system “For use with a network having server sites capable of being browsed by users based on identifiers received into the server sites and personal to the users, alternative proxy systems for providing substitute identifiers to the server sites that allow the users to browse the server sites anonymously via the proxy system. A central proxy system includes computer-executable routines that process site-specific substitute identifiers constructed from data specific to the users, that transmits the substitute identifiers to the server sites, that retransmits browsing commands received from the users to the server sites, and that removes portions of the browsing commands that would identify the users to the server sites. The foregoing functionality is performed consistently by the central proxy system during subsequent visits to a given server site as the same site specific substitute identifiers are reused. Consistent use of the site specific substitute identifiers enables the server site to recognize a returning user and, possibly, provide personalized service”;
• Proxy-Based Security Protocols in Networked Mobile Devices; M. Burnside, D. Clarke, T. Mills, S. Devadas, and R. Rivest; MIT Laboratory for Computer Science; event,declarke,mills,devada,rivest@mit.edu;
• SPKI/SDSI http Server/Certificate Chain Discovery in SPKI/SDDI; D. Clarke; MIT Laboratory for Electrical Engineering and Computer Science, September 2001;
• Grid Information Services for Distributed Resource Sharing; K. Czajkowski, S. Fitzgerald, I. Foster, C. Kesselman; Proc. 10^th IEEE Symposium on High-Performance Distributed Computing, 2001;
• Certificate Discovery Using SPKI/SDSI 2.0 Certificates; J. Elien; MIT Department of Electrical Engineering and Computer Science; May 1998; and
• Local Names in SPKI/SDSI; N. Li; NYU Department of Computer Science; Proceedings of the 13^th IEEE Computer Security Foundations Workshop.

Other systems provide various details of the operation of network identity and proxy systems, such as U.S. Pat. No. 6,460,036, System and Method for Providing Customized Electronic Newspapers and Target Advertisements; U.S. Pat. No. 6,029,195, System for Customized Electronic Identification of Desirable Objects; U.S. Pat. No. 5,835,087, System for Generation of Object Profiles for a System for Customized Electronic Identification of Desirable Objects; U.S. Pat. No. 5,754,939, System for Generation of User Profiles for a System for Customized Electronic Identification of Desirable Objects; U.S. Pat. No. 5,754,938, Pseudonymous Server for System for Customized Electronic Identification of Desirable Objects; U.S. Pat. No. 6,490,620, Integrated Proxy Interface for Web Based Alarm Management Tools; U.S. Pat. No. 6,480,885, Dynamically Matching Users for Group Communications Based on a Threshold Degree of Matching of Sender and Recipient Predetermined Acceptance Criteria; U.S. Pat. No. 6,473,407, Integrated Proxy Interface for Web Based Alarm management Tools; U.S. Pat. No. 6,421,733, System for Dynamically Transcoding Data Transmitted Between Computers; U.S. Pat. No. 6,385,652, Customer Access Solutions Architecture; U.S. Pat. No. 6,373,817, Chase Me System; U.S. Pat. No. 6,338,064, Method for Enabling a Web Server Running a “Closed” Native Operating System to Impersonate a User of a Web Client to Obtain a Protected File; U.S. Pat. No. 6,259,782, One-Number Communications System and Service Integrating Wireline/Wireless Telephone Communications Systems; U.S. Pat. No. 5,974,566, Method and Apparatus for Providing Persistent Fault-Tolerant Proxy Login to a Web-Based Distributed File Service; European Pat. No. EP 1094404, Collaborator Discovery Method and System; European Pat. No. EP 1031206, Identity Discovery method for Detecting Authorized Security Service Which is Illicitly Transferring Decoding Capabilities for use in Unauthorized Security Devices; The Session Initiation Protocol: Internet-Centric Signaling; H. Schulzrinne, J. Rosenberg; IEEE Communications Magazine; October 2000; How Bluetooth Embeds in the Environment; Lawday, G.; Electronic Product Design; November 2001; and Business: Designing with Users in Internet Time; J. Braiterman, S. Verhage, and R. Choo; Interactions: September-October 2000.

It would be advantageous to provide an identity based service system, which does not require a user to create a user identity for each participant. The development of such an identity based service system would constitute a major technological advance.

Furthermore, it would be advantageous to provide an identity based service system, which allows a user to create an identity that can be controllably accessed and shared by a plurality of participants. The development of such an identity based service system would constitute a further technological advance.

As well, it would be advantageous that such an identity based service system be integrated with existing site authentication and authorization structures, such that the identity based service system is readily used by a wide variety of sites. The development of such an identity based service system would constitute a further major technological advance.

SUMMARY OF THE INVENTION

An identity based service system is provided, in which an identity is created and managed for a user or principal, such that at least a portion of the identity is available to use between one or more system entities. A system entity is able to discover a service descriptor, such as through a discovery service, given a service name and a name identifier of the user, whereby system entities can find and invoke the user's other personal web services. A translation is preferably provided between a plurality of namespaces, to prevent linkable identity information over time between system entities.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a basic functional block diagram for an identity based service system, in which a participant accesses services for a principal;

FIG. 2 is a flow diagram for the access of service within an identity based service system;

FIG. 3 is a functional block diagram of an identity based service system, comprising a discovery service associated with a basic authentication agency, a service provider, and a service consumer;

FIG. 4 is a flow diagram for the access of service within an identity based service system comprising a discovery service associated with a basic authentication agency, a service provider, and a service consumer;

FIG. 5 is a functional block diagram of an identity based service system, in which a discovery service issues service assertions that are used to invoke services;

FIG. 6 is a flow diagram for the access of service in the identity based service system shown in FIG. 5;

FIG. 7 is a functional block diagram of profile service principal core information;

FIG. 8 is a functional block diagram of a profile data entry;

FIG. 9 is a schematic view of an identity based service system configured on a virtual network;

FIG. 10 is a functional block diagram of a core authentication record;

FIG. 11 is a functional block diagram of multiple core authentication records which are maintained on behalf of a plurality of identities for a user;

FIG. 12 is a functional block diagram of multiple core authentication records maintained on behalf of a user, based upon system access through different devices;

FIG. 13 is a schematic view of namespace translation within the identity based service system;

FIG. 14 is a first schematic view of operation for an identity based service system, in which user logs onto a first participant site;

FIG. 15 is a second view of operation for an identity based service system, wherein a users may select system site links and/or system service links; and

FIG. 16 is a third view of operation for an identity based service system, in which a system identity is established at a basic authentication agency.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 is a basic functional block diagram for an identity based service system 10a, in which a participant 16 accesses services for a principal 12, such as a user or individual U (FIG. 11, FIG. 12, FIG. 14). FIG. 2 is a flow diagram 30 for the access of service within an identity based service system 10. In FIG. 1, the system entities 27 comprise a basic authentication agency 14, a participant 16, and a principal 12. The system entities 27 assume roles within the identity based service system 10.

A principal 12, such as a user, user agent, is an entity 27 that can acquire a system identity 29, and be authenticated and vouched for 19 by a basic authentication agency (BAA) 14. A principal 12 often comprises a user or individual, using a user agent, either a web browser or a smart web services client.

A basic authentication agency (BAA) 14 authenticates and vouches for principals 12, and provides system management for system identities 29. A participant 16 provides service to one or more requesters, such as principals 12 or other participants 16, typically through a service consumer 48 (FIG. 3), upon proof of authentication 19 by the basic authentication agency 14.

The identity based service system 10a shown in FIG. 1 provides a web services-based service infrastructure that enables users U to manage the sharing of their personal information across a basic authentication agency 14 and participants 16. In some system embodiments 10, the system 10 also provides one or more personalized services 116, e.g. 116a, 116b, 116c, . . . 116n (FIG. 9) for users U (FIG. 11).

For example, a user U, through a principal 12, is able to authorize a participant 16 to access his or her contact data 94a (FIG. 7), such as shipping address data 96, e.g. 96a (FIG. 7), while processing a transaction. Principals 12 are able to use sophisticated clients that support web services, in addition to traditional browser-oriented user agents. In some system embodiments, web services are defined as simple object access protocol binding (SOAP) over HTTP calls, comprising header blocks and processing rules, which enable the system 10 to invoke identity services 116, through SOAP requests and responses.

The identity based system framework 10 enables participants 16 and other system entities 27 to craft and offer sophisticated services, including multi-provider-based services 116, e.g. 116a, 116b, 116c, and/or 116n (FIG. 9).

As seen in FIG. 1 and FIG. 2, a principal 12, such as a user or user agent, logs in 18 and receives a BAA assertion 19 from the basic authentication agency 14. The principal 12 then authenticates 20 at the participant 16, with the received BAA assertion 19. The participant 16 then requests 22 a service descriptor 26 and assertion for service 28 at the basic authentication agency 14. Based upon the request 22, the participant 16 receives 23 the service descriptor 26 and assertion for service 28 from the basic authentication agency 14. The participant 16 then invokes service 24 with the received assertion for service 28, such as at the basic authentication agency 14, or with an associated system entity 27, e.g. such as a service provider 54 (FIG. 3, FIG. 5).

FIG. 3 is a functional block diagram of an identity based service system 10b, which further comprises a discovery service 42 associated with the basic authentication agency 14, a service provider 42, and a service consumer 48. FIG. 4 is a flow diagram 60 for the access of service within an identity based service system 10b.

As seen in FIG. 3 and FIG. 4, a principal 12, such as a user or user agent, logs in 18 and receives 19b a BAA assertion and discovery service descriptor from the basic authentication agency 14. The principal 12 then authenticates 44 at the participant 16, with the received BAA assertion and discovery service descriptor 19b. The service consumer 48 associated with the participant 16 then requests 50 a service descriptor 26 and assertion for service 28 at the basic authentication agency 14, such as through a discovery service 42 associated with the basic authentication agency 14. Based upon the request 50, the participant 16 receives 51 the service descriptor 26 and assertion for service 28 from the basic authentication agency 14 or associated discovery service 42. The participant 16 then invokes service 52, e.g. 52a (FIG. 4), with the received assertion for service 28, at a service provider 54.

A service provider (SP) 54 hosts personal web services 116 (FIG. 9), such as a profile service 116b (FIG. 9), while a service consumer (SC) 48 invokes web services 116 at service providers SP 54. With appropriate identification and authorization, a service consumer 48 is able to access the user's personal web services 116, by communicating with the service provider endpoint 54.

As seen in FIG. 3, the basic authentication agency BAA 14 provides authentication 19, e.g. 19b, the principal 12, based upon a successful log in 18. The principal 12 then interacts with the participant 16, and relays the authentication information 19, comprising a BAA assertion 45 and a discovery service descriptor 26.

The participant SP 16, acting as a service consumer 48, uses the discovery service 42, to determine whether the principal 12 is enabled for a particular service 116, and to obtain the necessary assertions which authorize use of the service 116. The policy framework addresses whether the principal 12 is enabled for some particular service, and if so, what fine-grained methods are allowed, and what data is to be returned. Web service security is typically applied to all messages flowing between system entities 27.

As seen in FIG. 3, the identity based service system 10b comprises a web-service infrastructure, which comprises the discovery service 42, service invocation 52, e.g. 52a, a permission and authorization framework, a change management framework, as well as a mobile infrastructure.

In some system embodiments 10, service consumers 48 are hosted on a server at a participant 54. In alternate system embodiments 10, service consumers 48 are hosted on a user device 192 (FIG. 14, FIG. 15, FIG. 16).

A discovery device (DS) 42 is typically hosted by a basic authentication agency (BAA) 14, and enables service consumers 48 to discover service endpoint information 96 (FIG. 7) associated with the personal web services 116 of a user U.

Architectural Components. The identity based service system 10 comprises the following architectural components:

• • Services. A service is a grouping of common functionality. For example, a core profile service 116b (FIG. 9) handles all interaction to do with user profile information 96. Services typically offer one or more methods callers use to manipulate the information managed by the service, and are typically scoped in the context of a particular principal 12, e.g. GetProfile (Principal) accesses the principal's entire set of profile data.
  • Services may be either RPC-style or one-way exchanges. In RPC-based exchanges, the Service Consumer 48 is, the requester 50, and the Service Provider 54 is the responder 51.
  • Schemas. Schemas describe the syntax and relationships of data. Each service element 116 comprises an associated schema for the data that is relevant to the service element 116. For example, the profile service 116b comprises schema elements 96 which are relevant to a profile 94, such as but not limited to a name, an address, and a phone number for a user U.
  • System Entity Roles. System Entities 27 may assume one or more roles.

As seen in FIG. 3, service descriptors 26 are used to locate a system service 54, while service assertions 28 are used as credentials, to access the system service 54. A service descriptor 26 typically describes a SOAP endpoint for an identity based system service 54. A service assertion 28 is an assertion used as a credential to access an identity based system service 54.

Discovery Service Overview. In the identity based service system 10, the personal web services 116 for a user U are preferably distributed across multiple service providers 54. Therefore, service consumers 48 include a means for discovering service locations 54. The discovery service 42 is a personal web service which enables system entities 27 to discover a service descriptor 26, given a service name and a user's name identifier 174 (FIG. 13) or identity assertion 29, whereby a service consumer 48 is able to find and invoke the web services 54 of a user U.

FIG. 5 is a functional block diagram 70 of an identity based service system 10c, in which a participant 16, such as through a discovery service 42, issues service assertions 28 that are used to invoke services 54, such as at a service provider 118, such as but not limited to bank and/or credit card services 118j. FIG. 6 is a flow diagram 80 for the access of service 54 in the identity based service system 10c shown in FIG. 5. As seen in FIG. 5, FIG. 10, FIG. 11, and FIG. 12, a core authentication record (CAR) 132 is associated with a user identity 29, and is maintained on behalf of a user U.

As seen in FIG. 5 and FIG. 6, a principal 12, such as a user or user agent, logs in 18 and receives 19b a BAA assertion and discovery service descriptor from the basic authentication agency 14. The principal then authenticates 44 a participant 16 that is associated 46 with the basic authentication agency 14, with the received BAA assertion and discovery service descriptor 19b. The participant 16, either directly or through an associated service consumer 48 (FIG. 3), then requests 50 a service descriptor 26 and assertion for service 28 at the basic authentication agency 14, either directly or though a discovery service 42.

Based upon the request 50, the participant 16 receives 51 the service descriptor 26 and assertion for service 28 from the discovery service 42. The participant 16 then invokes service 52, e.g. 52a (FIG. 4), with the received assertion for service 28, at a site or service provider 54, such as at a service provider 118, e.g. 118j, that is associated 72 with the basic authentication agency 14,116a.

System Operation. The identity based service system 10, such as the system 10c shown in FIG. 5, is readily implemented to provide enhanced value for users U. For example, a principal 12, such as a user U at a terminal 192, may initiate a checkout at a bookstore site 120 that is a participant 16 within the system 10c. During the checkout, the participant 16,120 typically requests 50 a service descriptor 26, e.g. a wallet provider 118j and a service assertion, i.e. ticket 28, from the basic authentication agency BAA 14,116a, such that payment can be authorized. Upon a proper request 50, the BAA 14,116a sends 51 the requested service descriptor 26 and ticket 28 to the participant store 16,120. The participant store 16,120 then contacts the service provider 54, e.g. the wallet provider 118j, and invokes service 52b, by passing the ticket 28 to the wallet provider 118j. The wallet provider 118jprocesses the request 52b, and sends the results to the participant store 16,120, such that the checkout is either authorized or denied.

Because of the pseudonymous identity of users in the identity based service system 10, service consumers 48 and service providers 54 do not have a common name for a user U. The basic authentication agency 14 of a user U is the system entity 27 that maps between the disparate namespaces 176,182 (FIG. 13). As seen in FIG. 13, the discovery service 42, which is hosted by the basic authentication agency 14, provides this namespace translation.

The service consumer 48 prompts the name translation service, by sending the user's name 174a in the WSC-BAA namespace 176, to the basic authentication agency 14. The basic authentication agency 14 hands back a user name 174b in the WSP-BAA namespace 182, within a format that the service consumer 48 is blinded to this name, via encryption 184. The encrypted value 184 of the name 174b is preferably different each time the name 174a,174b is used, such that there is no linkable identity information over time between the service consumer 48 and the service provider 54. This name translation assertion 28 is also preferably time-bound, to prevent long-term use of a translated name 174b, and to prevent linking of the actions of a principal 12.

In the identity based service system 10, the user's basic authentication agency 14 always hosts the discovery service 42, since the discovery service 42 must be aware of the pair-wise identifier relationships 174a,174b between parties 27.

In response to a discovery request, the service 42 returns 52 a service descriptor 26 that points to a particular service provider 54: Additionally, a translated name 174b and relevant security tokens 186 (FIG. 13) are typically included as well. Some discovery services 42 enforce user presence requirements on service consumers 48, and/or enforce one or more authorization rules on each service consumer 48.

The discovery service 42 also provides an administrative interface, whereby a set of services 116 for a user can be configured. Services may be registered and unregistered.

Profile Service. FIG. 7 is a functional block diagram 90 of principal core information 92. A profile service 116b (FIG. 9) manages the core personal information 92 for a principal 12. The core personal information 92 typically comprises a plurality of data types 94a-94n, such as contact data 94a, demographic data 94b, and/or core preferences 94n.

A profile service 116b (FIG. 9) allows principals 12 to create a profile 92, to update profile data 94a-94n, and to specify privacy controls 98. Once a user creates a profile 92, the profile 92 can be used at any of the system service consumers 48, such that principals 12 are not required to re-enter data, such as on a registration form.

FIG. 8 is a functional block diagram of a profile data entry. Each profile data entry 96 is typically associated with a collection of metadata 107, comprising but not limited to data categories 102, change timestamp information 104, data validation information 106, and/or creator information 108.

Data category information 102 allows information to be classified as applicable, such as to define a home or business profile. For example, an address can be classified as a home and/or a business address. Data categories 102 are typically defined by service providers 54, by service consumers 48, and/or by principals 12.

Change timestamps information 104 typically comprises a number 105, e.g. 105a, which represents the latest modification time of a particular node and associated descendants.

Data validation information 106 comprises an indication of whether the data content 94 has been validated or not. If the data content 94 is validated, the information may preferably comprise what type of validation was performed, and when the validation was performed. A service consumer 48 typically uses metadata 107.

FIG. 9 is a schematic view 110 of an identity based service system 10 configured on a virtual network 112. The virtual network 112, provides a single set 114 of services 116a-116n, which are provided by one or more contributors 118a-118j. The virtual network 112 formed within the identity based service system 10 provides one or more core services 116.

In some basic embodiments of the identity based service system 10, the core services comprise a basic authentication service 14,116a. In alternate basic embodiments of the identity based service system 10, the core services comprise both an authentication service 116a and a profile service 116b. In some preferred embodiments of the identity based service system 10, the core services comprise a variety of services, such as an authentication service 14,116a, a profile service 116b, an alert service 116c, and/or a wallet service 116n.

The identity based service system 10 also supports other value-added services 116 for a user, such as a calendar service and/or an address book service. The identity based service system 10 provides access 54 for a wide variety of participant sites 120a-120k, such as large business sites 120a and/or small business sites 120k.

As seen in FIG. 9, service consumers 48 comprise sites which use services 116 from the network 112. As seen through a site 120, the services 116 presented by the virtual network 112 preferably look like a single set 114 of services 116, i.e. from a single provider 118 of services, even though the services are typically provided by any number of contributors 118a-118j.

The core service provider 118b shown in FIG. 9 provides one or more core services 116, e.g. 116a-116n, on the virtual network 112. While some basic services, such as a profile service, are currently available through some Internet providers, such services are separate and distinct. In the identity based service system 10, the various services 116, e.g. 116a-116n, are aware of each other and of the virtual network 112.

As seen in FIG. 9, the identity based service system 10 preferably comprises a plurality of service contributors, i.e. vendors 118a-118j. While different 118 vendors typically contribute different sets of varying services 116, the source of a service 116 is typically transparent to users U as they interact with the recipient sites 120.

Levels of Trust and Integration. The identity based service system 10 preferably provides varying levels of trust and integration. For example, as seen in FIG. 9, a small retail site 120k typically comprises a low level of trust, such that a user U is typically asked to confirm transactions, through redirect exchanges with the system 10.

A larger site 120, such as a large retail site 120a or an auction site 120b, which is integrated with the network 112 and is able to perform tasks on behalf of the user U, e.g. get money from a wallet 116n, typically has a higher level of trust with the system 10.

Core service providers 118, such as providers 118a-118j of core services 116, typically have a high level of trust with the system 10, and are able to perform system functions on behalf of a user U. In addition, core service providers 118 which provide authentication 116a have the highest level of service requirements, and inherently require the highest level of trust within the system 10.

Service Invocation. In order to enable interactions between multiple endpoints within a circle of trust, the discovery service 42 issues service assertions 28 (FIG. 3, FIG. 5) that can be used by service consumers 48, such as to access other participants 54.

In some embodiments of the identity based service system 10, messages can be routed and be transported through multiple hops. Additionally, message-level confidentiality is employed for sensitive data in multi-hop cases where confidentiality is required.

A target service provider 54,118 does not simply consume the service assertion 28. Relevant policy is enforced to ensure that the service invocation is in line with the principal's policies.

Authentication. Most system services require requester authentication. Additionally, the response is authenticated. For example, a user authentication comprises a determination of the identity 29 of a user U. Online authentication can take many forms, such as a stored browser cookie, a user name/password combination, or stronger technologies such as smart cards or biometric devices.

In the identity based service system 10, the user's identity 29 is authenticated, in accordance with privacy and security policies. The evidence of authentication for a user U comprises the user identity 29, in addition to assertions of authentication strength. The evidence of authentication for a user U refers to stored and/or passed data that indicates that a user is authenticated, and which can be interrogated to verify the authentication.

As an example, web sites often store a cookie to provide personalization information about their site for the user. However, for e-commerce transactions, that same web site may require a user to explicitly supply an ID 196 (FIG. 14) and password 198 (FIG. 14). While both stored cookies and ID/passwords are authentications, an ID/password authentication is stronger than an authentication provided by a stored cookie. The use of different forms of authentication allows a site to balance user convenience with its security policies, as needed.

System Authorization. While user authentication determines the identity 29 of the user U, authorization is the process of determining what an authenticated user U is allowed to do, and the determination any services and/or entities 27 which are allowed to act on behalf of the user U.

For example, a web site that provides access to bank account information may be configured to allow only the primary account holder to transfer funds to/from the account, but allow all members of the family to view the current account balance. While each user U is authenticated, only one user U is able to perform authorized activities.

Another example would be that of a network payment service (or smart wallet) 116n (FIG. 9, FIG. 10), which contains credit card information and/or cash account information 118. A user U of a wallet service 116n can controllably authorize a participant 16 to access credit card information and/or cash account information. In this case, the user U is authenticated, and authorized to control the payment service, while the participant 16 is also authenticated, but authorized only to access the credit card information.

As shown above, some embodiments of the identity based service system 10 feature a delegation of authorization, wherein a user U is not required to navigate to a payment site to authorize a transaction. For example, while a user U shops at a web site 120, during a checkout process, a system enabled web site 120 may access the payment/wallet service 116n, on behalf of the user U, wherein the user has delegated authorization to the web site to act on his behalf with the payment service 116n.

User Identities. In the identity based service system 10, an identity 29 of a user U comprises a persona for that user. FIG. 10 is a functional block diagram of a core authentication record (CAR) 132, which is maintained on behalf of a user U, such as by the basic authentication agency 14. FIG. 11 is a functional block diagram of multiple core authentication records (CAR) 132a,132b, which are maintained on behalf of a user U. Some preferred embodiments of the identity based service system 10 comprise support for multiple identities 29, i.e. personifications or personas, for a user U, wherein a user may interact differently, such as within different environments. As seen in FIG. 11, a user U can preferably have more than one identity 29. For example, a user U can have one identity 29 for personal information, another identity 29 for business information, and a third identity for “anonymous” service access.

The use of multiple identities 29 allows users U to store relevant information associated with each identity 29, and use or expose the information only as needed. For example, as seen in FIG. 11, “Financial Entity A” 118j, such as corporate credit card information 118j, is associated with a first entity 29a, e.g. business identity 29a, for a user U, and is located in the wallet 116n within work authentication record 132a. However, the “Financial Entity A” corporate credit card information 118j shown in FIG. 11 is not associated with a second entity 29b, e.g. home or personal identity 29b, for the user U, and is therefore not located in the wallet 116n associated with the home or personal authentication record 132b.

Similarly, an “anonymous” identity 29 would typically comprise no personally-identifiable information, enabling use of that identity 29 in appropriate situations.

Scopes of Authentication. Network authentication occurs when a user's evidence-of-authentication 19, e.g. 19b (FIG. 4), are issued by a network authentication service 116a (FIG. 10), and enables a user U to access sites and services on the network 112. This enables single-sign on features, wherein all network participants accept network evidence-of-authentication, in accordance with their own site policies, e.g. level of authentication required, and in accordance with user opt-in choices:

In addition, a local authentication may occur, such as when evidence of authentication for a user U is issued by a local site/service, using its own authentication facilities, wherein the evidence of authentication is only valid for that specific site or service. A local authentication does not inherently carry with the user U from one site to another, and does not allow the site or service to access network services on behalf of the user U.

Some embodiments of the identity based service system 10 provide both forms of authentication, whereby the system 10 can be integrated with sites that already have an authentication system.

Requester identity, such as that of a web consumer 48, is established by the inclusion of a security token 186 (FIG. 13), which represents the identity of the requester, and the signing of relevant portions of the message with the key material implied by the security token 186. The security token 186 may be an X.509 certificate, a Kerberos ticket, an SAML assertion, a username & associated password, or any other valid security token 186, as deemed necessary by the service provider 54. Additionally, a replay protection is preferably employed, such as a nonce-based challenge-response protocol, a timestamp included in the signature, or other replay protection mechanism.

The responder's identity can be authenticated, such as by validating that the signature of the response (containing the original RequestID) is authentic.

Long-Lived Access to Services. In some alternate system embodiments 10, pursuant to the approval of a user U, the discovery service 42 assures long-lived service assertions to a service consumer 48, such that the service consumer 48 can repeatedly invoke a service at the service provider 54. Continual acceptance of the service assertion 28 at the service provider 54 is dependent on user approval of continued access of the service at the service provider 54. Long-lived access may also be employed to allow services 27 to act on behalf of the user U even when the user U is not present.

However, in system embodiments 10 wherein revocation is preferred to be controlled by the basic authentication agency 14 and associated discovery service 42, the discovery service 42 prevents long-lived service assertions to a service consumer 48.

Service Infrastructure. While current system embodiments 10 comprise a profile service (PS) 116 (FIG. 9), the identity based service system 10b preferably comprises a complete services infrastructure, such that the profile service 116, as well as other services, may be built on top of web service standards.

For example, the infrastructure is typically accessible via SOAP over HTTP calls, as defined by WSDL descriptions, and use agreed-upon schemas, such that the web services infrastructure transparently supports both static and dynamic data. An example of static data is a basic profiling service that returns an e-mail address. An example of dynamic data is that of an infrastructure served by a calendar service, which return calendar appointments.

Services, which for example may include a user's profile 116b, wallet 116n, or calendars/alerts 116c, typically comprise a set of logically related functionality, and comprise collections of attributes and service calls.

Core Authentication Records. The core authentication record (CAR) 132 shown in FIG. 10 is maintained on behalf of a user U, such as by the basic authentication agency 14. The core authentication record 132 comprises links 136,140 to sites 120a-120k which are associated through the identity based service system 10. The core authentication record 132 is also linked to an ACL or other access control mechanism 134, and to services 138, such as core services 116, as provided by core participants 118 or other web services operating within the identity based service system 10.

As seen in FIG. 11, one or more core authentication records (CAR) 132, e.g. 132a,132b, may preferably be maintained on behalf of a user U, in embodiments of the identity based service system 10 which comprise support for multiple identities 29, i.e. personifications or personas, for a user U, wherein a user may interact differently, such as within different environments.

For example, users U often look at their work personification as different and distinct from their home personification, with different sites 120 visited, different credit cards 116n, and sometimes even different alert mechanisms 116c.

As seen in FIG. 11, multiple core authentication records (CAR) 132a,132b are preferably supported by the identity based service system 10, whereby a user U selectively logs in 18 to one or more core authentication records 132.

The links 136 also preferably include quick-links 140 between accounts 132. Once as user U logs in 18 to either account 132, they can switch between the accounts 132, e.g. from 132a to 132b, on an as needed or as desired basis, without logging in 18 again. For example, as seen in FIG. 11, a user U within a work authentication record 132a can link 140d to the associated home authentication record 132b for the user U. Similarly, the user U within a home authentication record 132b can link 140g to the associated work authentication record 132a for the user U.

FIG. 12 is a functional block diagram 160 of multiple core authentication records (CAR) 132a,132b, which are maintained on behalf of a user U, based upon the use of different devices 192a,192b (FIG. 14). The identity based service system 10 also preferably comprises support for multiple devices 192 for a user U, wherein a user logs on 18 to the system through any of a plurality devices 192, such as through a desktop computer 192a in an office, or through a mobile device 192b at any location.

While the user U may retain a similar identity while operating different devices, such as a work identity, the chosen services 138,116 and links 136,140 linked to the authentication records 132a,132b may be chosen or selected as suitable for the device 192. For example, an extended alert list 116c may be linked to a desktop computer 192a, while an abbreviated alert list 116c be linked to a mobile device 192b, such as a personal digital assistant 192b, or an Internet enabled cell phone 192b. Similarly, a wide variety of web site links 140 may be linked to a desktop computer 192a, while only a few key web site links 140 may be linked to a mobile device 192b.

While much of the identity 29, services 116, and/or core providers 118 may be shared between authentication records 132a, 132b in FIG. 12, the authentication records 132a,132b provide a customized operating environment for a user U, which is based on the device 192 from which the user U logs in 18.

System Advantages. The Identity based service system 10 provides significant advantages over conventional identity and service structures. Through the establishment of a system identity 29, a user U can quickly provide information as needed to system entities 27, while controlling how the information is distributed. The use of a secure and centralized identity structure provides controlled authentication and authorization of all system entities 27.

Through the use of detailed identity information, the identity based service system 10 provides unique value-added services, such as fast sign-in 18, a customized personal network environment, and quick links 140 to existing and new associated service providers 120.

System Operation. FIG. 14 is a schematic view 190 of a user U logging onto a first participant site 120 which is a participant 16 within the identity based service system 10, in which the user U does not currently have a system identity 29. As seen in FIG. 14, a user U may logs on 18 to the system 10 through any of a wide variety of devices 192, such as through a desktop computer 192a, or through a mobile device 192b. The device 192 typically comprises a graphic user interface GUI 194.

In the process of registering as a user at the site 120, the user typically establishes a user name 194 and password 196, and enters appropriate information to operate within the site 120, such as name, address, and/or credit information 96.

FIG. 15 is a second view 200 of operation for an identity based service system 10, wherein the user U is asked if a system identity 29 is desired. Upon the establishment of a system identity 29, a participant 16, such as through a service consumer 48 is able to find and invoke the web services 54 of a user U, such as to readily establish relationships with other providers 120, such as through selectable member site links 202. As well, upon the establishment of a system identity 29, a user can preferably establish and/or manage other system services 116, e.g. such as to establish a profile service 116b or a wallet service 116n, through selectable service links 204.

FIG. 16 is a third view 210 of operation for an identity based service system 10, in which a system identity 29 is established by a basic authentication agency 14. For example, information gathered from a first participant site 16,120 is associated with the identity 29 of the user U, and is typically securely stored by the basic authentication agency 14. The user U may easily chose one or more member site links 202 and/or service links 204, typically from an identity service selection screen 206.

Although the identity based service system and its methods of use are described herein in connection with personal computers, mobile devices, and other microprocessor-based devices, such as portable digital assistants or network enabled cell phones, the apparatus and techniques can be implemented for a wide variety of electronic devices and systems, or any combination thereof, as desired.

As well, while the identity based service system and its methods of use are described herein in connection with interaction between a principal and a network through a device, the use of identity based services can be implemented for a wide variety of electronic devices and networks or any combination thereof, as desired.

Accordingly, although the invention has been described in detail with reference to a particular preferred embodiment, persons possessing ordinary skill in the art to which this invention pertains will appreciate that various modifications and enhancements may be made without departing from the spirit and scope of the claims that follow.

Claims

1. A system, comprising: a device;at least one first entity associated with the device, the first entity comprising any of a user, a user agent and a principal;a first user identifier in a first namespace associated with the first entity, the first user identifier comprising any of a name identifier and an identity assertion;a second user identifier in a second namespace associated with the first entity, the second user identifier known to a service provider, the second namespace disparate from the first namespace, wherein the first user identifier and the second user identifier are pseudonymous to each other;an authentication agency;means for sending a login request from the first entity to the authentication agency;means for receiving an assertion at the first entity from the authentication agency in response to the log in request;means for sending the received assertion and the first user identifier in the first namespace to a participant;means for authenticating the first entity at the participant with the received assertion;means for sending the first user identifier in the first namespace and a request for service on behalf of the first entity from a second entity comprising any of the participant and a service consumer associated with the participant to any of the authentication agency and a discovery service associated with the authentication agency, using the received assertion, the request for service comprising a request for a service descriptor for locating the service provider, and a request for a service assertion for accessing the service provider;means for translating the first user identifier in the first namespace to the second user identifier in the second namespace at the authentication agency;means for an sending the service descriptor, the service assertion, and the second user identifier from the authentication agency to the second entity in response to the sent request for service if the first entity is enabled for the requested service, wherein the sent second user identifier is sent in a format that the second entity is blinded to the second user identifier:means for sending the service assertion to the service provider; andmeans for providing the requested service for the second entity at the service provider in response to the received service assertion if the second entity is authorized for the requested service by the user.

2. The system of claim 1, further comprising: at least one identity associated with the first entity, and user information associated with at least one of the identities; andat least one core service associated with the system and related to at least a portion of the user information.

3. The system of claim 2, wherein the core service is accessible by the first entity.

4. The system of claim 2, wherein the core service is accessible by the participant.

5. The system of claim 2, wherein the core service is associated with one or more core service providers.

6. The system of claim 2, wherein the core service comprises any of an authentication service, a profile service, an alert service, a calendar service, an address book service and a wallet service.

7. The system of claim 1, wherein a user identity of the first entity in the first namespace is translatable to a user identity in the second namespace at the authentication agency.

8. The system of claim 7, wherein the user identity in the second namespace is encrypted.

9. The system of claim 7, wherein the user identity in the second namespace is time-bound.

10. The system of claim 1, wherein a user identity is associated with the first entity, and wherein the system further comprises: at least one core authentication record associated with the user identity, comprising any of services and links associated with the user identity.

11. The system of claim 1, further comprising: means for invoking the requested service through the second entity using the service descriptor, the service assertion, and the second user identifier.

12. The system of claim 1, wherein the participant comprises any of a network site, a service provider and a store.

13. The system of claim 1, wherein the service assertion comprises a credential to access the requested service.

14. The system of claim 1, wherein at least one identity is associated with the first entity, comprising any of a personal identity, a business identity and an anonymous identity.

15. A system, comprising: an authentication agency for authenticating a first entity comprising any of a user, a user agent and a principal, the first entity having a first user identifier in a first namespace and a second user identifier in a second namespace, the second user identifier known to a service provider, the first user identifier comprising any of a name identifier and an identity assertion, the second namespace disparate from the first namespace, wherein the first user identifier and the second user identifier are pseudonymous to each other,for sending an assertion to a device corresponding to the first entity, andfor translating the first user identifier in the first namespace to the second user identifier in the second namespace; andat least one second entity comprising means for receiving the assertion and the first user identifier from the first entity,means for authenticating the first entity at the second entity with the received assertion,means for sending a request for service and the first user identifier on behalf of the first entity to any of the authentication agency and a discovery service associated with the authentication agency,means for receiving authorizations an authorization sent from the authentication agency in response to the sent request if the first entity is enabled for the requested service;means for receiving the second user identifier sent from the authenticating agency in a format that the second entity is blinded to the second user identifier;means for invoking the requested authorized service at the service provider with the received authorization and the received second user identifier, and means for receiving the invoked requested service from the service provider at the second entity if the second entity is authorized for the invoked requested service by the user.

16. The system of claim 15, further comprising: a discovery module associated with the authentication agency and adapted to receive a user identifier associated with the first entity and a service name known to the system.

17. The system of claim 15, further comprising: at least one core service associated with the system and related to the first entity.

18. The system of claim 17, wherein the core service is accessible by the first entity.

19. The system of claim 17, wherein the core service is accessible by the second entity.

20. The system of claim 17, wherein the core service is associated with one or more core service providers.

21. The system of claim 17, wherein the core service comprises any of an authentication service, a profile service, an alert service, a calendar service, an address book service and a wallet service.

22. The system of claim 15, wherein a user identity of the first entity in the first namespace is translatable to a user identity in the second namespace at the authentication agency.

23. The system of claim 22, wherein the user identity in the second namespace is encrypted.

24. The system of claim 22, wherein the user identity in the second namespace is time-bound.

25. The system of claim 15, wherein an identity is associated with the first entity, and wherein the system further comprises: at least one core authentication record associated with the identity, comprising any of services and links associated with the identity.

26. The system of claim 15, wherein the device is linked to the system.

27. The system of claim 15, wherein the second entity comprises any of a network site, a service provider and a store.

28. The system of claim 15, wherein the authorizations comprise a service descriptor and a service assertion, wherein the service descriptor comprises means for locating the requested service, and wherein the service assertion comprises a credential to access the requested service.

29. The system of claim 15, wherein at least one identity is associated with the first entity, comprising any of a personal identity, a business identity and an anonymous identity.

30. A process, comprising the steps of: sending a login request from a first entity associated with a device to an authentication agency, the first entity comprising any of a user, a user agent and a principal, the first entity having a first user identifier in a first namespace and a second user identifier in a second namespace, the second user identifier known to a service provider, the first user identifier comprising any of a name identifier and an identity assertion, the second namespace disparate from the first namespace, wherein the first user identifier and the second user identifier are pseudonymous to each other;receiving an assertion at the first entity from the authentication agency in response to the log in request;sending the received assertion and the first user identifier to a participant;authenticating the first entity at the participant with the received assertion;sending the first user identifier in the first namespace and a request for a service on behalf of the first entity from a second entity comprising any of the participant and a service consumer associated with the participant to any of the authentication agency and a discovery service associated with the authentication agency, using the assertion;translating the first user identifier in the first namespace to the second user identifier in the second namespace at the authentication agency;sending an authorization and the translated second user identifier from the authentication agency to the second entity for the requested service in response to the sent request if the first entity is enabled for the requested service, wherein the translated second user identifier is sent in a format that the second entity is blinded to the second user identifier;sending the authorization from the second entity and to the service provider; andproviding the requested service for the second entity at the service provider in response to the sent authorization if the second entity is authorized for the requested service by the user.

31. The process of claim 30, further comprising the step of: establishing at least one core service associated with the system and related to the first entity.

32. The process of claim 31, wherein the core service is accessible by the first entity.

33. The process of claim 31, wherein the core service is accessible by the participant.

34. The process of claim 31, wherein the core service is associated with one or more core service providers.

35. The process of claim 30, wherein the core service comprises any of an authentication service, a profile service, an alert service, a calendar service, an address book service and a wallet service.

36. The process of claim 30, further comprising the step of: translating namespaces for user identities, such that a user identity of a first entity in the first namespace is translated to a user identity in the second namespace.

37. The process of claim 36, further comprising the step of: encrypting the user identity in the second namespace.

38. The process of claim 36, wherein the user identity in the second namespace is time-bound.

39. The process of claim 30, further comprising the steps of: establishing at least one identity associated with the first entity; andassociating at least one core authentication record with the established identity, comprising any of services and links associated with the established identity.

40. The process of claim 30, further comprising the step of: invoking the requested service through the second entity using the authorization.

41. The process of claim 30, wherein the participant comprises any of a network site, a service provider and a store.

42. The process of claim 30, wherein the authorization comprises a service descriptor and a service assertion, wherein the service descriptor comprises means for locating the requested service and wherein the service assertion comprises a credential to invoke the requested service.

43. The process of claim 30, wherein at least one identity is associated with the first entity, comprising any of a personal identity, a business identity and an anonymous identity.

44. A process, comprising the steps of: providing an authentication agency networked to a service;establishing an identity at the authentication agency for a first entity associated with a device, the first entity comprising any of a user, a user agent and a principal, the first entity having a first user identifier in a first namespace and a second user identifier in a second namespace, the second user identifier known to a service provider, the first user identifier comprising any of a name identifier and an identity assertion, the second namespace disparate from the first namespace, wherein the first user identifier and the second user identifier are pseudonymous to each other;sending authentication information from the authentication agency to the device;sending the authentication information and the first user identifier from the device to a participant;authenticating the first entity at the participant with the authentication information;sending the first user identifier in the first namespace and a request for a service on behalf of the first entity from a second entity comprising any of the participant and a service consumer associated with the participant to any of the authentication agency and a discovery service associated with the authentication agency;translating the received first user identifier in the first namespace to the second user identifier in the second namespace at the authentication agency;sending an authorization and the translated second user identifier from the authentication agency to the second entity to access the service on behalf of the first entity if the first entity is enabled for the service by the authentication agency;establishing a link between the second entity and the service provider, based upon the authorization and the translated second user identifier; andproviding the requested service for the second entity at the service provider in response to the sent authorization and the translated second user identifier, if the second entity is authorized for the requested service by the user.

45. The process of claim 44, wherein the second entity comprises any of a network site, a service provider and a store.

46. The process of claim 44, wherein the authorization comprises a service descriptor and a service assertion, wherein the service descriptor comprises means for locating the requested service and wherein the service assertion comprises a credential to establish the link.