Source: http://www.patentsencyclopedia.com/app/20130014245
Timestamp: 2018-12-10 17:48:54
Document Index: 158099494

Matched Legal Cases: ['arty 130', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 130', 'arty 210', 'arty 130', 'arty 210', 'arty 130', 'arty 210', 'arty 130', 'arty 210', 'arty 130', 'arty 210', 'arty 210', 'arty 210', 'arty 210']

REMOTABLE INFORMATION CARDS - Patent application
Patent application title: REMOTABLE INFORMATION CARDS
Inventors: Lloyd Leon Burch (Payson, UT, US) Daniel S. Sanders (Orem, UT, US) Andrew A. Hodgkinson (Pleasant Grove, UT, US) Stephen R. Carter (Spanish Fork, UT, US)
Patent application number: 20130014245
An accessor function interfaces among a client, a relying party, and an identity provider. The identity provider can "manage" personal (i.e., self-asserted) information cards on behalf of a user, making the personal information cards available on clients on which the personal information cards are not installed. The client can be an untrusted client, vulnerable to attacks such as key logging, screen capture, and memory interrogation. The accessor function can also asked as a proxy for the relying party in terms of invoking and using the information cards system, for use with legacy relying parties.
1. A method, comprising: identifying a request of a resource of a legacy relying party received from a client, the legacy relying party not designed to use a security token; requesting the security token from the client; and using the security token on behalf of the user to access the resource.
2. A method according to claim 1, wherein using the security token on behalf of the user includes filling out a form on a website of the legacy relying party.
3. A method according to claim 1, wherein using the security token on behalf of the user includes authenticating the user to the legacy relying party.
4. A method according to claim 1, wherein using the security token on behalf of the user includes populating an LDAP store used by the legacy relying party.
5. A method according to claim 1, wherein: identifying a request of a resource of a legacy relying party received from a client includes identifying a request of a resource of a legacy relying party received from an untrusted client; and requesting the security token from the untrusted client.
[0001] This application is a divisional of co-pending U.S. patent application Ser. No. 13/408,384, titled "REMOTABLE INFORMATION CARDS", filed Feb. 29, 2012, which is a continuation of U.S. patent application Ser. No. 12/111,874, titled "REMOTABLE INFORMATION CARDS", filed Apr. 29, 2008, now U.S. Pat. No. 8,151,324, issued Apr. 3, 2012, which is a continuation-in-part of co-pending U.S. patent application Ser. No. 11/843,572, titled "PERFORMING A BUSINESS TRANSACTION WITHOUT DISCLOSING SENSITIVE IDENTITY INFORMATION TO A RELYING PARTY", filed Aug. 22, 2007, now U.S. Pat. No. 8,073,783, issued Dec. 6, 2011, of co-pending U.S. patent application Ser. No. 11/843,638, titled "POLICY-BASED AUDITING OF IDENTITY CREDENTIAL DISCLOSURE BY A SECURE TOKEN SERVICE", filed Aug. 22, 2007, and of co-pending U.S. patent application Ser. No. 11/843,640, titled "FRAMEWORK AND TECHNOLOGY TO ENABLE THE PORTABILITY OF INFORMATION CARDS", filed Aug. 22, 2007, now U.S. Pat. No. 8,074,257, issued Dec. 6, 2011, all of which are herein incorporated by reference for all purposes. Co-pending U.S. patent application Ser. No. 11/843,572, titled "PERFORMING A BUSINESS TRANSACTION WITHOUT DISCLOSING SENSITIVE IDENTITY INFORMATION TO A RELYING PARTY", filed Aug. 22, 2007, now U.S. Pat. No. 8,073,783, issued Dec. 6, 2011, co-pending U.S. patent application Ser. No. 11/843,638, titled "POLICY-BASED AUDITING OF IDENTITY CREDENTIAL DISCLOSURE BY A SECURE TOKEN SERVICE", filed Aug. 22, 2007, and co-pending U.S. patent application Ser. No. 11/843,640, titled "FRAMEWORK AND TECHNOLOGY TO ENABLE THE PORTABILITY OF INFORMATION CARDS", filed Aug. 22, 2007, now U.S. Pat. No. 8,074,257, issued Dec. 6, 2011, all claim the benefit of U.S. Provisional Patent Application Ser. No. 60/895,312, filed Mar. 16, 2007, U.S. Provisional Patent Application Ser. No. 60/895,316, filed Mar. 16, 2007, and U.S. Provisional Patent Application Ser. No. 60/895,325, filed Mar. 16, 2007, all of which are herein incorporated by reference for all purposes.
[0002] U.S. patent application Ser. No. 12/111,874, titled "REMOTABLE INFORMATION CARDS", filed Apr. 29, 2008, now U.S. Pat. No. 8,151,324, issued Apr. 3, 2012, is also a continuation-in-part of co-pending U.S. patent application Ser. No. 12/019,104, titled "PROCESSING HTML EXTENSIONS TO ENABLE SUPPORT OF INFORMATION CARDS BY A RELYING PARTY", filed Jan. 24, 2008, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/973,679, filed Sep. 19, 2007, both of which are herein incorporated by reference for all purposes.
[0003] U.S. patent application Ser. No. 12/111,874, titled "REMOTABLE INFORMATION CARDS", filed Apr. 29, 2008, now U.S. Pat. No. 8,151,324, issued Apr. 3, 2012, is also a continuation-in-part of co-pending U.S. patent application Ser. No. 12/029,373, filed Feb. 11, 2008, which is herein incorporated by reference for all purposes.
[0005] When a user interacts with sites on the Internet (hereafter referred to as "service providers" or "relying parties"), the service provider often expects to know something about the user that is requesting the services of the provider. The typical approach for a service provider is to require the user to log into or authenticate to the service provider's computer system. But this approach, while satisfactory for the service provider, is less than ideal to the user. First, the user must remember a username and password for each service provider who expects such information. Given that different computer systems impose different requirements, and the possibility that another user might have chosen the same username, the user might be unable to use the same username/password combination on each such computer system. (There is also the related problem that if the user uses the same username/password combination on multiple computer systems, someone who hacks one such computer system would be able to access other such computer systems.) Second, the user has no control over how the service provider uses the information it stores. If the service provider uses the stored information in a way the user does not want, the user has relatively little ability to prevent such abuse, or recourse after the fact.
[0006] To address this problem, new systems have been developed that allow the user a measure of control over the information stored about the user. Windows CardSpace® (sometimes called CardSpace) is a Microsoft implementation of an identity meta-system that offers a solution to this problem. (Microsoft, Windows, and CardSpace are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.) A user can store identity information with an identity provider the user trusts. When a service provider wants some information about the user, the user can control the release of information stored with the identity provider to the service provider. The user can then use the offered services that required the identity information.
[0007] While this system simplifies the management of information used to satisfy the requests of service providers, there are potential problems. This system assumes that a client machine is trustworthy. But if the client machine is not trustworthy--if the client might be subject to attacks of different natures--it would be dangerous for a user to use the client with the system. The various attacks to which the client might be subjected might lead to the user involuntarily revealing secret information, which could then be used against the user at a later time.
[0009] In an embodiment of the invention, an untrusted client can engage in a transaction with a relying party. An accessor function acts as an intermediary between the untrusted client and the relying party. The accessor function can invoke the card selector on the untrusted client and act as a pathway through which all sensitive information flows to the relying party. Personal information cards, which normally would be stored directly on the client, can be "managed" on behalf of the user by an identity provider.
[0030] The problem with this model is, as noted above, that there is an implicit assumption that client 105 is trustworthy. More specifically, there is an implicit assumption that client 105 is not subject to attacks that might result in sensitive information of the user being captured by a third party. When this assumption is removed--that is, when client 105 is potentially subject to attacks that could leak sensitive information--the problem with this model becomes apparent.
[0031] Now that the problem--removing the assumption that client 105 is trustworthy--is understood, embodiments of the invention can be explained. In FIG. 2, both trusted client 105 and untrusted client 205 are shown communicating with relying parties. Trusted client 105 can be any trusted client, as known in the art. Untrusted client 205 represents a client whose security cannot be trusted: for example, untrusted client 205 might be vulnerable to key logging software, screen capture software, memory interrogation, or any other variety of attack that might expose the user's sensitive information to another. Untrusted client 205 might be, for example, a kiosk in a public place, or even a publicly-accessible computer, such as might be found in the library. Any machine whose security is uncertain or cannot otherwise be guaranteed can be considered to be an untrusted client.
[0032] A relying party can be relying party 130, a relying party that is capable of processing a security token issued in accordance with the information card system. The relying party can also be a legacy relying party, such as legacy relying party 210. Legacy relying party 210 represents a party with whom trusted client 105 or untrusted client 205 might wish to conduct a transaction, but does not process security tokens issued in accordance with the information card system. For example, legacy relying party 210 might represent a website that expects a user to provide a username and password to access a resource on the website, but does not request a security token from an information card system. Or, legacy relying party 210 might be a website that includes a form that can be filled out from data stored in information card. Or, legacy relying party 210 might be a machine that uses LDAP in order to authenticate credentials and retrieve attribute information; accessor function 215 can populate an LDAP store that can be used by this machine. A person skilled in the art will recognize other types of legacy relying parties, not normally designed to use information card systems, with which embodiments of the invention can be used.
[0035] Facilitating communications between trusted client 105, untrusted client 205, relying party 130, legacy relying party 210, and identity provider 135 is accessor function 215. Most communications between trusted client 105 and/or untrusted client 205 on the one hand and identity provider 135, relying party 130, and/or legacy relying party 210 on the other hand pass through accessor function 215, with some exceptions to be discussed below. For example, trusted client 105 and untrusted client 205 communicate with accessor function 215 via lines of communication 220 and 225, respectively. Similarly, identity provider 135, relying party 130, and legacy relying party 210 communicate with accessor function via lines of communication 230, 235, and 240, respectively. (Not shown in FIG. 2 is a network connecting trusted client 105, untrusted client 205, accessor function 215, identity provider 135, relying party 130, and legacy relying party 210. A person skilled in the art will recognize that some network(s) connect these components, and that different networks and different network types can be used to connect these various components. For example, some components of FIG. 2 might be connected via wireline networks, where as other components might be connected via wireless networks.)
[0036] A person skilled in the art might recognize that trusted client 105 can communicate directly with relying party 130 and identity provider 135 without the intervention of accessor function 215. Nevertheless, there is an advantage to including accessor function 215 in the system shown in FIG. 2. Specifically, by including accessor function 215 in the system shown in FIG. 2, legacy relying party 210 can use the information card system with trusted client 105, a functionality that would not be available without accessor function 215.
[0038] As discussed above, legacy relying party 210 represents a relying party that is not capable of using the information card system. Accessor function 215 can detect that legacy relying party 210 is a legacy relying party, and act as a proxy for legacy relying party 210 in using the information card system. Co-pending U.S. patent application Ser. No. 12/019,104, titled "PROCESSING HTML EXTENSIONS TO ENABLE SUPPORT OF INFORMATION CARDS BY A RELYING PARTY", filed Jan. 24, 2008, and incorporated by reference herein describes how a trusted client can use the information card system on behalf of a legacy relying party. A person skilled in the art will recognize how accessor function can be adapted to provide a similar functionality on behalf of a legacy relying party, separating this functionality from the trusted client.
[0041] FIG. 4 shows the trusted client of FIG. 2 transmitting a personal information card to the identity provider of FIG. 2 for management on behalf of the user. In FIG. 4, trusted client 105 is shown transmitting personal information card 320 to identity provider 135. As trusted client 105 is, of course, trusted, trusted client 105 could use personal information card 320 without needing identity provider 135 to "manage" personal information card 320 (shown coupled to identity provider 135 as personal information card 405) on its behalf. However, by having identity provider 135 "manage" personal information card 405 (along with managed information card 410), the system enables the use of personal information card 405 at any client. In fact, having identity provider 135 "manage" personal information card 405 on behalf of trusted client 105 not only enables the use of personal information card 405 at untrusted clients, but it also enables the user to utilize personal information card 405 at other trusted clients on which personal information card 320 has not been installed. Thus, the system enables not only the use of untrusted clients with the information card system, but it also enables the user to have a "virtual wallet" that can be used at any client, trusted or not.
[0042] When the user desires to utilize the information card system from a client (trusted or not), the client can request from identity provider 135 images of any information cards resident on identity provider 135 that belong to the user. The images of the information cards of themselves are not sensitive information, and can be transmitted across any networks, even to an untrusted client. The images of the information cards can be graphical images, such as bitmaps, GIFs, JPGs, or any other desired graphical form, which can be displayed by the client. The images of the information cards can also be structured in a "textual form" that can be displayed by the client. For example, the images can be structured as HTML, XML, or other text-based formats; the client can then process the text-based format and display information about the information card to the user. In either case, the image normally does not include any secret information (which, if made available to an untrusted client, could be captured and used against the user). The user, of course, knows what information is represented by the image of each information card, and therefore can select an appropriate information card to use in the current transaction.
[0043] At this point, it is worth noting that the advantage of the virtualization of the user's "wallet" can come at a price. For example, as discussed above, the information card system can use data known about the information cards installed on the system, in conjunction with the security policy from the relying party, to identify installed information cards that can satisfy the security policy. In some embodiments of this invention, the identity provider can transmit to the client only images of information cards that can satisfy the security policy. In such embodiments of the invention, the user can select any information card whose image is shown, in the knowledge that the information card can satisfy the security policy of the relying party. In other embodiments of the invention, however, the identity provider can transmit images of all information cards available at the identity provider, without identifying which information cards can satisfy the security policy of the relying party. In these alternative embodiments of the invention, the burden is on the user to remember which information card might satisfy the security policy of the relying party.
[0046] Dumb USB device 505 represents a dumb storage device: that is, a storage device that simply stores data, without any inherent security or processing capability. As it lacks any security or processing capabilities, dumb USB device 505 is not considered any more "secure" than untrusted client 205 is. Thus, dumb USB device 505 normally would not store any sensitive information. Dumb USB device 505 is shown as storing personal information card 515 and managed information card 520. These are not true information cards stored on dumb USB device 505; rather, they are merely images representing information cards that can be accessed from some other source, such as an identity provider. When the card selector on untrusted client 205 is invoked, it can detect the presence of dumb USB device 505, and retrieve from the storage therein the images of personal information card 515 and managed information card 520. The user can therefore bring with him on dumb USB device 505 images of information cards the user wants to carry with him, even though the cards themselves remain stored securely at the identity provider.
[0047] In contrast, when untrusted client 205 is coupled to smart USB device 510, things can operate a little differently. Because smart USB device 510 is "smart", smart USB device 510 can securely store information cards, such as personal information card 525 and managed information card 530. In addition, smart USB device 510 can include local secure token service 535. Local secure token service 535 is a trusted secure token service, capable of generating (from within smart USB device 510) a security token responsive to a selected information card. (This of course assumes that the data needed to generate the security token is available within smart USB device 510. For example, local secure token service 535 cannot generate a security token based on managed information card 530, as the data that comprises managed information card 530 is not stored on smart USB device 510, but rather on identity provider 135.) Because smart USB device 510 is secure, and because local secure token service 535 is trusted, local secure token service 535 can generate a security token without any sensitive information being compromised, even though smart USB device 510 is coupled to untrusted client 205, which itself might be compromised.
[0048] A comparison with co-pending U.S. patent application Ser. No. 11/843,572, titled "PERFORMING A BUSINESS TRANSACTION WITHOUT DISCLOSING SENSITIVE IDENTITY INFORMATION TO A RELYING PARTY", filed Aug. 22, 2007, now U.S. Pat. No. 8,073,783, issued Dec. 6, 2011, to co-pending U.S. patent application Ser. No. 11/843,638, titled "POLICY-BASED AUDITING OF IDENTITY CREDENTIAL DISCLOSURE BY A SECURE TOKEN SERVICE", filed Aug. 22, 2007, to co-pending U.S. patent application Ser. No. 11/843,640, titled "FRAMEWORK AND TECHNOLOGY TO ENABLE THE PORTABILITY OF INFORMATION CARDS", filed Aug. 22, 2007, now U.S. Pat. No. 8,074,257, issued Dec. 6, 2011, all of which are herein incorporated by reference, might now be useful. These related applications describe, among other concepts, portable information cards. For example, if the client is coupled to a USB device storing the portable information cards, the client can access the information cards from this USB device. The same is true of any other pluggable card store. But if the client is not trusted, the use of portable information cards as described in these related applications does not avoid the potential revelation of sensitive information on the untrusted client: once the untrusted client has access to the information cards (particularly personal information cards) from the pluggable card store, the sensitive information stored in those cards is vulnerable. In contrast, with remotable information cards, the sensitive information in card stores can be protected.
[0054] A person skilled in the art will recognize that normal operation of the information card system has all information flowing through the client: no information normally bypasses the client. Thus, in normal operation, the security token as generated by the identity provider passes through the client before it is delivered to the relying party (in embodiments of the invention, via the accessor function). However, a person skilled in the art will also recognize that, if the security token is considered "sensitive information" (in that the security token represents, usually in encrypted form, data from an information card), the security token can be transmitted from the identity provider directly to the accessor function, bypassing the client. In this embodiment of the invention, it is helpful for the identity provider to also transmit a message to the client, alerting the client that the security token was transmitted directly to the accessor function. In this way, the client is kept aware of the fact that the security token was transmitted to the accessor function, even though the security token did not pass through the client on the way to the accessor function.
[0060] The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention can be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine can be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term "machine" is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
[0063] Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles, and can be combined in any desired manner. And although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as "according to an embodiment of the invention" or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms can reference the same or different embodiments that are combinable into other embodiments.
Patent applications by Daniel S. Sanders, Orem, UT US
2009-12-31 Remotable information cards
2012-06-21 Remotable information cards
2009-10-29 Restricted use information cards