JP2005529392A - Hierarchical distributed identity management - Google Patents

Abstract

In this application, systems and methods for identity management and authentication are provided. The present invention employs a shadow domain to prove the executor's membership in an identity management system whose trust responsibilities depend on the user. The present invention further teaches double signature certificate transmission for assertion authentication performed by a third party in the identity management network.

Description

  The present invention relates generally to a method and system for identity management. In particular, the present invention relates to a hierarchical distributed identity system and method when used in a distributed computer network.

  In the field of electronic commerce, it is widely recognized that there is a need for systems and methods for managing or authenticating identity-based information. It is recognized by those skilled in the art that identity-based authentication of information is not about guaranteeing who the user is saying. Rather, identity authentication is limited to authentication that the user has presented the same credentials that were previously presented when the identity was asserted. A simple way to understand this subtle difference is to consider a situation where the user is identified by a user ID for which an associated password exists. The electronic system has no way of determining who the user is when the account is initialized. However, once the account is initialized, the presentation of the user ID and password combination can be viewed as evidence that the same person who previously registered the service and submitted this credential. The presentation of a user ID and password does not prove that the user is a particular individual.

  Identity management is of great interest in the field of e-commerce, as it allows e-commerce vendors or service providers to provide custom services to users and also allows vendors to track user behavior. From the user's perspective, identity management allows the user to retrieve previously stored identification information. Without an identity management system, each use of the service must select a set of settings that cannot be saved in subsequent sessions. For example, for online purchases, without an identity management system, the user must be required to submit all identifying information, including credit card number, billing address, and shipping address for each purchase. This is generally annoying for customers and detrimental to online commerce.

  The following description is generally related to the application of identity management to electronic commerce, but other non-commerce related issues such as customizing news sites, registering access to newspapers and maintaining the desired display configuration for electronic discussion sites. One skilled in the art will appreciate that the service uses identity management. For these services, the highest priority is that the user can single sign-on for multiple services.

  FIG. 1 shows a first generation identity management system. A user 100 is connected through an internet 102 to an electronic retailer 104 commonly referred to as an E-tailer. The E-Taylor 104 is typically accessed using a Hypertext Transfer Protocol (HTTP) session. When E Taylor 104 first accesses a hosted site, user 100 creates a user profile that includes a user ID and password. The user ID and password are stored in the user profile database 106, possibly along with other relevant information including credit card number, ship-to and billing address and display preferences. The user profile database 106 is preferably inaccessible to general computers connected to the Internet 102 to protect sensitive user information. After creating a user profile in the user profile database 106, the user 100 may simplify subsequent visits to the E-Taylor 104 simply by presenting a certificate to prove their identity. it can. Generally, this credential is a combination of a user ID and a password. When presented with this credential, E-Taylor 104 checks the user profile database 106 to see if the user has presented a valid identity certificate. If this check is passed, the user 100 is not prompted for input to submit known information. From the standpoint of E-Taylor 104, the system ensures that the user 100 provides all the information necessary for the transaction that can be stored in the user profile database 106. This information can be correlated across multiple sessions or transactions to generate user profile trends. From the user's perspective, the system allows for simplified transactions with E-Taylor 104. However, the disadvantages of this system are illustrated in FIG.

  FIG. 2 shows a network model of a user 100 using the Internet 102 to connect to two different E-tailers, E-Taylor 104a and E-Taylor 104b. Each E-Taylor has its own user profile database, databases 106a and 106b. Since the user ID and password are used to authenticate the identity of the user 100, E Taylor generally insists that each user ID is unique. Accordingly, it is conceivable that the user 100 has different user IDs in the E Taylors 104a and 104b in addition to other user IDs in other E Taylors, which are not shown in the figure. From the user's standpoint, it is difficult to manage multiple user IDs. Further, when user information changes, for example, when the user 100 moves or changes credit card information, each user information database 106a and 106b must be updated individually. While this is simply cumbersome at a small scale, it can be a major nuisance for many users who often visit various E-Taylors. Furthermore, repeatedly entering user data increases the probability that the user will inadvertently provide inaccurate information and is harmful to E-Taylor. Thus, given the responsibility of ensuring the data integrity of many databases and the hassle associated with multiple user IDs, this model of identity management appears inadequate to many users.

  To ensure that the user ID is unique, many E-tailers use the user's 100 email address instead of the user ID. However, there is no guarantee that the email address provided by the user will not change over time. In many cases, users are given email addresses by employers, internet service providers, or free email providers. In these cases, there is no guarantee that the email address will not change due to workplace changes, Internet service provider changes or simple whims. As a result, the user needs to reapply to E-Taylor when their email address changes.

A second generation identity management and authentication method was created to allow users to use a single user ID for multiple services and to provide what is commonly referred to in the art as “single sign-in”. It was. This solution is commonly referred to as a hierarchical identity management system, typically represented by Microsoft's Passport ^™ service. An overview of this model is shown in FIG.

  FIG. 3 shows a user 100 having a connection to an identity provider 108 (IDP), preferably through the Internet 102. User 100 provides IDP 108 with an identity-based set of information associated with a unique user ID and password combination. This information is stored in the user profile database 110. When user 100 connects to an E-Taylor affiliated with IDP 108, user 100 submits an identity certificate to E-Taylor 112, which is sent to IDP 108 to authenticate user 100. In general, the certificate that the user 100 submits to the IDP 108 through the E-tailor 112 is a combination of a user ID and a password. Upon authenticating the user 100, the IDP 108 provides the identity information stored in the E Taylor 112. In general, the information provided by IDP 108 to E Taylor 112 is a strictly defined subset of the information stored by IDP 108 or the entire data related to user 100 stored by IDP 108 in user profile database 110. Since IDP 108 stores information that can be accessed by multiple E-Taylors affiliated with IDP, IDP 108 generally does not store site-specific information, such as preferences expressed by a user for a particular site, and from a particular E-Taylor to a user. The user preference database 110 is not used to store the history of products purchased by 100. As a result, E-Taylor 112 must maintain a user preference database 114 separately. Information in the user preference database 114 is used to track the patterns of the user 100 and to maintain a purchase or subscription history for the user 100.

  In the example of a transaction in this model, user 100 requests a web page from E Taylor 112 using an HTTP link over Internet 102. During this HTTP session, the user 100 informs that he wants to purchase some items. During the checkout procedure, E Taylor 112 asks user 100 to authenticate his identity. In order to receive authentication from the IDP 108, the E-Taylor 112 requests and receives a certificate necessary for authentication from the user 100. The certificate is sent to the IDP 108 for authentication. In an alternative embodiment, user 100 does not provide authentication information to E Taylor 112. Instead, when E-Taylor 112 requests identity authentication, E-Taylor redirects user 100 to IDP 108, and upon completion of this transfer, user 100 provides the necessary authentication information to IDP 108. If the authentication of the user 100 is successful, the IDP 108 redirects the user 100 back to the E Taylor 112. Using the same or different data communication channel, IDP 108 provides information stored in user profile database 110 to E Taylor 112. This information is correlated with information stored in the user preference database 114 to allow the user 100 to access historical information.

  While this model of identity management addresses the single sign-in problem associated with the first model of identity management, many other problems arise. The first problem is the reliability of the executing entity that operates the IDP. This executing entity must be trusted by both E-Taylor 114 and user 100. The IDP 108 must be trusted by the user 100 to protect the information and provide the information only to the performing entity that the user 100 approves. E-Taylor 112 must be reliable that IDP 108 provides reliable services, accurate data, and does not predatory actions. If E Taylor 112 is a service provider that provides services that compete with services provided by the executing entity that operates IDP 108, E Taylor 112 will generally not have much higher trust in IDP 108.

Because there are many privacy concerns among users, the Microsoft Password ^™ service is implemented so that the user is never required to provide E Taylor 112 with identity authentication information. Instead, a redirect command is used to pass the user from E Taylor 112 to IDP 108 over a secure connection. Through this secure connection, the user 100 provides identity authentication information to the IDP 108. Once the user 100 is authenticated, the IDP 108 returns the user 100 to the E Taylor 112 over a secure back channel and provides authentication and user information to the E Taylor 112. In order to prevent two E-Taylors from correlating information about a single user 100 at different sites, IDP 108 uses an identity coding index to correlate users between the two sites. E-Taylor's unique identity coding is performed. However, since E-Taylor 114 generally knows the credit card number associated with user 100, the two E-Taylors willing to share information can use the credit card information, email address or home address as a cross-reference field. Those skilled in the art will appreciate that can be used to correlate their own database.

The current implementation of the Microsoft Passport ^™ system has failed to gain enough traction to push the first generation identity management system in the e-commerce market. One reason is that a centralized euser profile database, such as the user profile database 110, generally has a static data structure. That is, the database stores a predefined set of information. However, different E-Taylors generally require different information sets from the user. The centralized user profile database 110 is not designed to store all the information required by various e-tailors, so it will be profitable even if you migrate to the centralized user profile database 110 as provided by the Microsoft Passport ^TM service. Many E-Taylors decided that it was not possible. Another reason that the Passsport ^™ service has not been replaced by the first generation identity management system is that users have been wary of providing vast amounts of identity information to a single actor. In order for a user to have sufficient trust in the IDP to provide such an amount of information, there must be existing trust relationships and user assumptions regarding data security. Many users did not want to provide this information because many users did not have this kind of historical relationship with Microsoft.

  Another concern among many people is that the hierarchical identity management system promotes a monopoly trend. To address this concern, a third generation model of identity management system was created by the Liberty Alliance. This model is best described as a distributed identity management system. Such a system is shown in FIG.

  FIG. 4 shows a distributed identity management system proposed by the Liberty Alliance. This specification describes a plurality of identity providers, shown in the figure as IDP1 116, IDP2 120 and IDP3 124, each having a user profile database UPD1 118, UDP2 122 and UPD3 126. All IDPs exist in the trusted web 128, and each IDP has a trust relationship with all other IDPs. Trust relationships are indicated by dotted lines. For data security, communication between IDPs on the trusted web 128 is performed using asymmetric encryption. Thus, in the example of FIG. 4, IDP1 116 has a public encryption key and a secret encryption key associated therewith, and so are IDP2 120 and IDP3 124. IDP1 116 also has the public keys of IDP2 120 and IDP3 124. In this way, all requests sent between the two IDPs can be encrypted using the public key of the destination IDP and signed using the private key of the sending IDP. In this way, when IDP1 116 needs to communicate with IDP2 120, it encrypts the request with the public key assigned to IDP2 120 and signs the encrypted message with its private key. IDP2 120 can decrypt the encrypted message using its private key and verify the signature of IDP1 116 using the public key assigned to IDP1 116 stored in IDP2 120. This allows each IDP belonging to the trusted web 128 to communicate with other IDPs belonging to the trusted web without worrying about the data data channel between the IDPs being compromised. The user 100 registers with one of the IDPs belonging to the trusted web 128. In FIG. 4, the user is associated with IDP3 124. IDP3 124 stores the identity information provided by user 100 in UPD3 126 along with the identity certificate. When user 100 establishes a session with an E Taylor associated with any of the IDPs belonging to trusted web 128, eg, E Taylor B 132, user 100 submits an identity certificate to E Taylor B, and the certificate Is then given to one of the systems belonging to the trusted web 128. As shown in FIG. 4, E-Taylor B 132 is affiliated with IDP2 120. Accordingly, the ID certificate of the user 100 is presented to E Taylor B, which relays it to IDP2 120. In order to authenticate the user credentials of user 100, IDP2 120 determines that user 100 is subscribed to IDP3 124 and uses a public key and a private key to secure between IDP3 124 and itself. Establish a data connection. This data connection is used to authenticate the identity certificate provided by the user 100. Once the user 100 is authenticated, IDP3 124 provides identity information to IDP2 120, which is relayed back to E Taylor 132.

  This system provides the user 100 with a single sign-on capability and addresses concerns about IDP's monopoly trend. Each IDP is not considered a global repository of information because it is independent of other IDPs. Thus, even if an IDP's security is compromised, only information related to that IDP's user profile database is compromised. This is an advantage over a hierarchical model where the risk of the user profile database extends to all users of the system.

  However, according to the specification of the Liberty Alliance, only a limited set of user identity information is stored in the IDP. Thus, E-Taylor must still ask the user 100 for information that is not stored in the IDP. In addition, public and private encryption keys require each IDP to be able to perform enormous computationally intensive tasks for each data request. Furthermore, as the scale of the trusted web increases, advanced key management systems must be employed. Although FIG. 4 shows only three IDPs, the model proposed by the Liberty Alliance specification is not limited to this. One skilled in the art will appreciate that the number of IDPs belonging to a trusted web cannot be expanded indefinitely. When the number of IDPs is small, a system in which each IDP can trust other IDPs can be realized. However, when the number of IDPs reaches tens of thousands, this type of system is unlikely to be realized in a reliable manner.

  From the perspective of the user 100, the model presented by the Liberty Alliance has a number of drawbacks. User single sign-on capabilities are somewhat limited. A user is assigned a unique user ID that links the user to the IDP selected by the user. When a user is authenticated by an IDP belonging to a trusted web, E-Taylor is given a pair of unique identifiers (PUID) that can be used to identify the user in the future. Since PUIDs are unique in pairs, the PUIDs assigned to two E-Taylors for the same user are different to prevent cross-correlation of user purchases or activities. Since only the IDP related to the user holds the PUID given to E Taylor, it is not possible to transition from one IDP to another. If the user wants to move from IDP3 124 to IDP2 120, an entirely new identity must be created and all information stored in IDP3 124 must be entered again for storage in IDP2 120. Many users see this as binding users to a system that has not yet been tested. As a result, many users are very hesitant to register for this service. For E-Taylor and potential IDPs, participation in the Liberty Alliance includes the ability to store user information, including how user information can be used for statistics or marketing, Including agreeing on certain constraints. Such a constraint appears to limit the number of people who want to join the Liberty Alliance.

Both Passport ^™ and Liberty Alliance give PUIDs to E-Taylor and other sites that require user authentication. The PUID allows E Taylor to store information and build a profile for the user, while preventing two E Taylors from easily correlating its database to determine user activity and patterns. . The PUID in the Liberty Alliance is assigned by the IDP that holds the user profile and cannot be tied to the user account by other IDPs, so when a user tries to change the IDP, All site-specific settings are lost. This constrains the user to a single IDP and does not give most users the opportunity to port beyond the single source that Passport ^™ offers. Furthermore, the purpose of the PUID assigned by Passport ^™ or Liberty Alliance can be achieved as described above by correlating with other information such as credit card information.

  None of the current identity management systems can provide the single sign-on service, the specialized information that many E-Taylors need, and the portability of identity information, so any service has so far taken on other services. I couldn't replace it. Accordingly, it is desirable to provide an identity management system that provides a dynamic user information set, scales, and does not rely on global data storage.

(Summary of Invention)
It is an object of the present invention to eliminate or mitigate at least one disadvantage of previous identity management systems.

  In a first aspect of the present invention, an identity management system for providing user authentication to a member site is provided. The identity management system includes a root server having a user database for storing a globally unique identifier associated with a user. The root server has means for giving the user a globally unique identifier, and means for maintaining a list of network addresses associated with the names of the shadow domains to give to the domain name server, each name Is associated with a member site or home site belonging to an identity management network. The root server allows the home site to authenticate the executing entity accessing the member site as a user associated with the globally unique identifier when the user is redirected to a name associated with the home site in the shadow domain. The root server can optionally include a home site authentication message for providing the member site with authentication of the home site's authority to authenticate the executing entity as a user associated with the globally unique identifier.

  In one embodiment of the first aspect of the present invention, the identity management system is a home site that communicates with a root server and has a domain name in a user profile database, a user authentication engine, and a shadow domain namespace. including. The user profile database stores both a globally unique identifier and authentication information associated with the user. The authentication engine allows the home site to authenticate the user's identity. The authentication information is arbitrarily a combination of a user ID and a password. In another embodiment, the user profile database further stores identity information associated with the user, and the authentication engine includes means for providing a subset of the identity information to the member site when authenticating the user. . In a further embodiment of the invention, the authentication engine provides an authenticated user identity to the member site by providing the user with a cookie containing authentication information readable by the member site and redirecting the user to the member site. . The cookie is optionally signed by the home site and includes an indication from the root server that the home site is authorized to authenticate the globally unique identifier. The display is optionally a signed assertion of the root server. In another embodiment, the authentication engine provides the user with a cookie containing authentication information readable by the member site or by redirecting the user to an authentication encoded universal resource locator and redirects the user to the member site To provide the member site with identity information associated with the user.

  In a second aspect of the invention, a method is provided for providing user authentication to a member site of an identity management network. The method includes obtaining a name of the home site, providing an authentication request to the home site, and obtaining user authentication from the home site. Obtaining the name of the home site includes obtaining from the user the name of the home site that can be given user authentication based on user authentication information known to the home site. Providing the authentication request to the home site includes redirecting the user to the home site in the shadow domain associated with the identity management network. Obtaining authentication includes obtaining authentication of the user from the home site in response to the home site receiving known authentication information from the user. The authentication information includes a globally unique identifier associated with the user. In one embodiment of the second aspect, the step of obtaining the name of the home site from the user includes the step of the member site examining a cookie provided by the user. In another embodiment, providing the authentication request to the home site includes the user converting a name associated with the home site in the shadow domain to a network address. In yet another embodiment, providing the authentication request to the home site includes providing the user with a cookie that includes a user authentication request readable by the home site. In yet another embodiment, the home site can provide both user authentication information and user identity information, and the step of granting an authentication request to the home site further includes the member site requesting identity information from the home site. While obtaining the authentication further includes obtaining identification information in response to the home site receiving known authentication information from the user. In a further embodiment, the method provides the home site with identity information obtained by redirecting the user to the home site in the shadow domain, and obtaining identity information that the home site does not provide. Identity information, including steps, that is not provided by the home site is obtained from the user.

  In a third aspect of the present invention, a method for performing user authentication at a home site belonging to an identity management network is provided. The method includes receiving a request to provide authentication for a member site from a user having a globally unique identifier and known authentication information, and in response to receiving the known authentication information, a shadow associated with the identity management network. Including authenticating the user to the member site by redirecting the user to the member site in the domain. In one embodiment of the third aspect, providing authentication of the user to the member site includes receiving from the user a user ID and password combination associated with the user's globally unique identifier. In another embodiment, providing the user's authentication to the member site includes converting the name associated with the member site in the shadow domain to a network address, and further providing the user's authentication: Optionally, the home site includes providing the user with a cookie that is readable by the member site and includes a user authentication and a globally unique identifier associated with the user. In another embodiment, receiving a request to provide authentication information includes receiving an identity information request, and providing authentication includes providing identification information to a member site upon receiving known authentication information from a user. And before the step of providing identification information to the member site includes the step of obtaining the user's permission to transfer the requested identification information to the member site. In another embodiment, the method includes receiving identity information obtained from a member site from a user and storing the transferred identity information in a user profile database.

  In another aspect of the invention, a method is provided for obtaining a globally unique identifier associated with a user having an email address. The method includes receiving a request from a user to associate a globally unique identifier with an email address; a global unique identifier associated with the user's email address in a root server that associates the globally unique identifier with the email address; Requesting an assignment, and obtaining a globally unique identifier associated with the email address in response to providing the route with a response to what the user is sent to the email address.

  Other aspects and features of the present invention will become apparent to those of ordinary skill in the art by reading the following description of specific embodiments of the invention in conjunction with the accompanying drawings.

(Detailed explanation)
Generally speaking, the present invention provides a method and system for identity management.

  In order for an identity management system to be successful, the user must trust the executor that stores the personal information and be given a set of characteristics that prompt the user to use the system. Without an adequate user base, the identity management system will not succeed because it cannot attract service providers.

  From the user's point of view, the system must provide a simple registration process with a trusted actor. After registration, the user must be provided with a simple way to log in to the service using a single login, and a simple mechanism must be provided to register for these services. The user must be provided with a simple mechanism for providing additional information to the trusted actor. Finally, the interaction between the vendor / service provider and the trusted performer should be mostly transparent to the user.

  From the standpoint of a vendor or service provider, traditional identity management systems have been problematic because of the high degree of trust required between the vendor and the certificate authority. This trust problem is solved in the present invention by delegating trust responsibility to the user. If a user trusts an executing entity to keep his / her personal information and perform the function of a certification body, the vendor can be satisfied that the user is satisfied with the trust relationship, so the vendor Reliable. This trust relationship is sufficient as long as the certificate authority remains in the identity management network.

  From the certification authority's standpoint, the agreements reached with the users can be designed to serve the certification agency's business needs rather than being directed by the central body as in the case of the Liberty Alliance. it can. Furthermore, the authentication mechanism is left to the agreement between the certification body and the user. Accordingly, each authentication authority can employ a respective authentication mechanism such as a combination of user ID and password, smart card, biometric sampling, and other known user authentication methods. If the user is disillusioned with the authentication mechanism or service provided by the certificate authority, the user can change the certificate authority used to store and authenticate identity information.

  A central authority is established to operate the network. This central authority defines the schema used by the certificate authority to store user identity information. This allows vendors belonging to the identity management network to request information in the predefined fields. The central authority also provides a mechanism for both the vendor and the certification authority to ensure that the communication partner is part of the identity management network.

  Every computer system connected to a public communications network, such as the Internet, has an assigned numeric network address. This address serves as a unique identifier and also provides routing information so that packets destined for a network node can be effectively routed to this designated node. In order to simplify addressing for network and human interaction, an alphanumeric domain name is assigned to a node, and a domain name server (DNS) is generally used to allow an alphanumeric domain name to be converted to a numeric address. ) Is given a lookup function. These techniques are well known to those skilled in the art. Another known use of the domain name system is for restricting access to systems in the domain. By simply addressing a transmission using an alphanumeric domain name, the sending system can restrict systems outside the domain specified by that alphanumeric domain name from receiving the packet. The relative security of DNS systems is trusted almost entirely by the Internet without global redirection. As referred to in this application, a shadow domain is a domain created in the Internet under a central authority namespace. All actors belonging to the identity management network can be assigned a name in the shadow domain, and this name is translated into a numeric address associated with that actor. In this way, the vendor has a shadow domain address that translates to the same numeric address as its primary domain, or a numeric address that is associated with other systems that are different from the primary domain but controlled by the vendor. Can have shadow domain addresses that can In order to ensure that both the vendor and the certificate authority belong to the identity management network, it is desirable to use a technique using shadow domains in the present invention.

  The following description is an overview of the identity management network architecture and the role of each actor, and how this architecture registers the user to the identity management network, single sign-on functionality, and the user that the certificate authority remembers. Simplified registration for services that require information, a mechanism for updating the schema used by the certification authority to store user data, and vendor or service provider backfilling user information to the certification authority A mechanism to do this, whether to provide a mechanism for the user to change the certificate authority without providing any previously stored information while maintaining all sign-ins. In addition, the security characteristics arising from this architecture and the new chain of trust for certificate signatures and keys are introduced along with other advantages of the architecture and method of the present invention.

  In the following description, the central certificate authority is referred to as the root or simply the root of the hierarchical distributed identity management network. The certification authority is called the home site (HS) because it provides a home for user data. Sites that require user authentication or user identity information are called member sites (MS). A user is called a user as it is.

  FIG. 5 illustrates the architecture used in the hierarchical distributed identity management system of the present invention. FIG. 5 shows four execution entities: a user 200, a home site (HS) 202, a member site (MS) 206, and a route 210. Each executing entity will be described in relation to its role in authentication and identity management. Since FIG. 5 is merely an example, there may be additional home sites and member sites, which are not shown in the figure.

  The user 200 is a user who has a connection to a general public communication network such as the Internet. User 200 has information related to his identity, such as address, billing information and other personal information such as calendar-based information. The user 200 selects a home site (HS) 202 to store this identity information and provide identity authentication for single sign-on service.

  HS 202 includes a user profile database (not shown) that is used to store identity information about user 200. The HS also associates a globally unique identifier (GUID) with user 200 identity information. The GUID is a globally unique identifier assigned to the HS 202 by the route 210, and the method will be described later. HS 202 has a unique network address and a domain name 204 associated with this address, shown in the figure as homesite.com. Thus, to access HS 202, user 200 can direct a web browser to www.homesite.com and the address is converted to the address of HS 202 through a domain name server (DNS).

  Member site 206 (MS) is a node on the public Internet 102 that has a domain 208 membersite.com associated with its network address. The MS 206 provides a service that the user 200 subscribes to or sells a product that the user 200 wants to purchase. In order to allow the user 200 to sign in or to obtain personal information regarding the user 200, the MS 206 requests authentication of the user 200 or a set of information regarding the user 200.

  User 200 provides identity information to home site 202 (HS). A set of identity certificates is associated with information provided to the HS 202 by the user 200. In the following description, the user certificate is shown as a combination of a user ID and a password. However, those skilled in the art will appreciate that any number of other authentication methods can be used in place of the user ID and password combination, including biometric reading, static IP tracing and smart card derived information.

  HS 202 has a primary domain 206homesite.com that is associated with its IP address through a conventional domain name system. User 200 or other systems on the network can access HS 202 either through a numeric IP address or through a domain name associated with the IP address. The MS 206 can also be accessed using a unique numeric IP address or a domain associated with the IP address. In addition to having a primary domain in the Internet 102 (not shown), both the HS 202 and the MS 206 are connected to each other through a shadow domain managed by the route 210. Route 210 manages the shadow domain associated with identity management network 212. In this way, user 200 can access HS 202 at its primary domain homesite.com, and MS 206 at its primary domain membersite.com, and HS and MS can each access homesite.com.root. It can be accessed at net and membersite.com.root.net. One skilled in the art will recognize that the primary domain name and shadow domain name pairs are not necessarily the same address, but both result in the same performing entity. The shadow domain managed by route 210 is shown in the figure as identity management network 212. In the model of FIG. 5, identity management and authentication is provided by a hierarchical separate identity management system. In this system, member sites rely on any home site in the same shadow domain for user authentication. In previous identity management systems, there has been resistance from E-Taylor or other service providers because there must be a certain trust between IDP and E-Taylor, but the model of the present invention eliminates that need. . The MS 206 only relies on the HS 202 to authenticate that the user 200 claiming to be the user 200 has submitted the same certificate for authentication as previously submitted. Regardless of how the HS 202 integrity, business ethics, and how the user's 200 information is handled, the member site 206 no longer cares about the member site 206, and the MS 206 leaves it to the user 200 to determine whether the HS 202 is reliable. If multiple users determine that a home site is not reliable in this model, the user can request that the route 210 be removed from the Internet without using the home site. In this way, home site enforcement is an obligation assigned to users, not vendors. In addition, since the network is distributed, there is no restriction by claiming that member sites cannot be home sites at the same time. As a result, allowing member sites to act as home sites at the same time can address the fear that IDP may illegally use businesses to steal customers. The only requirement imposed on member sites or home sites is to be part of the shadow domain.

  To establish an identity profile at HS 202, user 200 submits a profile information and a certificate, such as a user ID and password, and receives a token indicating that the user can be authenticated by HS 202. In the presently preferred embodiment, the token is a cookie called a home site cookie. This token can be accessed by any execution subject belonging to the shadow domain. When the user 200 visits the MS 206, the user presents this token only when redirected to the shadow domain. To do this, the MS can provide a link that directs all users whose identity information is stored in the identity management network 212 to click for registration or authentication. This link redirects the user to the shadow domain 208 so that the home site cookie can be retrieved. The user is then given a second cookie and can be directed to HS 202 in the primary or shadow domain. Instead, when visiting the MS 206, the user 200 is redirected to the shadow domain 216 and then returned to the primary domain 208 so that the cookie is retrieved before the login request. When requesting authentication through the HS 202, the MS 206 can provide the user 200 with a second cookie. The second cookie can be used to request authentication and give HS 202 what (challenge) that requires a signature. This can be used to ensure that the HS 202 belongs to the identity management network 212 and has authority to authenticate the user 200. This redirection can be made transparent to the user. Since user 200 can only provide cookies for requests originating from the shadow domain corresponding to identity management network 212, confirmation that HS 202 and MS 206 are in identity management network 212 is fulfilled. Can be obtained. A more detailed description of how authentication and information transfer takes place is given below.

  The root 210 creates the shadow domains homesite.com.root.net 214 and membersite.com.root.net 216 for the HS 202 and the MS 206, respectively, thereby confirming that the HS 202 and the MS 206 are joined to the identity management network 212. Manage shadow domains so they can be verified. Route 210 also has the ability to assign globally unique identifiers (GUIDs) to users through interaction with HS 202 and to define information schemas that allow member sites to request information from multiple home sites in a standardized manner. It performs many other functions including. The route 210 also provides a mechanism for the MS 206 to obtain an encryption certificate from the HS 202 and to guarantee its authenticity. Since the root 210 manages the domain root.net, DNS lookup items can be added and excluded to include or exclude the executing entity in the identity management network 212. In this way, the shadow domain is managed by the route 210 in the identity management network 212 to allow member sites and home sites to verify that the authentication or information exchange partner remains in the network. . The route 210 also preferably provides the HS 202 with a signed assertion that identifies the home site that has authority to authenticate the user to provide to the member site along with the user's authentication.

  Those skilled in the art will readily recognize that eliminating many of the scalability issues associated with this model by excluding trust relationships between IDPs. A single root 210 can manage a domain large enough to accept multiple home sites, so that each member site belonging to the shadow domain can authenticate user information at each home site. To.

  In order to understand how the hierarchical distributed structure works, some standard operations will now be described. Those skilled in the art will appreciate that these methods are merely examples and should not be viewed as limiting the scope of the invention.

  As will be appreciated by those skilled in the art, the identity management system 212 desirably identifies each user with a unique identifier. While previous identity management systems assigned PUIDs, the presently preferred embodiment of the present invention is portable globally unique so that a user ID can be associated with a single HS and moved to another HS. It can be. For this purpose, each user is assigned a globally unique identifier (GUID) that is assigned by route 210 and is associated by route 210 to both the user and the HS. If the user subsequently wants to change the home site, the route 210 can authenticate the request and instruct the current HS to forward all information about the user to the new HS. When the user subscribes to the MS or completes the transaction, the MS is given a GUID so that the MS can easily identify the user even after the HS has changed. In the user-HS interaction, the HS allows the user to associate a user-friendly identifier, such as a prior art user ID, with the GUID to facilitate identification. With some unique user ID and password combination or other user authentication mechanism, the HS 202 authenticates the user 200, along with a signed signature of the root that the HS 202 is authorized to authenticate the user, and the associated GUID. Can be given to. In this way, the user 200 interacts with the HS 202 using an easy-to-use user ID, but for all other systems in the identity management network 212, the user 200 is represented by a GUID. The GUID is assigned by the route 210 and is preferably assigned only when the HS 202 can provide a valid email address for the user 200 that can be verified by the route 210. In order to prevent the HS 202 from inappropriately requesting or generating a GUID for users not interested in the identity management system 212, it is desirable to verify the validity of the email address.

  FIG. 6 is a flowchart illustrating the steps used to register a user 200 in the identity management network. Since each GUID is associated with a home site and a home site specific user identifier, each home site can employ a unique method for determining the appropriate user ID for each user. The GUID is assigned by route 210 to be unique throughout the network and to prevent home sites from creating fictitious users in the network. In step 220, the user 200 registers with the home site 202 and requests a home site specific user ID. A GUID is associated with this user ID. In making this request, the user 200 indicates a valid email address to the home site 202. In step 222, the home site 202 informs the route 210 of the user's email address and requests to assign a GUID to the user email address before obtaining the GUID. Upon receipt of the GUID assignment request from home site 202, in step 224, route 210 verifies the validity of the email address by sending an authentication challenge to this email address. User 200 receives an authentication challenge in the email sent and communicates with both root 210 and home site 202 in step 226 to prove the validity of the email address. Upon successful receipt of the challenge response, route 210 assigns a GUID to this email address and associates this GUID with both a valid email address and a home site identifier associated with the home site that requested the GUID. The GUID is preferably stored by the HS 202 in a signed assertion of the root 210 that associates the HS 202 with the GUID to prove to the MS that the HS 202 has authority to authenticate the GUID. Similar assertions that associate GUIDs with email addresses can also be stored. These assertions are preferably signed and indicate an expiration date so that the HS 202 cannot authenticate the user after the user has transferred its GUID to another HS. In another embodiment, when an executing entity joins the identity management network 212 as a home site, the home site verifies that the route 210 is satisfied that the email address of the existing account is valid. The route can issue a GUID for each existing account without sending a challenge to the email address. This allows a home site with an existing user base to join the identity management network 212 without having each existing user respond to the challenge email. In order to verify the validity of the email address to the route 210, the home site can submit evidence of previous transmissions to the user as evidence of the validity of the email address.

  Since the trust relationship is between the user 200 and the HS 202, it may be desirable for the challenge email to be stamped with the identity of the HS 202. To this end, along with the GUID request, the HS 202 can provide the root 210 with an email template for use with the challenge. In this way, using the provided template, the route 210 can send an HS 202 branded email. The template may ensure that the HS 202 is sure to give the user a challenge email with the HS 202 logo and that the challenge email is given in the language specified by the HS 202. This makes the sign-in process seamless to the user.

  In the currently preferred embodiment, sending the challenge in the email message of step 224 is performed by sending a challenge encoded URL to the user. In step 226, the user responds to the challenge by clicking on the URL and is directed to the destination address. The ability for user 200 to click through the link is considered sufficient evidence that a valid user has received the email message. The route 210 does not issue a GUID to the HS 202 until it receives confirmation that the user has clicked through. This can be done by having the challenge URL direct the user 200 to the route 210 and the route then redirects the user 200 to the HS 202 along with the GUID, or the challenge leads the user 200 to the HS 202 and instead of the user 200 A challenge response can be provided to HS 202 for provision to route 210. The URL can be directed to either the conventional address of the HS 202 or its shadow domain address to serve as a further guarantee that the HS 202 belongs to the identity management network 212.

  In the presently preferred embodiment, when root 210 or home site 202 identifies user 200, it provides user 200 with a cookie that is accessible to any member of the shadow domain consisting of home site, member site, and root 210. Giving cookies is an optional step 228. This cookie is preferably referred to as an HS cookie and identifies the home site to be used to authenticate the user. In the presently preferred embodiment, the home site cookie given to the user provides the home site with an http URL that gives the MS 206 the location to which the user should be redirected and also gives the MS 206 a location where the HS certificate can be obtained. Identify. In another embodiment, the home site cookie may provide a number of URLs, including a URL indicating where to redirect the user and a URL indicating where the MS 206 can obtain a certificate from the home site. Obtaining an HS certificate is important for signature verification as described below. In another preferred embodiment, the cookie includes a representation by route 210 that identifies home site 202 and that the identified home site is a home site that can authenticate the user. Those skilled in the art will appreciate that information about where to obtain the HS certificate can be obtained from the certificate URL while the MS 206 obtains information about where to redirect the user from what is called a command URL. Both of these URLs can be included in the home site cookie, can be given in the DNS system, and can be given a command URL in the HS certificate. In this way, the home site cookie can refer to the location from which the certificate can be obtained, and in the certificate, the MS 206 either finds the location of the HS 202 or only part of the URL is in the cookie and this URL's Based on the fragment, MS 206 adds a known prefix and suffix to generate both a command URL and a certificate URL.

  The registration process described above will now be described from three standpoints: user 200, home site 202 and route 210. From the perspective of user 200, user 200 visits home site 202 and requests an identity management account. In making this request, the user 200 is provided with a valid email address and is informed that an email message will be sent to the provided email address to complete the process. Upon receiving this email message, the user 200 responds to this challenge, preferably by clicking on the URL to confirm the validity of the email address. At this point, the user 200 is directly or indirectly connected to the home site 202 and an identity management account is established. Thus, from the perspective of the user 200, account registration is a simple process that is completely independent of whether the user 200 trusts the root 210 because the root is transparently involved. Instead, all trust issues relate to whether the user 200 trusts the home site 202. From the viewpoint of the home site 202, the home site 202 receives a request for a new identity management account from the user 200. An e-mail address is attached to this request. The email address is then forwarded to route 210 along with a request for GUID assignment. If the home site 202 succeeds in responding to the challenge, the home site 202 receives the GUID. In one currently preferred embodiment, the response to the challenge is provided to the home site 202 by the user 200 through a redirect URL. This challenge response is then sent by the home site 202 to the route 210, and in response, the route 210 provides the home site 202 with a GUID to associate with the user 200. In an alternative embodiment, the challenge response is provided directly from the user 200 to the route 210 and the home site 202 receives the GUID when the user 200 is redirected to the home site 202 by the route 210. Those skilled in the art will appreciate that the communication between the route 210 for transmitting the actual route GUID and the home site 202 should be made transparent to the user. As is apparent to those skilled in the art, sending information transparently between route 210 and HS 202 uses an encoded URL in the redirect and redirects the user along with a post-based HTTP request, as a transport mechanism. This can be done by redirecting the user with a cookie and in particular using back channel communication. This channel can later be used for communication between the home site and member sites.

  From the perspective of route 210, route 210 receives a request from home site 202 to associate a new GUID with the provided email address. To verify that the email account is valid, route 210 sends an email message containing the challenge to the email account. The challenge is preferably an encoded URL, which the user 200 clicks. If the user 200 clicks on the challenge encoded URL, the route 210 receives a challenge response from the user 200 or the home site 202. Upon receiving this challenge response, the route assigns a GUID to this email address and associates it with the home site 202. This GUID is transmitted to the home site 202 using a known technique.

  Those skilled in the art will appreciate that this process prevents assigning a GUID to a home site without a valid route reason. This maintains the integrity of the identity management system.

  In addition to assigning a GUID, another role of the route 210 is the definition of the schema that the HS 202 uses to store identity data. With the schema defined, the MS 206 can request a subset of user information, and any request can be made using a predefined field name to get an appropriate response. In the presently preferred embodiment, if the HS 202 does not need to store the entire schema and is required to provide information about a user that the HS does not store, the user 200 is informed that the HS 202 does not store the requested information. Inform and prompt the user to submit it and then send the stored and retrieved information to the MS 202 or provide the stored subset of requested information to the MS 206 for further information to the user It is up to MS 206 to ask 200. As a result of not requiring the HS 202 to store the entire schema for the user, the root can add new fields to the schema at regular intervals. This allows the route 210 to add new fields to store information about new reward programs or unexpected requests from member sites. In prior art systems, the schema was fixed once defined, and adding new fields to the schema was difficult if not impossible. By not forcing the home site 202 to store the entire schema, the root 210 can update the schema at any time, leaving the home site to connect to and request a new schema at their convenience. In this way, the home site 202 may be requested at a defined periodic interval when a new GUID is requested, or with other transactions with the route 210, or other schedules that the home site 202 defines. Can be used to check the new schema. In the presently preferred embodiment, the schema is stored as an extensible makeup language that can be queried to obtain a variety of information.

  FIG. 7 shows a method for the home site 202 to obtain an update schema from the route 210. In step 230, the home site sends a schema update request to route 210. In response to receiving a schema update request from home site 202, route 210 preferably determines the last transmitted schema at step 232. This step preferably includes determining the date of the last submitted schema by analyzing the sent update request. In step 234, route 210 sends the new schema to home site 202 that sent the update request. In the presently preferred embodiment, the route 210 uses the determined last sent schema and sends only the updated information list, including changes to the schema, without sending the entire schema. In step 236, the home site 202 receives the transmitted new schema information, employs new schema elements, and associates unimplemented fields corresponding to each of the new schema elements with each user account. Those skilled in the art will appreciate that any of a number of known techniques may be used to implement the new field, and the following examples are merely illustrative and not exhaustive. In one embodiment, upon receiving a new schema, home site 202 sends an email to the user notifying that additional information can be stored in the user file. In an alternative embodiment, the next time the user logs into home site 202, the user is informed that there are new schema fields and is prompted to click on a link that allows the user to implement the new fields.

  One skilled in the art will appreciate that many similar techniques can be used to send new schemas to member sites. However, when a member site receives a new schema, it may require an operator interaction to incorporate a request for information contained in the new schema.

  The manner in which the member site requests user authentication is shown in FIG. In order to provide the user with a single sign-on function, the identity management system of the present invention preferably employs a home site cookie provided to the user 200 in step 228 of FIG. This cookie desirably identifies the home site associated with the GUID. In order for this information to be available to all sites in the identity management network 212, the cookie is preferably readable by sites in the domain root.net. This prevents attempts to read the cookie if the member site attempts to access the cookie and the member site does not belong to the shadow domain. However, if the member site 206 is a member of the shadow domain, the member site obtains a GUID and a display of the home site associated with the GUID at step 238. As already mentioned, the MS 206 must redirect to the shadow domain to retrieve the cookie. This can be done by the user clicking on the link or before. The home site cookie identifies a home site that can authenticate the user 200. If the home site 202 determines that the home site 202 is identified in the home site cookie, the member site 206 redirects the user to the home site 202 along with the authentication request in step 240. In order to retrieve an authentication request, the HS 202 must belong to the shadow domain. In this way, the MS 206 can redirect the user to the HS 202 in the shadow domain 214 or the primary domain 204. If the HS 202 accepts the user 200 in the primary domain 204, the HS redirects the user 200 to the shadow domain 214 so that the authentication request can be retrieved. If home site 202 no longer belongs to the shadow domain, the operation fails because the redirect to retrieve the cookie is not translated to a valid address. However, if the home site 202 belongs to the identity management network 212, the redirect request allows the shadow domain address 214 to be converted to the address with which the user 200 is transferred to the home site 202 as a result. In step 242, the user submits an authentication certificate to home site 202. When authentication is complete, the home site 202 redirects the user to the shadow domain 216 or member site 206 in the primary domain at step 244 and provides user authentication information accessible to the shadow domain 216 to the member site 206. Thus, depending on the redirection provided by the HS 202, the MS 206 may need to redirect the user 200 to the shadow domain 216. Upon receiving the user authentication and redirect, in step 246, member site 206 authorizes user 200 to log in. In the presently preferred embodiment, the authentication is signed with HS 202, accompanied by a signed assertion of root 210 that HS 202 has authority to authenticate the GUID.

  One skilled in the art will readily appreciate that communication between the home site 202 and the member site 206 can be implemented in any of a variety of ways. In the presently preferred embodiment, when the member site 206 detects the home site cookie, the user can log in to the member site 206 by redirecting the user to the home site 202 in the shadow domain, as described in step 240. Request information by giving the user 200 a second cookie to identify the schema fields needed to do so. Upon accepting and subsequently authenticating the redirected user at step 244, the home site 202 redirects the authenticated user to the member site 206 in the shadow domain at step 244 for authentication information through cookies or other known techniques. It is desirable to give

  The above method will now be described in terms of users, member sites, home sites and routes. From the user's perspective, it is desirable for a user to visit a member site and click on a link indicating that the member site is part of an identity management network. This link redirects the user to the home site 202 where a certificate is presented to verify the identity. If the identity is successfully authenticated, the user is returned to the member site 206 and login is permitted.

  From the perspective of the member site, the member site 206 receives an indication from the user that it is registered at a home site belonging to the identity management network. Member site 206 requests a cookie from user 200 and receives it in the shadow domain. The cookie identifies home site 202 as a home site that can be authenticated. The member site 206 redirects the user 200 to the home site 202, authenticates the user 200, and requests the home site 202 to return the user to the member site 206 after authentication. The member site 206 receives the user through the redirect URL and further receives an indication that the user has been authenticated. This indication is preferably accessible in the shadow domain 216 and is accompanied by a signed signature of the root as described above.

  From the perspective of home site 202, user 200 establishes a connection as a result of redirection from member site 206. The user 200 generally submits a request from the member site 206 that authenticates the user's identity and prompts the user to return to the member site 206 upon authentication. In general, this authentication and redirect request is stored in a cookie provided by the user. Home site 202 then asks the user to submit a certificate to authenticate the identity. Upon receiving this certificate and authenticating the identity of the user 200 based on the presented certificate, the home site 202 redirects the user to the member site 206 and provides the member site 206 with an indication that the user has been authenticated.

  Route 210 is called twice during this process. In either case, the interaction with route 210 is done to ensure that the user is redirected to the shadow domain name. In this way, when the member site 206 redirects the user to the home site 202 in the shadow domain, the route 210 receives a request for a shadow domain name change. Upon receipt of this request, route 210 determines the current state of this shadow domain entity. Based on the current state of the shadow domain entity, the route 210 translates the shadow domain name into an address. In this way, if the home site 202 is currently part of an identity management network, its shadow domain name is translated to the same IP address that its actual domain name is translated. However, if the home site 202 has already been removed from the identity management network, the domain name change will result in an error or redirect to a page explaining to the user that the home site 202 is no longer part of the identity management network To do. Similarly, when the home site 202 redirects the user to the member site 206, the route 210 receives the shadow domain name change request, determines the current state of this shadow domain entity, and based on the determined current state, • Convert domain names to addresses.

  One skilled in the art will readily appreciate that management of shadow domains by root 210 is accomplished by maintaining subdomains under the root.net domain. Thus, when adding a member site or home site to the identity management network, route 210 modifies the domain name server lookup table to associate the IP address or domain name with the shadow domain name. Thanks to the synchronization of domain name servers on public communication networks such as the Internet, the role of route 210 in domain name translation can also be performed by multiple domain name servers that receive data from the route. The contractor will understand. However, those skilled in the art will appreciate that for shadowing the domain name server, logically all shadow domain conversion requests can be considered to be converted by the route 210.

  In addition to providing a single sign-on function, the present invention allows the HS 202 to provide this information to the MS 206 for the user to store identification information in the HS 202 and to facilitate registration for services provided by the MS 206. Provide a mechanism. This function appears to the user 200 as a form filling function.

  FIG. 9 illustrates a method of providing identity information stored by the HS 202 to the MS 206. Using this method, the user 200 can initiate a sign-up procedure at the MS 206 and have the HS 202 fill in the fields of the registration form with the appropriate stored values. Similar to the single sign-on function provided by the method of FIG. 8, the form filling method of the present invention begins with the user 200 displaying on the MS 206 that a home site belonging to the identity management network can provide identification information. This display preferably takes the form of clicking on a hypertext link indicating that the site is affiliated. After receiving the user's notification, MS 206 determines the home site of user 200 by searching for a cookie provided by user 200 in shadow domain 216 in step 248. Thereafter, in step 250, the user 200 is redirected to the HS 202 along with the information request. The information request includes a request for information required to fill in the fields of the form, and does not necessarily include a request for all information on the form, and it is not necessary to request all information stored in the HS 202. Can request a subset of the information that the HS 202 stores. The HS 202 preferably authenticates the user 200 after receiving a redirect in step 252 so that no one requests information about the user 200 for abuse purposes. Upon receiving authentication, the user 200 gives the HS 202 permission to transfer the requested information to the MS 206. This step is also considered optional, although desirable, as it depends on the service conditions agreed between the HS 202 and the user 200. The HS 202 then redirects the user 200 to the MS 206, preferably in the shadow domain, to ensure that the MS 206 belongs to the identity management network 212. Simultaneously with the redirect, the HS 202 provides the requested information to the MS 206 in step 254. In step 256, the MS 206 receives both the user 200 redirected from the HS 202 and the requested information. If the HS 202 has previously authenticated the user 200, the HS may not re-authenticate the user 200, but instead simply confirms that the user 200 has been authenticated.

  Those skilled in the art will appreciate that the MS 206 can request data stored by the HS 202 in a variety of ways. For simple queries, the MS 206 can request name and value pairs from the HS 202 so that the HS 202 can provide a response in a format that allows the MS 206 to receive the information in the desired order. Further, the MS 206 can request information using a structured query to the HS 202. This structured query can be given a structured response of other known techniques, but is generally answered with an XML-based result. Queries can also be made on information that is dynamically determined by the HS 202 or information hosted by a third party that is not directly hosted by the HS 202 and that the HS 202 maintains a link in between. For simple queries based on name-value pairs, MS 206 returns the value stored in the schema under one name for the form given by MS 206 using the form-based name used by MS 206. You can specify a name that will be returned with the value so that you can. This allows a member site with a pre-existing data collection system to request information from the home site and receive data through a POST operation to implement a field in its HTML form. This allows MS 206 to join the identity management network with minimal modifications to its existing pages. Further, in the presently preferred embodiment, the simple query includes a redirect URL value so that the HS 202 can redirect the user 200 to the next page in the data collection phase of the MS 206. In order to allow automatic form filling, the HS 202 provides the MS with the requested information related to the provided name, in any required order, and automatically redirects the provided data to the MS 206. Giving the URL redirects the user 200 to the next page of the sign-in procedure. For structured queries, the HS 202 preferably redirects the user 200 to the MS 206 by a POST operation that provides the required structured data, preferably in the form of an XML file. The HS 202 can store machine readable data, such as user photos, and can provide it in response to queries from the MS 206. The dynamic data can include data such as the length of time since the last authentication and can be provided in response to a simple query or a structured query. As described above, HS 202 can store data as a reference to another site, for example, user 200 can store calendar data in a third party and HS 202 can store a link to it. . Assume that MS 206 is an airline that makes structured queries to obtain an XML-based report on the availability of user 200 one day to schedule a flight. The HS 202 can indicate a reference to the calendar site or query the calendar site to obtain the results and provide this to the MS 206. Communication with a third party such as a calendar site is preferably performed using a predefined protocol.

  Other data that can be provided in response to the query includes a third party assertion associated with the GUID. The assertion has been previously described with respect to a signed assertion by the route 210 that asserts that the home site has authority to authenticate the GUID, but the assertion can also be given by other actors. Government agencies can provide a statement that associates a birthday with a GUID so that MS 206 can receive a signed statement that user 200 is over a certain age from a trusted authority. The mechanism for the MS 206 to obtain a certificate or public key for authenticating the assertion is described below. Other representations include, for example, an indication that the user has reached a premium service level in a reward program. Using this statement, the member site can provide the user 200 with a discount service based on the premium membership system. Other third party signed representations will be apparent to those skilled in the art. The assertion is stored by the HS 202 or stored as a link by the HS 202 to allow the MS 206 to directly retrieve an assertion from a third party.

  Simple queries are typically answered through URL encoding, but extensible queries are preferably answered by passing information to the MS 206 through an HTTP post operation.

  Since the schema used to store user information is dynamic, a mechanism for obtaining user information after initial signup is needed. Although it is believed that HS 202 can prompt 200 to add authentication or information requesting information, the present invention provides a new way of obtaining user information for HS 202 to store. This method is illustrated in the flowchart of FIG.

  The architecture of the present invention allows a user to implement schema fields from member site 206 or modify existing information stored by home site 202. This method is illustrated in FIG. Upon requesting and receiving information about the user from home site 202, member site 206 determines in step 258 that more information is needed and prompts user 200 to enter this information. In an alternative embodiment, the MS 206 asks the user to confirm the information provided by the HS 202. In step 250, the user provides information to member site 206, instructing this information to be sent back to home site 202, preferably by clicking on a hypertext link. At this point, the member site 206 redirects the user to the home site 202 using the shadow domain address and forwards the information provided by the user to the home site 202. The transfer of information provided by the user can be done using back channel communication, an encoded URL in the form of a simple query or a cookie conveyed by the user. Upon receiving both the redirected user and the transmitted information, the home site 202 presents the information to the user and asks for approval of the information. Upon receiving approval of information from the user 200 in step 254, the home site 202 stores the information in a schema. At this point, the user is returned to member site 206 in step 256. In another embodiment, the MS 206 determines that new information is available as a result of the interaction with the user 200 and should be provided to the HS 202. MS 206, like step 260, asks the user for permission to send data back to HS 202 and the process continues as described above. As an example of an alternative embodiment, MS 206 is an airline that has booked a flight for user 200. The MS 206 has structured information to be provided to the HS 202 for storage in the user 200 calendar. The structured data is preferably transferred as an XML file that includes the flight number, destination, takeoff and landing times, and other relevant information. HS 202 stores data if HS is the host of the calendar for user 200, redirects information to the calendar provider if the calendar provider is a third party, or The update can be responded to by providing the MS 206 with the address of the other party to send. Thus, the information provided to the HS 202 may be structured information or simple information, and may be stored data or reference data. In the presently preferred embodiment, MS 206 does not ask for user permission for all updates of HS 202 information. In the airline booking example described above, if the flight is delayed, it is desirable for the MS 206 to be able to automatically update the HS 202 without user approval.

  As already mentioned, one of the advantages of the present invention is that information stored by a home site is portable to another home site. There may be numerous reasons why a user wants to move data from one home site to another, including the cost, the amount of information the home site wants to store, and the service conditions of the home site. In prior art systems, there was no equivalent to transfer data or the data was not portable, but the system of the present invention assigns a unique GUID to user 200 and uses a defined schema. By requiring the HS 202 to store user information, the portability of user information is guaranteed. Thus, to change the home site, the user 200 visits the second home site and requests to associate a new account with an existing GUID. By maintaining the same GUID, the user can maintain an account at the member site that is recording information using the GUID as an identifier. Almost like the registration process, the route 210 challenges the user to respond to the challenge to make sure that the fraudulent home site is not trying to take the user away from another home site. To request. The transfer of the registration process is the same as the challenge response phase, and if the challenge response is successful, the route 210 issues a command to the current home site requesting that all schema related information be transferred to the new home site. This is done using back channel communication or URL encoding, or preferably the route 210 redirects the user 200 to the original home site and stores a cookie containing all personal information stored on the original home site. And then redirecting the user 200 to a new home site. Redirection from the first home site to the second home site can be performed by redirecting the user 200 to the route 210 so that the original home site is not known where the user went. Once redirected directly or indirectly to a new home site, user 200 is a site that provides a cookie that stores all schema related information to verify the GUID and the new home site is associated with the GUID. You will receive a new cookie indicating that.

  In the presently preferred embodiment, the newly chosen home site can direct the user to the initial home site for authentication in order to eliminate the need to resend the challenge email. If this authentication is successful, the route 210 can consider this as evidence that the user has the authority to transfer the GUID to another home site.

  Although prior art identity management methods have given PUIDs to member sites, the present invention provides GUIDs that can be used to obtain third party representations due to their global nature. A PUID cannot support a third party assertion without the IDP sharing the PUID mapping with the third party, and thus without denying the purpose of the PUID. To provide the user 200 with the benefits afforded by the PUID, the HS 202 can allow the user to obtain multiple GUIDs. By acquiring multiple GUIDs, the user 200 can create multiple online personas so that different member sites cannot correlate behavior online. This gives the user 200 the option to obtain PUID security while retaining the advantages of the GUID. In order to be able to manage multiple GUIDs, the user 200 is prompted by the HS 202 for which GUID to give to the member site during authentication. This allows the user to provide a set of information to the HS 202 and configure different profiles for each GUID. In this way, a work-based persona with a certain GUID defaults to the work phone number and address when a member site requests a phone number and address, while a home-based persona with a different GUID You can give your home phone number and address by default when an address is requested.

  As stated above, the assertion is preferably provided by the route 210 to provide proof that the member 202 has authority to authenticate the GUID. This assertion is preferably signed using a private key or certificate, and the signature can preferably be verified using a public key or certificate. The certificate is preferably obtainable by communication with root 210 over a secure data channel. To ensure that the certificate has not been tampered with, the root 210 certificate is signed by the first certification authority (CA) and passed to the requesting party through an SSL link signed by a second different CA. It is desirable to be sent. This double chain of signatures is necessary to prevent both the first CA and the second CA from being compromised because a malicious party can misrepresent the route 210. The authentication information provided by the home site is preferably signed by this home site so that it is also a certificate. This information is preferably signed by the home site so that the member site can be confident that it has not been tampered with or that the home site has been spoofed by a third party. To confirm the assertion by the home site, the member site can obtain a certificate from the home site through a CA-signed SSL connection along with a root-signed home site certificate. Since the CA and root are distinct, there is another security double chain, which is necessary to prevent security violations at both the CA and the root. The third party assertion is preferably a certificate available through an SSL connection, a root or CA signed certificate, and a signed by a CA signed connection different from the one that signed the certificate. In order to verify the certificate transmitted in the identity network 212, the above double signature transmission is desirable.

  In the presently preferred embodiment, when a signed assertion is presented, the MS 206 obtains a certificate that is used to verify the signature and places the certificate in cache memory. In the next signature verification using this certificate, the MS 206 does not need to request the certificate again, but must make sure that the certificate is up-to-date. To this end, the MS 206 performs a DNS txt lookup for the certificate holder's shadow domain name. When root 210 provides DNS service for the shadow domain, it maintains its certificate number in the txtDNS field of each executing entity. If the value returned from the DNS lookup is the same as the certificate number, the MS 206 can verify the signature, and if the certificate number is different, the MS 206 discards the cached certificate and creates a new certificate. Request.

  In order to allow a member site to participate in the identity management network 212 without adding scripting capabilities that allow key management and without a shadow domain migration, the MS 206 will add its shadow domain 216 to the home site It can be associated with a third party that handles the reading of cookies, redirection to HS 202 and the provision of data provided by HS 202. Furthermore, this third party can simply handle the necessary signature check to verify the integrity of the received data. One skilled in the art will appreciate that a single actor can provide this functionality for multiple member sites.

  A common requirement for existing single sign-in services is the provision of a single sign-out function. For this reason, it is desirable that the member site that has accepted the user's sign-in corrects the cookie transmitted by the user 200. This cookie tracks the member site where the user logs in. In the currently preferred embodiment, the cookie provides a URL that allows the user to log out. To sign out of the service, the user 200 returns to his home site 202 to inform that he wants to log out of all services or a subset thereof. The home site 202 can be processed through a URL given in a cookie to allow the user to sign off with a single click. Instead, the MS 206 either logs out the user 200 from the MS 206 and removes the member site reference in the cookie, or provides a logout link that can redirect the user 200 to the HS 202 to follow the logout process described above. It can be given to the user 200. In another embodiment, when the HS 202 authenticates the user 200 for the MS 206, the HS 202 may store a logout URL for the MS 206 in a user profile database. Accordingly, the user 200 visits the HS 202 and requests a list of current login sites to log out. This list should give the user the ability to log out from any or all member sites.

  The present invention provides the user with simplified sign-in and registration to the member site so that the user can visit the member site and indicate that the user is part of an identity management network. This is preferably done by clicking on an icon or link on the sign-in page. When this link is clicked, the MS 206 searches for a cookie that identifies the user 200 and redirects the user 200 to the HS 202. In the case of a simple sign-in to the MS 206, the redirect to the HS 202 is only for authentication if registration has been done previously. If the user 200 has not previously been registered with the MS 206, the redirect to the HS 202 is for both authentication and information request. The MS 206 requests a subset of information stored in the HS 202 using a simple URL-encoded redirect, or requests extensible information by using a query stored in a cookie carried by the user 200 be able to. When redirecting user 20 to HS 202, user 200 is sent to the shadow domain of HS 202 to ensure that HS 202 still belongs to the identity management network. After giving the HS 202 the authorization required for the authentication certificate and data transfer, the user 200 is redirected to the MS 206. Confirmation that both MS 206 and HS 202 belong to the shadow domain and are therefore active in the identity management system is transparent to the user and the user utilizes a simplified process for login and registration can do. Since the MS 206 can send information back to the HS 202, the user 200 is provided with a simplified mechanism to ensure that the HS 202 has updated new information.

  Since the user 200 is authenticated by the HS 202 after being redirected from the MS 206, the user 200 generally confirms that the correct redirect has occurred by checking the URL in the browser window navigation or location bar. There is a need. For additional security, the HS 202 can store a series of user preferences obtained from the user 200 that define the user interface and experience. These preferences can include user-defined background page colors, customized icon sets, user-defined greetings, and user-selected language interfaces. These preferences can be obtained from the user 200 at registration, stored in the user profile database, and retrieved when the user 200 is redirected for authentication. When a malicious party attempts to spoof HS 202, the user-defined preferences are not available, so the user 200 will immediately notice that he has been redirected to the wrong site.

While the hierarchical structure of the present invention can address security breaches from a single point, the distributed nature of the home site eliminates a single point of failure that releases user information. If the integrity of route 210 is compromised, all root. The net domain can be removed. The DNS authority shuts down the entire identity management network 212. This prevents the release of user information and prevents fictitious home sites from spoofing users. If the route 210 is compromised, no user-specific data is released, unlike the Passport ^TM model. If a single home site is compromised, its user data will be released, but it is inappropriate because it cannot be retrieved from the shadow domain by excluding this home site from the shadow domain Is prevented from being granted proper authentication. In this way, the compromised home site can be effectively removed from the network within the time it takes for the address update to propagate throughout the DNS network. In the Liberty Alliance model, which does not provide a single point of failure, there is no simple way to remove IDPs that are at risk from the web due to the complexity of the key ring on the trusted web. Thus, the present invention provides a mechanism for isolating a compromised home site through its structure, eliminating a single point of failure that allows the release of user data and preventing user spoofing. .

  The above-described embodiments of the present invention are merely examples. Those skilled in the art can make changes, modifications, and changes without departing from the scope of the present invention, which is defined only by the claims appended hereto.

Embodiments of the present invention have been described by way of example only with reference to the accompanying drawings in which:
FIG. 1 is a block diagram of a prior art identity management system. FIG. 2 is a block diagram of a prior art identity management system. FIG. 3 is a block diagram of a prior art hierarchical identity management system. FIG. 4 is a block diagram of a prior art distributed identity management system. FIG. 5 is a block diagram of the hierarchical distributed identity management system of the present invention. FIG. 6 is a flowchart illustrating the method of the present invention. FIG. 7 is a flowchart illustrating the method of the present invention. FIG. 8 is a flowchart illustrating the method of the present invention. FIG. 9 is a flowchart illustrating the method of the present invention. FIG. 10 is a flowchart illustrating the method of the present invention.

Claims (25)

An identity management system for providing user authentication to member sites, the identity management system comprising:
A root server having a user database for storing a globally unique identifier associated with a user, wherein when the root server redirects the user to a name associated with a home site belonging to a shadow domain, the member site To give the user the globally unique identifier and to give to a domain name server, so that the home site can authenticate the executing entity accessing the user as the user associated with the globally unique identifier. Means for maintaining a list of network addresses associated with a name in the domain, wherein the name relates to the member site or home site belonging to the identity management network. Attached, the root server,
Including an identity management system.   In the identity management system, the root server includes a home site authentication message for providing the member site with authentication of authority of a home site for authenticating the execution subject as a user associated with the globally unique identifier. The identity management system according to claim 1.   And further comprising a home site in communication with the root server and having a domain name in a user profile database, a user authentication engine and a shadow domain namespace, wherein the user profile database is associated with the user. Identity management according to claim 1 or 2, for storing both a globally unique identifier and authentication information, wherein the authentication engine enables the home site to authenticate the identity of the user. system.   The identity management system according to claim 3, wherein the authentication information is a combination of a user ID and a password.   In the identity management system, the user profile database further stores identity information associated with the user, and the authentication engine includes means for providing a subset of the identity information to the member site upon authentication of the user. 5. An identity management system according to claim 3 or claim 4.   In the identity management system, the authentication engine provides the authenticated user identity to the user by providing the user with a cookie containing authentication information readable by the member site and redirecting the user to the member site. The identity management system according to any one of claims 3, 4, and 5, which is given to a member site.   7. The identity management system of claim 6, comprising an indication by the root server that the cookie is signed with the home site and that the home site is authorized to authenticate the globally unique identifier. Identity management system.   In the identity management system, the authentication engine provides the user with a cookie containing authentication information readable by redirecting the user to an authentication encoded universal source locator or by the member site. The identity management system according to claim 5, wherein the identity information associated with the user is provided to the member site by redirecting the member site to the member site. A method for obtaining user authentication from a home site in an identity management network, the method comprising:
Obtaining from the user a name of a home site that can provide user authentication based on user authentication information known to the home site;
Providing an authentication request to the home site by redirecting the user to the home site in a shadow domain associated with the identity management network;
Obtaining the user's authentication from the home site in response to the home site receiving the known authentication information from the user, the authentication including a globally unique identifier associated with the user; ,
Including a method.   10. The method of claim 9, wherein obtaining the name of the home site from the user comprises the member site examining a cookie provided by the user.   10. The method of claim 9, wherein providing an authentication request to the home site comprises the user converting a name associated with the home site in the shadow domain to a network address.   10. The method of claim 9, wherein providing an authentication request to the home site includes providing the user with a cookie that is readable by the home site and includes the user's authentication request. .   In the method, the home site can provide both user authentication information and user identity information, and the step of providing an authentication request to the home site further includes the step of the member site providing an identity information request to the home site. 10. The method of claim 9, comprising.   14. The method of claim 13, wherein obtaining the authentication further comprises obtaining identification information in response to the home site receiving the known authentication information from the user. further,
Obtaining identity information not provided by the home site;
Providing the obtained identity information to the home site by redirecting the user to the home site in the shadow domain;
14. The method of claim 13, comprising:   16. The method of claim 15, wherein the identity information not provided by the home site is obtained from the user. A method for performing user authentication at a home site belonging to an identity management network using the system according to claim 2, wherein the method includes:
Receiving from the user a request to authenticate for a member site;
In response to receiving known authentication information, providing authentication of the user to the member site by redirecting the user to the member site in a shadow domain associated with the identity management network;
Including a method.   18. The method of claim 17, wherein providing authentication of the user to the member site includes receiving a user ID and password combination associated with the user's globally unique identifier from the user.   18. The method of claim 17, wherein providing authentication of the user to the member site comprises converting the name associated with the member site in the shadow domain to a network address. Method.   In the method, providing the user's authentication includes providing the user with a cookie that is readable by the home site and includes the user's authentication and the globally unique identifier associated with the user. The method of claim 17.   The method of claim 17, wherein receiving a request to provide the authentication information comprises receiving a request for identity information.   The method of claim 21, wherein providing the authentication comprises providing identification information to the member site after receiving the known authentication information from the user.   23. The method of claim 22, comprising obtaining a user's permission to forward the requested identification information to the member site prior to providing the member site with identification information. further,
Receiving identity information obtained by the member site from the user;
Storing the transferred identity information in a user profile database;
The method of claim 21, comprising: A method for obtaining a globally unique identifier for association with a user using the system of claim 2, comprising:
Receiving from the user a request to associate a globally unique identifier with an email address;
Requesting a root server to assign a globally unique identifier associated with the user email address;
Obtaining a globally unique identifier associated with the email address in response to providing the route with a response to what the user is sent to the email address;
Including a method.

Images