Source: https://patents.google.com/patent/US20090320095
Timestamp: 2018-02-20 00:26:42
Document Index: 163002541

Matched Legal Cases: ['arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120']

US20090320095A1 - Obtaining digital identities or tokens through independent endpoint resolution - Google Patents
Obtaining digital identities or tokens through independent endpoint resolution
US20090320095A1
US20090320095A1 US12141515 US14151508A US2009320095A1 US 20090320095 A1 US20090320095 A1 US 20090320095A1 US 12141515 US12141515 US 12141515 US 14151508 A US14151508 A US 14151508A US 2009320095 A1 US2009320095 A1 US 2009320095A1
US12141515
US8074258B2 (en )
A federated identity provisioning system includes relying parties, identity providers, and clients that obtain tokens from identity providers for access to a relying party's services. When a client contacts a new relying party, the relying party provides information that the client can independently resolve and evaluate for trustworthiness. For example, the relying party provides a generic domain name address. The client can then resolve the domain name address over various, authenticated steps to identity an endpoint for a digital identity provisioning service. The client can further interact with and authenticate the provisioning service (e.g., requiring digital signatures) to establish a trust relationship. Once determining that the client/user trusts the provisioning service, the client/user can then provide information to obtain a digital identity representation. The client can then use the digital identity representation with the corresponding identity provider to obtain one or more tokens that the relying party can validate.
Conventional computer systems are now commonly used for a wide range of objectives, whether for productivity, entertainment, or the like. One reason for this is that computer systems tend to add efficiency with task automation, as well as making certain types of transactions more efficient. For example, some types of transactions in the past might have taken users hours or days to complete. In particular, if a user were to make a bank deposit, bank transfer, or even purchase items in a store, the user might have needed to physically travel to the bank or store location in order to verify the user's identity and present instructions for the transaction. Upon verifying the user's identity, the bank or store might then initiate and confirm the requested transaction. In this scenario, the bank or store could be considered a “relying party,” which relies on the in-person identity provided by the user, who is an “identity provider.”
Some conventional mechanisms attempt to mitigate some of these concerns by implementing “federated” identity verification systems. In federated systems, a separate identity provider maintains data that can be used to generate one or more security tokens for many of a user's different accounts at various relying parties. In general, a “security token” is the means by which an identity provider asserts a user's identity to a relying party. So that the security tokens are portable across many different relying parties, this type of identity provider will need to establish a trust relationship with each of the different relying parties for which the user would like access.
For example, if the above scenario were established so that a relying party automatically directs a client system to a particular identity provider, the user could be at risk for a “phishing” attack. In particular, a malicious relying party that the user believes is legitimate may automatically direct the user to a malicious identity provider. When the user attempts to establish an identity representation with the malicious identity provider, the identity provider could simply steal the user's identity and take advantage of the user. The identity provider could even provide a token for access to the malicious relying party, and thus maintain appearances for an extended period of time.
Implementations of the present invention overcome one or more problems in the art with systems, methods, and computer program products configured to provide independent user/client verification of digital identity representation provisioning services before obtaining tokens for use with a relying party. In at least one implementation, for example, in response to a request for services at a relying party, a client receives metadata about one or more identity providers trusted by the relying party. The client then independently resolves the metadata to identify a digital identity provisioning service offered by the identity provider, and to determine if the client can trust the provisioning service. If trusted, the client can then establish a digital identity representation with the corresponding identity provider through that provisioning service, and obtain one or more tokens for use with the relying party.
Implementations of the present invention extend to systems, methods, and computer program products configured to provide independent user/client verification of digital identity representation provisioning services before obtaining tokens for use with a relying party. In at least one implementation, for example, in response to a request for services at a relying party, a client receives metadata about one or more identity providers trusted by the relying party. The client then independently resolves the metadata to identify a digital identity provisioning service offered by the identity provider, and to determine if the client can trust the provisioning service. If trusted, the client can then establish a digital identity representation with the corresponding identity provider through that provisioning service, and obtain one or more tokens for use with the relying party.
Accordingly, and as will be understood more fully herein, implementations of the present invention provide one or more mechanisms by which an identity provider can publish the location of services that can issue digital identity representations (or DIR, also referred to as “information cards”). Implementations of the present invention also provide one or more mechanisms by which an identity provider can publish alternative information, which allows a user to establish a relationship with the identity provider before obtaining a DIR. In addition, implementations of the present invention provide one or more mechanisms by which an identity selector (e.g., a component or application on the client system) can find out if DIRs for a particular identity provider are available, and present the information to users to help them obtain their DIRs.
In addition, FIG. 1A shows that the federated identity provisioning system 100 comprises one or more identity providers 110(a, b, etc.), which each also have their own determination modules 145(a, b, etc.) and corresponding one or more digital identity provisioning services 150(a, b, etc.) As understood more fully herein, the one or more identity providers 110 verify the identity of a user/client to a relying party with one or more “security tokens” (e.g., 210, FIG. 2). In general, a security token provides various claims about a user in a format/configuration that is mutually agreed upon by a relying party 120 and trusted identity provider 110. For example, a relying party 120 in the form of a bank or online store requires independent verification of user/client 105 credentials before providing the requested services to the client 105; a trusted identity provider 110, in turn, provides this verification through one or more security tokens, which comprise expected data used to verify the user's credentials.
The client 105 cannot, however, simply request a security token from an indicated identity provider 110. Rather, the client 105 will need to establish a relationship of trust with the identity provider 110. Furthermore, the client 105 cannot simply gain a relationship of trust with any given identity provider 110 for purposes of interacting with any particular relying party 120. Rather, the client 105 needs to obtain a relationship of trust with a particular identity provider 110 that is also trusted by the particular relying party 120 for which the client requests services. That is, not every relying party 120 will have a trust relationship with every identity provider 110, and vice versa. For example, FIG. 1A shows that relying party 120 a maintains a list 125 a of trusted identity providers 100, which includes in this case identity provider 110 a, but not identity provider 110 b. Similarly, FIG. 1A shows that relying party 120 b maintains a list 125 b of trusted identity providers 100, which includes in this case identity provider 110 b, but not identity provider 110 a.
In general, the client's (on behalf of the user) relationship of trust with a given identity provider is manifest in the aforementioned digital identity representation, or DIR (113). The client, in turn, uses a particular DIR 113(a, b, etc.) in order to obtain a security token with a particular identity provider 110, ultimately for use with services at one or more relying parties that trust the particular identity provider. Thus, for example, FIG. 1A shows that client 105 maintains a DIR store 107, which includes in this case a DIR 113 a for identity provider 110 b, which is used for services with relying party 120 b since only relying party 120 b, and not relying party 120 a, trusts identity provider 110 a. Accordingly, one will appreciate that any given DIR 113 may be used with multiple different relying parties 120.
In addition, although the client 105 can maintain any number of DIRs 113 in store 107, FIG. 1A shows that client 105 only has a single DIR 113 a for purposes of simplicity. In this example, the illustrated DIR 113 a allows client 105 to obtain security tokens from identity provider 110 b for use with relying party 120 b. By contrast, FIG. 1A also illustrates that client 105 does not have a DIR corresponding to an identity provider 110 a, and/or for use with services at relying party 120 a.
Accordingly, as shown in FIG. 1A, when client 105 attempts (e.g., message 155) to access services with relying party 120 a, relying party 120 a ultimately directs client 105 to an identity provider (i.e., 110 a) for which the client 105 has not yet established a relationship (i.e., there is no DIR 113). For example, FIG. 1A shows that, in response to message 155, relying party 120 a (e.g., via determination module 140 a) determines that client 105 still needs to present a security token to access services. Thus, FIG. 1A shows that relying party 120 a responds with one or more policies 160.
The information/policies 160 provided by relying party 120 a in turn, can comprise any number or types of information. As previously mentioned, for example, the policies 160 can comprise various metadata elements (e.g., in accordance with the WS-FEDERATION specification) regarding a network endpoint for a particular identity provider 110. In additional or alternative implementations, the one or more metadata elements comprise or otherwise indicate one or more generalized domain names, which client 105 will need to resolve further in order to determine the appropriate endpoint. For example, the one or more policies 160 can comprise information such as “use an identity provider from BANK.com”. In such a case, client 105 would need to resolve BANK.com to identify one or more identity providers 110, and obtain a security token therefrom.
In the illustrated case, FIG. 1A shows that service requester 130 is instructed to find (and communicate with) identity provider 110 a to obtain an appropriate DIR 113. FIG. 1A also shows that the information 160 regarding identity provider 110 a needs further resolution, since it does not represent a precise network endpoint. Accordingly, FIG. 1A shows that service requester 130 contacts one or more domain name resolution services 115 with one or more messages 175. In additional or alternative implementations, service requester 130 contacts one or more other agents or services, which, in turn, contact network resolution service 115 with message 175. In either case, FIG. 1A shows that client 105 ultimately receives one or more messages 180 with the resolved information 180, which includes in this case, a specific network endpoint for identity provider 110 a.
Of course, one will appreciate that network resolution service 115 could additionally or alternatively respond with one or more other domain names for other services or agents. Such a response could require service requester 130 to still further contact other entities to obtain additional information/resolutions before obtaining an endpoint corresponding to identity provider 110 a. For example, response 180 could include a list of identity providers that could potentially correspond with the name for identity provider 110 a. Service requester 130 could then contact any or all of the identified identity providers in the list on a continuing basis until identifying the appropriate and specific network endpoint for the identity provider 110 a indicated by relying party 120 a. However conducted, it is notable that client 105 (e.g., on behalf of the user) independently determines or resolves network endpoints without specific direction from relying party 120 a.
In any event, upon receiving the endpoint via message 180, FIG. 1A shows that service requester 130 sends one or more messages 185 to identity provider 110 a (i.e., the resolved endpoint corresponding thereto) in order to obtain information about its DIR provisioning service. If client 105 had a previously-established relationship of trust, and already had an appropriate DIR 113, client 105 could then use that DIR (e.g., via message 200, FIG. 2) to request an appropriate security token (210, FIG. 2) for relying party 120 a. Since, in this case, client 105 does not have a DIR for identity provider 110 a, client 105 thus asks for the location of an appropriate DIR provisioning service.
In response, FIG. 1A shows that identity provider 110 a sends one or more messages 190, which generally identify a digital identity representation provisioning service 150 a (i.e., “DIR Provisioning Service”). As with policies 160, the one or more messages 190 can also comprise a published document comprising metadata elements having one or more specific network endpoints. In additional or alternative implementations, however, the information in message 190 can comprise resolvable domain names, which service requester 130 must resolve (e.g., via resolution service 115) in one or more additional steps to identify a network endpoint for the DIR provisioning service 150. In either case, and upon identifying the correct network endpoints for the DIR provisioning service 150 (i.e., 150 a), client 105 then attempts to obtain a DIR 113.
For example, FIG. 1B shows that service requester 130 sends one or more messages 193 to the identified digital identity provisioning service 150 a, requesting one or more DIRs 113 for use with a relying party, such as relying party 120 a. In general, this can include not only a general request to initiate/create a DIR 113, but also a series of requests and responses (i.e., multiple different messages) in order to establish and obtain the DIR 113. For example, DIR provisioning service 150 a may request personal information about a user (through client 105), and the user, via client 105 may need to provide several corresponding responses. Such requests can include information regarding credit card information, driver's license information, social security card information, and other challenge-based information that can be used to personally identify the user in some way. Upon validating the user's information/credentials (provided by service requester 130), DIR provisioning service 150 a can then respond with an appropriate DIR 113. For example, FIG. 1B shows that DIR provisioning service 150 a sends to client 105 one or more messages 195 regarding a newly created DIR 113 b pertaining to identity provider 110 a, which, in this case, client can use with relying party 120 a.
As shown in FIG. 2, client 105 stores this new DIR 113 b in its DIR store 107. In addition, client 105 can then use the new DIR 113 b to obtain one or more security tokens 210 in order to access services with relying party 120 a. As shown in FIG. 2, for example, client 105 (i.e., via service requester 130) sends one or more new messages 200 to identity provider 110 a. In this case, the one or more messages 200 include information corresponding to the newly created DIR 113 b, as well as a request for one or more security tokens to access services at relying party 120 a.
In response, determination module 150 a at identity provider 110 a then validates the provided DIR 113 b. For example, determination module 145 a at identity provider 110 a determines that the new DIR 113 b corresponds to (or was created by) a DIR provisioning service 150 that was based on the one or more metadata elements in messages 190. As such, since the DIR 113 b has been authenticated or validated, FIG. 2 shows that identity provider 110 a responds with one or more corresponding security tokens 210. Specifically, FIG. 2 shows that identity provider 110 a sends the one or more security tokens 210 directly to client 105, whereupon client 105 provides the one or more security tokens 210 in one or more corresponding messages 220 to relying party 120 a. Of course, one will appreciate that identity provider 110 a may additionally or alternatively send the one or more security tokens 210 directly to relying party 120 a.
In addition, FIG. 2 shows that relying party 120 a processes the security token 210 received in the one or more messages 220 through determination module 140. For example, determination module 140 a processes the security token 210 to determine if it conforms to the one or more data elements of in the previously-provided information 160 (FIG. 1). In one implementation, this includes the relying party 120 a determining that the received security token 210 is from a trusted identity provider (e.g., 110 a), and that the security token 210 includes expected data for verifying the user that is requesting services. Upon identifying that the security token 210 is valid, and/or (in conjunction with the security token 210) that the user information provided by client 105 is verified, relying party 120 a can then grant access to the requested services. For example, FIG. 2 shows that relying party 120 a sends one or more messages 230 back to client 105, which allow client 105 to access the requested services.
For example, FIG. 3 illustrates that a method from the perspective of client 105 can comprise an act 300 of contacting a relying party (RP) for services. Act 300 includes contacting a relying party to access one or more services at the relying party. For example, FIG. 1A shows that client 105 sends one or more messages 155 to relying party 120 a, which request access to one or more services at relying party 120 a.
FIG. 3 also shows that the method from the perspective of client 105 can comprise an act 310 of receiving information about a trusted identity provider (IP). Act 310 includes receiving one or more policy files from the relying party, wherein the one or more policy files comprise information that identifies a generalized name corresponding to a set of one or more trusted identity providers. For example, FIG. 1A shows that, since client 105 does not have an established relationship with relying party 120, relying party sends one or more messages 160 back to client 105. In this particular case, the one or more messages 160 include information indicating generalized information about trusted identity provider 110 a. As understood more fully herein, such information 160 could include a specific network endpoint for identity provider 110 a. Of course, such information 160 can also or alternatively include a generalized domain name of the identity provider 110 a, or to yet another service 110 a that can be contacted to identity the network address for identity provider 110 a.
In addition, FIG. 3 illustrates that a method from the perspective of client 105 can comprise an act 320 of resolving the identity provider name to a trusted network endpoint. Act 320 includes automatically resolving the generalized name to obtain one or more network endpoints for one of the trusted identity providers. For example, service requester 130 at client 105 automatically sends one or more messages 175 to a network resolution service 115 and requests resolution of a generalized domain name found in information 160. In turn, service requester 130 receives one or more messages 180 that resolve the initially-provided generalized name corresponding to identity provider 110 a to one or more particular network endpoints. Alternatively, service requester 130 automatically contacts a specific network endpoint found in information 160, and asks the entity at the network endpoint to provide the location of an appropriate identity provider 110.
FIG. 4 also illustrates that the method from the perspective of identity provider 110 can also comprise an act 410 of providing information for a digital identity representation provisioning service. Act 410 includes providing to the client information that identifies one or more digital identity provisioning services trusted by the identity provider. For example, as previously mentioned, FIG. 1A shows that, in response to a request 185, identity provider 110 a provides information via one or more messages 190. In at least one implementation, the one or more messages 190 comprise a published security document, or at least a portion of the information contained therein. Such information can include domain names for the DIR provisioning service 150 a (which may need further resolution via network resolution service 115), or simply the specific network endpoints for service 150 a.
In addition, FIG. 4 shows that the method from the perspective of identity provider 110 comprises an act 420 of authenticating a digital identity representation provided by a client. Act 420 includes authenticating one or more digital identity representations received from the client, wherein the identity provider determines that the received one or more digital identity representations are valid. For example, as shown in FIG. 2, identity provider 110 a (e.g., via determination module 145 a) evaluates DIR 113 b provided by client 105 in message 200. Specifically, identity provider 110 a determines that DIR 113 b was created and provided by the DIR provisioning service 150 a previously referred to in the one or more messages 190. As such, identity provider 110 a confirms that client 105 that provided DIR 113 b via message 200 is the same client 105 that requested the DIR provisioning information via message 185.
Furthermore, FIG. 4 shows that the method from the perspective of identity provider 110 can comprise an act 430 of providing a security token to the client. Act 430 includes providing one or more security tokens corresponding to the authenticated one or more digital identity representations. For example, FIG. 2 shows that, upon validating the digital identity representation 113 b in message 200, identity provider 110 a sends one or more security tokens 210 back to client 105. Client 105 can then use the provided security tokens 210 to verify the requesting user's identity with relying party 120 a.
Accordingly, implementations of the present invention provide a number of different components and mechanisms for safely, securely, and efficiently providing clients with access to appropriate security tokens. As discussed herein, for example, such mechanisms can include means by which a client's identity selector to determine if DIRs for a particular identity provider are available, and, if not, a way to help the users obtain an appropriate DIR. Such mechanisms can also enable identity providers to provide (e.g., via publications or otherwise) various metadata elements to the users, where the metadata elements indicate the location of DIR provisioning services that can issue appropriate DIRs. As previously mentioned herein, such information (e.g., in the form of metadata elements) can be published in such a way as to enable independent resolution by a client of the various endpoints, thus enhancing security in the overall federated system.
contacting a relying party to access one or more services at the relying party;
receiving one or more policy files from the relying party, wherein the one or more policy files comprise information that identifies a generalized name corresponding to a set of one or more trusted identity providers;
automatically resolving the identified generalized name to obtain one or more network endpoints for one of the trusted identity providers;
upon authenticating the one or more network endpoints, contacting the one resolved identity provider to obtain one or more digital identity representations for use in obtaining one or more security tokens.
2. The method as recited in claim 1, wherein the generalized name comprises a network endpoint for the one trusted identity provider.
sending one or more requests to the resolved identity provider to obtain information about any available digital identity representation provisioning service; and
receiving one or more messages comprising information about a digital identity representation provisioning service used with the resolved identity provider.
6. The method as recited in claim 5, further comprising, wherein one or both of the information in the one or more policy files, and the information received in the one or more messages from the identity provider comprise one or more metadata elements.
identifying a network endpoint corresponding to the digital identity representation provisioning service; and
the client sending one or more messages to the digital identity representation provisioning service to obtain a digital identity representation.
9. The method as recited in claim 8, further comprising an act of receiving one or more digital identity representations from the provisioning service for use with the resolved identity provider.
the client sending one or more additional messages to the resolved identity provider comprising information corresponding to the received digital identity representations; and
receiving one or more messages from the resolved identity provider comprising the one or more security tokens.
the client sending one or more messages to the relying party that include the one or more tokens received from the identity provider; and
receiving one or more responses from the relying party that indicate that access to the one or more services has been granted.
12. At an identity provider in a federated computerized system having the identity provider, one or more clients, and one or more relying parties, a method of providing one or more digital identity representations and one or more security tokens to a client that resolves information provided by a relying party, comprising the acts of:
receiving at an identity provider one or more requests from a client for one or more digital identity representation provisioning services for establishing one or more DIRs that can be subsequently used to obtain one or more security tokens that will be used to verify a user to a relying party;
providing to the client information that identifies at least one digital identity provisioning service trusted by the identity provider;
authenticating one or more digital identity representations received from the client, wherein the identity provider determines that the received one or more digital identity representations are valid; and
providing one or more security tokens corresponding to the authenticated one or more digital identity representations.
13. The method as recited in claim 12, wherein the act of providing the client information further comprises:
publishing one or more documents comprising the information that identifies the one or more digital identity provisioning services; and
digitally signing the one or more documents.
14. The method as recited in claim 14, wherein the provided information in the published one or more documents comprise one or more metadata elements.
receiving at the identity provider one or more new requests from the client for the one or more security tokens for use with the relying party; and
identifying one or more valid digital identity representations in the one or more new requests.
19. The method as recited in claim 18, wherein the act of authenticating the one or more digital identity representations further comprises determining that the received one or more digital identity representations were obtained from one of the trusted digital identity provisioning services.
US12141515 2008-06-18 2008-06-18 Obtaining digital identities or tokens through independent endpoint resolution Active 2030-02-26 US8074258B2 (en)
US12141515 US8074258B2 (en) 2008-06-18 2008-06-18 Obtaining digital identities or tokens through independent endpoint resolution
CN 200980123431 CN102067145B (en) 2008-06-18 2009-06-02 Obtaining digital identities or tokens through independent endpoint resolution
EP20090767440 EP2310975A4 (en) 2008-06-18 2009-06-02 Obtaining digital identities or tokens through independent endpoint resolution
JP2011514676A JP5086474B2 (en) 2008-06-18 2009-06-02 Acquiring digital identity or token by independent resolve endpoint
PCT/US2009/045989 WO2009155129A3 (en) 2008-06-18 2009-06-02 Obtaining digital identities or tokens through independent endpoint resolution
US20090320095A1 true true US20090320095A1 (en) 2009-12-24
US8074258B2 US8074258B2 (en) 2011-12-06
ID=41432690
US12141515 Active 2030-02-26 US8074258B2 (en) 2008-06-18 2008-06-18 Obtaining digital identities or tokens through independent endpoint resolution
US (1) US8074258B2 (en)
JP (1) JP5086474B2 (en)
CN (1) CN102067145B (en)
EP (1) EP2310975A4 (en)
WO (1) WO2009155129A3 (en)
WO2012050717A1 (en) 2010-09-30 2012-04-19 Microsoft Corporation Trustworthy device claims as a service
US8370914B2 (en) 2010-12-15 2013-02-05 Microsoft Corporation Transition from WS-Federation passive profile to active profile
US20140068743A1 (en) * 2012-08-30 2014-03-06 International Business Machines Corporation Secure configuration catalog of trusted identity providers
US20080028000A1 (en) * 2006-07-31 2008-01-31 Microsoft Corporation Synchronization operations involving entity identifiers
US20080069102A1 (en) * 2006-09-20 2008-03-20 Nortel Networks Limited Method and system for policy-based address allocation for secure unique local networks
EP2622534A4 (en) * 2010-09-30 2017-06-21 Microsoft Technology Licensing Llc Trustworthy device claims as a service
CN102067145A (en) 2011-05-18 application
EP2310975A4 (en) 2014-10-08 application
CN102067145B (en) 2013-11-06 grant
WO2009155129A3 (en) 2010-03-11 application
JP2011525028A (en) 2011-09-08 application
EP2310975A2 (en) 2011-04-20 application
US8074258B2 (en) 2011-12-06 grant
WO2009155129A2 (en) 2009-12-23 application
JP5086474B2 (en) 2012-11-28 grant
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NANDA, ARUN K.;SHARIF, TARIQ;REEL/FRAME:021124/0558;SIGNING DATES FROM 20080617 TO 20080618
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NANDA, ARUN K.;SHARIF, TARIQ;SIGNING DATES FROM 20080617TO 20080618;REEL/FRAME:021124/0558