Source: https://patents.google.com/patent/US8973123B2/en
Timestamp: 2019-12-08 23:57:08
Document Index: 416063121

Matched Legal Cases: ['arty 745', 'arty 213', 'arty 213', 'arty 213', 'arty 313', 'arty 213', 'arty 213', 'arty 213', 'arty 213', 'arty 213', 'arty 213']

US8973123B2 - Multifactor authentication - Google Patents
US8973123B2
US8973123B2 US13/655,436 US201213655436A US8973123B2 US 8973123 B2 US8973123 B2 US 8973123B2 US 201213655436 A US201213655436 A US 201213655436A US 8973123 B2 US8973123 B2 US 8973123B2
US13/655,436
US20130276087A1 (en
2012-04-17 Priority to US201261625641P priority Critical
2012-10-18 Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
2012-10-18 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NADALIN, ANTHONY JOSEPH, BJONES, RONALD JOHN KAMIEL EUPHRASIA, CAMERON, KIM
2012-10-18 Priority to US13/655,436 priority patent/US8973123B2/en
2013-10-17 Publication of US20130276087A1 publication Critical patent/US20130276087A1/en
2015-03-03 Publication of US8973123B2 publication Critical patent/US8973123B2/en
Aspects of the subject matter described herein relate to identity technology. In aspects, a user device requests access to a service provided by a relying party. In response, the relying party indicates required claims and may also indicate claims providers from which the required claims may be obtained. The user device may obtain the required claims from different claims providers, and send the claims obtained from the different claims providers in one or more messages to the relying party. The relying party may verify the claims or employ a validating service to verify that the claims are valid prior to providing access to the requested service.
Briefly, aspects of the subject matter described herein relate to identity technology. In aspects, a user device requests access to a service provided by a relying party. In response, the relying party indicates required claims and may also indicate claims providers from which the required claims may be obtained. The user device may obtain the required claims from different claims providers, and send the claims obtained from the different claims providers in one or more messages to the relying party. The relying party may verify the claims or employ a validating service to verify that the claims are valid prior to providing access to the requested service.
FIG. 9 is a flow diagram that generally represents exemplary actions that may occur in obtaining and presenting claims in accordance with aspects of the subject matter described herein; and
FIG. 10 is a flow diagram that generally represents exemplary actions that may occur in obtaining and validating claims in accordance with aspects of the subject matter described herein.
At 3 b, in response, the policy gateway 715 may send a cookie to the user device 730. For example, one form of a cookie may be write cookie (context, stripped policy, identity provider, user agent). A stripped policy is a policy that has been stripped of information identifying the relying party 745.
Turning to FIG. 8, at 3 g, the protocol gateway 715 may read the cookie previously written to the user device 730. The read may take the form of read cookie (context, stripped policy, identity provider, user agent).
At 4 b, tokens may be generated by interacting with the token issuer 720. One form of interaction may include a command such as Generate Tokens (context, Signed Claims, stripped URL).
FIG. 9 is a flow diagram that generally represents exemplary actions that may occur in obtaining and presenting claims in accordance with aspects of the subject matter described herein. At block 905, the actions begin.
At block 910, a message is received that indicates claims required from a relying party to gain access to a service provided by a relying party. For example, referring to FIG. 5, the user device may receive a message from a relying party through the communications mechanism 525. The message may also include data that indicates claims providers that are allowed to provide the claims.
At block 915, a plurality of claims providers are contacted to obtain the required claims. For example, referring to FIG. 6, two or more of the claims providers 610-612 may be contacted to obtain claims to access a service of the relying party 213.
At block 920, the claims are obtained. At least two the claims are obtained from different claims providers. For example, referring to FIG. 6, the user device 212 may obtain one claim from the claims provider 610, three claims from the claims provider 611, and zero claims from the claims provider 612. In other examples, there may be other combinations of claims from claims providers without departing from the spirit or scope of aspects of the subject matter described herein.
At block 925, the natural identity information is obscured. The natural identity information may be obscured, for example, by removing it from claims data provided to the relying party, by encrypting the claims data by actions executing on the user device, or otherwise as has been mentioned previously. The actions may be performed by a user agent executing on the user device. The user agent may erect a privacy boundary to prevent natural identity information from being transmitted to the relying party.
Natural identity information is information that may be used to identify a user in other contexts. For example, a social security number and a birth date may be sufficient to identify an individual in another unrelated transaction while a temporary number assigned to the individual may not be sufficient.
At block 930, the claims data is provided a device associated with the relying party. For example, referring to FIG. 6, the user device 212 may provide the claims to a device of the relying party 213. The device may be a part of one or more computers and may be located in the cloud, at the site of the relying party, or in another location without departing from the spirit or scope of aspects of the subject matter described herein.
At block 935, other actions, if any, may be performed.
FIG. 10 is a flow diagram that generally represents exemplary actions that may occur in obtaining and validating claims in accordance with aspects of the subject matter described herein. At block 1005, the actions begin.
At block 1010, a request is received to access a service of a relying party. For example, referring to FIG. 6, the relying party 213 may receive a request from the user device 212 to access a service provided by the relying party 313.
At block 1015, in response to the request, a message may be sent that indicates claims required by the relying party to gain access to the service. For example, referring to FIG. 6, the relying party 213 may send a message to the user device 212 that indicates claims required by the relying party 213 to gain access to a service provided by the relying party 213. The message may also indicate, for each of the claims, at least one claims provider that is allowed to provide the claim.
At block 1020, claims data is received that includes the claims. At least two of the claims included in the claims data are obtained from different claims providers. The claims data omits information sufficient to determine a natural identity of the user. The claims data may be received in a single message or in two or more messages. The claims data may include a plurality of tokens that are partially signed by one or more token issuers where each token includes all claims received from a single corresponding claims provider.
In addition, natural identity information may be obscured by actions (e.g., encryption, removal, or the like) executed on the user device.
For example, referring to FIG. 6, the user device provides claims data to the relying party 213. In this example, the claims data includes claims from the claims providers 610 and 611; in other examples, the claims data may come from other claims providers.
At block 1025, the claims data may be provided to a validating service. For example, referring to FIG. 6, the relying party 213 may provide the claims data to the validating service 615.
At block 1030, validation data may be received from the validating service. For example, referring to FIG. 6, the relying party 213 may receive validation data from the validating service 615. The validating data may indicate whether the claims have been obtained from the appropriate claims providers and have not been tampered with. The validating data may, in one example, indicate that all the claims are valid, which of the claims are valid, or provide other information about the validity of the claims.
at a communications interface of a user device, receiving a message from a relying party, the message indicating claims required to gain access to a service provided by the relying party;
contacting, via the user device, claims providers to obtain the claims;
obtaining at least two of the claims from different claims providers;
through a privacy boundary established by a user agent executing on the user device, providing claims data that includes the claims to a relying party device associated with the relying party to obtain access to the service provided by the relying party, the claims data omitting information sufficient to determine a natural identity of a user of the user device.
2. The method of claim 1, wherein the receiving the message from the relying party comprises receiving data that indicates claims providers allowed to provide the claims.
3. The method of claim 1, wherein the receiving the message from the relying party comprises receiving data that, for each of the claims, indicates at least one claims provider that is allowed to provide a particular one of the claims.
4. The method of claim 1, wherein the obtaining at least two of the claims from different claims providers comprises providing different authentication data to the different claims providers.
5. The method of claim 1, wherein the providing claims data that includes the claims to the relying party device comprises providing the claims data in a plurality of tokens, each token including all claims received from a single corresponding claims provider of the claims providers.
6. The method of claim 1, further comprising combining claims data from the at least two of the claims into a single token prior to providing the claims data to the relying party device.
7. The method of claim 1, further comprising obscuring natural identity information in the claims data by encrypting the natural identity information by actions executed on the user device.
8. The method of claim 1, further comprising obscuring natural identity information in the claims data by removing the natural identity information from the claims data.
9. A computer-readable storage memory having computer-executable instructions, which when executed perform actions, comprising:
from a user device associated with a user, receiving a request to access a service of a relying party;
in response to the request, sending a message that indicates claims required by the relying party to gain access to the service; and
receiving claims data that includes the claims, at least two of the claims obtained from different claims providers, the claims data omitting information sufficient to determine a natural identity of the user.
10. The computer-readable storage memory of claim 9, wherein receiving claims data that includes the claims comprises receiving the claims data in a single message.
11. The computer-readable storage memory of claim 9, wherein receiving claims data that includes the claims comprises receiving the claims data in a plurality of messages.
12. The computer-readable storage memory of claim 9, wherein receiving claims data that includes the claims comprises receiving the claims data in a plurality of tokens that are partially signed by one or more token issuers, each token of the plurality of tokens including all claims received from a single corresponding claims provider of the claims providers.
13. The computer-readable storage memory of claim 9, wherein sending the message that indicates the claims required by the relying party to gain access to the service comprises sending the message that also indicates, for each of the claims, at least one claims provider that is allowed to provide a claim of the claims.
14. The computer-readable storage memory of claim 9, wherein receiving the claims data that includes the claims comprises receiving the claims data in which natural identity information has been obscured by actions executed on the user device.
15. The computer-readable storage memory of claim 9, wherein receiving the claims data that includes the claims comprises receiving the claims data in which natural identity information has been obscured by removing the natural identity information from the claims data prior to the receiving the claims data.
16. The computer-readable storage memory of claim 9, further comprising providing the claims data to a validating service to validate that the claims have been obtained from the claims providers.
17. The computer-readable storage memory of claim 16, further comprising, from the validating service, receiving validation data that indicates whether the claims have been obtained from the claims providers.
18. The computer-readable storage memory of claim 16, further comprising, from the validating service, receiving validation data that indicates which of the claims are valid.
a computer coupled to a memory, the memory comprising:
a validating service hosted on one or more computers, the validating service configured to perform actions, including:
receiving claims data that includes claims required to access a service of a relying party, at least two of the claims obtained from different claims providers, the claims data omitting information sufficient to determine a natural identity of a user requesting access to the service, the claims obtained from a user agent executing on a device associated with the user, the user agent erecting a privacy boundary to prevent the information sufficient to determine the natural identity of the user from passing to the validating service;
validating whether the claims have been obtained from valid claims providers; and
providing an indication to the relying party regarding validity of the claims.
20. The system of claim 19, further comprising the relying party service hosted on the one or more computers, the relying party service configured to perform actions, including:
from the user device, receiving a request to access the service;
in response to the request, sending a message that indicates the claims required to access the service, the message also indicating, for each of the claims, at least one claims provider that is allowed to provide the claim of the claims;
receiving the claims data from the user device;
sending the claims data to the validating service; and
from the validating service, receiving the indication regarding validity of the claims.
US13/655,436 2012-04-17 2012-10-18 Multifactor authentication Active US8973123B2 (en)
US201261625641P true 2012-04-17 2012-04-17
US13/655,436 US8973123B2 (en) 2012-04-17 2012-10-18 Multifactor authentication
US20130276087A1 US20130276087A1 (en) 2013-10-17
US8973123B2 true US8973123B2 (en) 2015-03-03
US13/652,478 Abandoned US20130275282A1 (en) 2012-04-17 2012-10-16 Anonymous billing
US13/655,436 Active US8973123B2 (en) 2012-04-17 2012-10-18 Multifactor authentication
US13/682,743 Active 2032-12-20 US8752158B2 (en) 2012-04-17 2012-11-21 Identity management with high privacy features
US13/688,210 Active US9571491B2 (en) 2012-04-17 2012-11-29 Discovery of familiar claims providers
US13/705,179 Active 2033-02-05 US8806652B2 (en) 2012-04-17 2012-12-05 Privacy from cloud operators
CA2774990A1 (en) * 2009-09-25 2011-03-31 Google Inc. Controlling content distribution
2012-10-16 US US13/652,478 patent/US20130275282A1/en not_active Abandoned
2012-10-18 US US13/655,436 patent/US8973123B2/en active Active
2012-11-21 US US13/682,743 patent/US8752158B2/en active Active
2012-11-29 US US13/688,210 patent/US9571491B2/en active Active
2012-12-05 US US13/705,179 patent/US8806652B2/en active Active
"Criterion White Paper: Federated Online Attribute Exchange Initiatives" Published Jun. 14, 2012 (7 pages) http://openidentityexchange.org/sites/defaultlfiles/Federated Online Attribute Exchange White Paper 6.pdf.
"Making sense of the National Strategy for Trusted Identities in Cyberspace (Part IV: Strawman Architecture)", Retrieved at http://www.educatedguesswork.org/2011/05/making-sense-of-the-national-s-3.html>>, May 25, 2011, pp. 2.
"Making sense of the National Strategy for Trusted Identities in Cyberspace (Part IV: Strawman Architecture)", Retrieved at http://www.educatedguesswork.org/2011/05/making—sense—of—the—national—s—3.html>>, May 25, 2011, pp. 2.
"OIX Open Identity Exchange: An Open Market Solution for Online Identity Assurance" Published Mar. 2010 (13 pages) http://openidentityexchange.org/sites/defaultlfiles/oix-white-paper-201 0-03-02.pdf.
"OIX Open Identity Exchange: Trust Framework Requirements and Guidelines V1 (Draft 01)" Published Jan. 17, 2011 (7 pages) http://openidentityexchange.org/sites/defaultifiles/OIX%20Trust%20Framework%20Requirements.pdf.
"OIX: The OIX Listing Service" © 2010 OIX [Article dated Mar. 12, 2011 as seen by Internet Archive] (2 pages) http://web.archive.org/web/2011 03121 05303/http://openidentityexchange.org/listing-service.
Martinet, et al., "Cryptanalysis of a partially blind signature scheme or how to make $100 bills with $1 and $2", Retrieved at <<http://www.ssi.gouv.fr/archive/fr/sciences/fichiers/lcr/maposo06.pdf>>,FC'06 Proceedings of the 10th international conference on Financial Cryptography and Data Security, Feb. 27, 2006, pp. 171-176.
Molina-Markham, et al., "Designing Privacy-preserving Smart Meters with Low-cost Microcontrollers", Retrieved at <<http://fc12.ifca.ai/pre-proceedings/paper—29.pdf>>,IACR Cryptology ePrint Archive, Retrieved Date: May 16, 2012, pp. 15.
Molina-Markham, et al., "Designing Privacy-preserving Smart Meters with Low-cost Microcontrollers", Retrieved at >,IACR Cryptology ePrint Archive, Retrieved Date: May 16, 2012, pp. 15.
Rial, et al., "Privacy-Preserving Smart Metering", Retrieved at <<http://research.microsoft.com/en-us/um/people/gdane/pfsm.pdf.pdf>>, WPES '11 Proceedings of the 10th annual ACM workshop on Privacy in the electronic society, Oct. 17, 2011, pp. 49-60.
Rial, et al., "Privacy-Preserving Smart Metering", Retrieved at >, WPES '11 Proceedings of the 10th annual ACM workshop on Privacy in the electronic society, Oct. 17, 2011, pp. 49-60.
Tiwari, et al., "A Multi-Factor Security Protocol for Wireless Payment—Secure Web Authentication Using Mobile Devices", Retrieved at <<http://www.tifr.res.in/˜sanyal/papers/Ayu—MultiFactorSecurityProtocol.pdf>>, IADIS International Conference Applied Computing 2007, Feb. 2007, pp. 160-167.
U.S. Appl. No. 13/628,044, Amendment dated Jun. 17, 2014, 12 pages.
U.S. Appl. No. 13/628,044, filed Sep. 27, 2012, 55 pages.
U.S. Appl. No. 13/628,044, Final Office Action dated Oct. 23, 2014, 13 pages.
U.S. Appl. No. 13/628,044, Office Action mailed Dec. 20, 2013, 12 pages.
US20130276087A1 (en) 2013-10-17
US8752158B2 (en) 2014-06-10
US8806652B2 (en) 2014-08-12
US20130275469A1 (en) 2013-10-17
US9571491B2 (en) 2017-02-14
US20130275282A1 (en) 2013-10-17
US20130276131A1 (en) 2013-10-17
US20130276088A1 (en) 2013-10-17
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BJONES, RONALD JOHN KAMIEL EUPHRASIA;CAMERON, KIM;NADALIN, ANTHONY JOSEPH;SIGNING DATES FROM 20121012 TO 20121014;REEL/FRAME:029155/0310