Source: http://www.google.com/patents/US20090178112?dq=6246862
Timestamp: 2016-07-01 19:24:38
Document Index: 29369562

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

Patent US20090178112 - Level of service descriptors - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAn apparatus can include a client having a card selector, a query generator, and a transmitter. The card selector can allow a user to select an information card based on a security policy. The card selector can also provide a security token in response to the selected information card. The query generator...http://www.google.com/patents/US20090178112?utm_source=gb-gplus-sharePatent US20090178112 - Level of service descriptorsAdvanced Patent SearchPublication numberUS20090178112 A1Publication typeApplicationApplication numberUS 12/402,782Publication dateJul 9, 2009Filing dateMar 12, 2009Priority dateMar 16, 2007Publication number12402782, 402782, US 2009/0178112 A1, US 2009/178112 A1, US 20090178112 A1, US 20090178112A1, US 2009178112 A1, US 2009178112A1, US-A1-20090178112, US-A1-2009178112, US2009/0178112A1, US2009/178112A1, US20090178112 A1, US20090178112A1, US2009178112 A1, US2009178112A1InventorsThomas E. Doman, Wendy Michelle Busath, Duane F. BussOriginal AssigneeNovell, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (98), Referenced by (40), Classifications (12), Legal Events (6) External Links: USPTO, USPTO Assignment, EspacenetLevel of service descriptors
[0001] This application is a continuation-in-part of co-pending U.S. patent application Ser. No. 12/323,141, titled “INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT”, filed Nov. 25, 2008, and co-pending U.S. patent application Ser. No. 12/323,177, titled “INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT”, filed Nov. 25, 2008, both of which are hereby incorporated by reference for all purposes. Co-pending U.S. patent application Ser. No. 12/323,141, titled “INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT”, filed Nov. 25, 2008, and co-pending U.S. patent application Ser. No. 12/323,177, titled “INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT”, filed Nov. 25, 2008, are each a continuation-in-part of co-pending U.S. patent application Ser. No. 11/830,492, titled “SYSTEM AND METHOD FOR ORDERED CREDENTIAL SELECTION”, filed Jul. 30, 2007, of co-pending U.S. patent application Ser. No. 12/054,774, titled “CLAIM CATEGORY HANDLING”, filed Mar. 25, 2008, of co-pending U.S. patent application Ser. No. 11/843,591, titled “CREDENTIAL CATEGORIZATION”, filed Aug. 22, 2007, and of co-pending U.S. patent application Ser. No. 12/044,816, titled “SYSTEM AND METHOD FOR USING WORKFLOWS WITH INFORMATION CARDS”, filed Mar. 7, 2008, all of which are hereby incorporated by reference for all purposes. Co-pending U.S. patent application Ser. No. 11/843,591, titled “CREDENTIAL CATEGORIZATION”, filed Aug. 22, 2007, is a continuation in part of co-pending U.S. patent application Ser. No. 11/843,572, “PERFORMING A BUSINESS TRANSACTION WITHOUT DISCLOSING SENSITIVE IDENTITY INFORMATION TO A RELYING PARTY” filed Aug. 22, 2007, 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, all of which are hereby 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, 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, 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. This application is also related to co-pending U.S. patent application Ser. No. 11/768,755, titled “TIME-BASED METHOD FOR AUTHORIZING ACCESS TO RESOURCES”, filed Jun. 26, 2007, to co-pending U.S. patent application Ser. No. 11/843,608, titled “CHAINING INFORMATION CARD SELECTORS”, filed Aug. 22, 2007, to 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, to co-pending U.S. patent application Ser. No. 12/026,775, titled “METHODS FOR SETTING AND CHANGING THE USER CREDENTIAL IN INFORMATION CARDS”, filed Feb. 6, 2008, to co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, to co-pending U.S. patent application Ser. No. 12/030,063, titled “INFO CARD SELECTOR RECEPTION OF IDENTITY PROVIDER BASED DATA PERTAINING TO INFO CARDS”, filed Feb. 12, 2008, to co-pending U.S. patent application Ser. No. 12/038,674, titled “SYSTEM AND METHOD FOR SECURE ACCOUNT RESET UTILIZING INFORMATION CARDS”, filed Feb. 27, 2008, to co-pending U.S. patent application Ser. No. 12/042,205, titled “PRIVATELY SHARING RELYING PARTY REPUTATION WITH INFORMATION CARD SELECTORS”, filed Mar. 4, 2008, to co-pending U.S. patent application Ser. No. 12/054,137, titled “CARDSPACE HISTORY VALIDATOR”, filed Mar. 24, 2008, to co-pending U.S. patent application Ser. No. 12/108,805, titled “RESTRICTED USE INFORMATION CARDS”, filed Apr. 24, 2008, to co-pending U.S. patent application Ser. No. 12/111,874, titled “REMOTABLE INFORMATION CARDS”, filed Apr. 29, 2008, to co-pending U.S. patent application Ser. No. 12/112,772, titled “DYNAMIC INFORMATION CARD RENDERING”, filed Apr. 30, 2008, to co-pending U.S. patent application Ser. No. 12/170,834, titled “NON-INTERACTIVE INFORMATION CARD TOKEN GENERATION”, filed Jul. 9, 2008, to co-pending U.S. patent application Ser. No. 12/184,155, titled “SITE-SPECIFIC CREDENTIAL GENERATION USING INFORMATION CARDS”, filed Jul. 31, 2008, to co-pending U.S. patent application Ser. No. 12/201,754, titled “SYSTEM AND METHOD FOR VIRTUAL INFORMATION CARDS”, filed Aug. 29, 2008, to co-pending U.S. patent application Ser. No. 12/243,619, titled “SYSTEM AND METHOD FOR APPLICATION-INTEGRATED INFORMATION CARD SELECTION”, filed Oct. 1, 2008, to co-pending U.S. patent application Ser. No. 12/248,815, titled “TRUSTED RELYING PARTY PROXY FOR INFORMATION CARD TOKENS”, filed Oct. 9, 2008, and to co-pending U.S. patent application Ser. No. 12/253,860, titled “SMART CARD BASED ENCRYPTION KEY AND PASSWORD GENERATION AND MANAGEMENT”, filed Aug. 29, 2008, all of which are herein incorporated by reference for all purposes.
[0002] Embodiments of the disclosed technology pertain to information cards, and more particularly to using level of service descriptors for a user-selected information card in order to identify certain features that might be available on a relying party card independent of the user's identity.
[0003] 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.
[0004] 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.
[0005] While this system simplifies the management of information used to satisfy the requests of service providers, there are potential problems. A single user might have more than one account on a given service provider's computer system. For example, the user might have a basic account that gives the user a typical level of access, and an administrator account that gives the user a greater level of control. In addition, some service providers offer different privileges to an account based on how satisfied the service provider is with the identity of the user (that is, based on what claims are included in the security token). In these situations, the user has to remember which information card was provided to the service provider to gain access to the desired accounts. This problem is a serious inconvenience when the user is dealing with only one service provider: when the user has to deal with dozens or hundreds of service providers, each demanding different information to gain access to the desired accounts, remembering what information should be provided to gain access to a particular service becomes effectively impossible.
[0006] A need remains for a way to addresses these and other problems associated with the prior art.
[0007] In certain embodiments of the disclosed technology, a user can access a client having a card selector, a query generator, and a transmitter. The card selector can allow the user to select an information card based on a security policy and, responsive to the user's selection, provide a security token. The query generator can generate a query based on the selected information card, where the query pertains to information about features that are available on a relying party based on the security token and independent of the user's identity. The transmitter can then transmit the generated query as well as the security token to an endpoint on the relying party.
[0008] The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
[0009] FIG. 1 shows a sequence of communications between a client, a relying party, and an identity provider.
[0010] FIGS. 2A-2B show the client of FIG. 1 equipped to provide information to a user about federation points and information cards, both to carry out a transaction with a relying party and to manage the information about the federation points and information cards, according to a first embodiment of the invention.
[0011] FIG. 3 shows the identity provider of FIG. 1 including a secure token generator.
[0012] FIG. 4 shows the client of FIGS. 2A-2B including a secure token generator.
[0013] FIG. 5 shows details about federation points on the clients of FIGS. 2A-2B.
[0014] FIG. 6 shows details about accounts on the relying party of FIG. 1, along with levels of access associated with each account, according to a second embodiment of the invention.
[0015] FIG. 7 shows types of requests a user can make in managing federation points and information cards on the client of FIGS. 2A-2B.
[0016] FIG. 8 shows the relying party of FIG. 1 with an endpoint to process requests for information from the endpoint.
[0017] FIG. 9 shows the client of FIGS. 2A-2B and another client synchronizing federation point information and information cards.
[0018] FIG. 10 shows the details about the federation point merger of FIG. 2B.
[0019] FIG. 11 shows details about the information card merger of FIG. 2B.
[0020] FIGS. 12A-12E show a flowchart of a procedure for the client of FIGS. 2A-2B to perform a transaction with a relying party using federation point information.
[0021] FIG. 13 shows a flowchart of a procedure for the client of FIGS. 2A-2B to query an endpoint on the relying party for information about an account on the relying party.
[0022] FIGS. 14A-14B show a flowchart of a procedure for the client of FIGS. 2A-2B to manage federation points and information cards.
[0023] FIG. 15 shows a flowchart of a procedure for the relying party of FIG. 1 to respond to a query for information about an account on the relying party.
[0024] FIG. 16 shows a flowchart of a procedure for the relying party to use information derived from an information card to respond to a query for information about an account on the relying party.
[0025] FIG. 17 shows a flowchart of a procedure for the client of FIGS. 2A-2B to export information about federation points and/or information cards to another client, as part of a synchronization process.
[0026] FIG. 18 shows a flowchart of a procedure for the client of FIGS. 2A-2B to import information about federation points and/or information cards from another client, as part of a synchronization process.
[0027] FIG. 19 shows a flowchart of a procedure for the client of FIGS. 2A-2B to synchronize information about federation points imported from another client.
[0028] FIG. 20 shows a flowchart of a procedure for the client of FIGS. 2A-2B to synchronize information about information cards imported from another client.
[0029] FIG. 21 illustrates a client configured to implement a level of service descriptor mechanism in accordance with the disclosed technology, according to an embodiment of the invention.
[0030] FIG. 22 shows a flowchart of a procedure for the client of FIG. 21 to implement a level of service descriptor mechanism in accordance with the disclosed technology.
[0036] Once computer system 105 has security policy 150, computer system 105 can identify which information cards will satisfy security policy 150. Different security policies might result in different information cards being usable. For example, if relying party 130 simply needs a user's e-mail address, the information cards that will satisfy this security policy might be different from the information cards that satisfy a security policy requesting the user's full name, mailing address, and social security number. The user can then select an information card that satisfies security policy 150.
[0038] In addition, the selected information card can be a self-issued information card: that is, an information card issued not by an identity provider, but by computer system 105 itself. In that case, identity provider 135 effectively becomes part of computer system 105.
[0040] The problem with this model is, as noted above, that the user is responsible for managing the selection of the information card to be used in generating the security token. A typical user can have a large number of information cards, any of which might be used to satisfy the security policy of relying party 130. A subset of the user's information cards might be “interchangeable” in the sense that any could be used to generate an acceptable security token. But depending on which information card is used to generate the security token, the user might be granted access to different accounts. For example, if relying party 130 were to use the e-mail address from the security token to identify which account to give the user access to, then it might matter which information card the user selected to generate security token 160. Using an information card including a different e-mail address might result in the user not receiving access to the desired account, or even potentially denying the user access to any account on relying party 130. (A person skilled in the art will recognize that relying party 130 can use potentially any information in the security token to determine what level of services to give the user, and not just the user's e-mail address.)
[0041] Now that the problem—managing which information cards provide access to which accounts/services on various relying parties—is understood, embodiments of the invention can be explained. In FIGS. 2A-2B, details about client 105 are shown. A person skilled in the art will recognize that FIGS. 2A-2B show different components that can be included in client 105. A person skilled in the art will also recognize that it is not required that client 105 include every component of FIGS. 2A-2B in every embodiment, as different components are applicable to different embodiments of the invention. A person skilled in the art will also recognize that FIGS. 2A-2B do not represent specific potential embodiments of the invention: potential embodiments of the invention can include features from each of FIGS. 2A-2B, as appropriate to the embodiment of the invention.
[0042] In FIG. 2A, computer system 105 is shown as including card selector 205, receiver 210, and transmitter 215. Card selector 205 enables the user of the client to select information card 220 to use in a particular transaction. Receiver 210 receives data transmitted to computer system 105, and transmitter 215 transmits information from computer system 105.
[0043] In addition to these components, computer system 105 includes data store 225, which stores information about federation points, such as federation point 230. A federation point is a combination of an identifier of an information card and an identifier of an account on the relying party; federation points are discussed further with reference to FIG. 5 below. (A person skilled in the art will recognize that, to identify an account on a relying party, the relying party can also be identified as part of the federation point.) Note that the concept of a federation point can be used by the client; the relying party is generally concerned with the security token it ultimately receives, and generally does not care about which information card the client used to generate the security token. But as the security token can include the private personal identifier (PPID) of the information card used to generate the security token, the relying party can also be aware of an identifier of the information card used to generate the security token. There can be other ways to identify a security token: for example, the identity provider can include some information that remains constant across multiple requests for a security token (provided that the claims to be included in the security token do not change).
[0044] Computer system 105 also includes federation point adder 235 and data store accessor 240. Federation point adder 235 enables a user to define a new federation point. While federation point adder 235 can provide an interface for a user to manually specify an account on a relying party and an information card on client 105, a person skilled in the art will recognize that federation point adder 235 can operate in other ways. For example, when card selector 205 receives a user's selection of information card 220 to satisfy a request for a security token from a relying party, assuming no federation point exists that represents the combination, federation point adder 235 can prompt the user as to whether this combination represents a new federation point. Upon receiving the user's confirmation, federation point adder 235 can add the combination as a new federation point in data store 225. Data store accessor 240 enables computer system 105 to retrieve information about federation points from data store 225. Data store accessor 240 operates in a manner consistent with any other technique to access data from a data store.
[0045] Although FIG. 2A shows client 105 as storing federation point 230 separately from information card 220 (in FIG. 2A, specifically in data store 225), a person skilled in the art will recognize that federation point 230 can be stored in other ways. For example, federation point 230 can be stored as metadata in information card 220. A person skilled in the art will recognize how embodiments of the invention can be modified to support accessing federation point 230 from metadata stored in information card 220.
[0046] Turning to FIG. 2B, computer system 105 can also include relying party identifier 245. Relying party identifier 245 identifies the relying party that has requested a security token. This enables computer system 105 to be able to identify federation points that include the identified relying party (and also which information cards on computer system 105 are included in those federation points).
[0047] Computer system 105 also includes query mechanism 250. Query mechanism 250 can send a query to an endpoint on a relying party. This query can find out information about how the relying party processes security tokens, among other possibilities. For example, query mechanism 250 can query the endpoint on the relying party for how the relying party handled a security token the last time it was sent (that is, the relying party can indicate to which account the user was granted access after providing the security token). This query can be performed by submitting a security token to the relying party endpoint, or by uniquely identifying the security token in some way (but without providing the actual security token). Query mechanism 250 can also query the endpoint for how it might handle a hypothetical security token, if issued in response to a security policy: for example, an account to which the user might be granted access if the hypothetical security token were provided to the relying party. Query mechanism 250 can also query the relying party endpoint for information about the account to which the user currently has access (assuming there is an active session between client 105 and the relying party). Query mechanism 250 can also query the relying party endpoint about what claims the user could include in a security token and the accounts to which the relying party would grant the user access based on those claims. The endpoint on the relying party is discussed below with reference to FIG. 8.
[0048] Computer system 105 can include local cache 255, which can store information 260 about federation points, received from the endpoint on the relying party, in response to queries. Storing information 260 about federation points enables client 105 to use information 260 again, without having to query the end point of the relying party again. But a person skilled in the art will recognize that local cache 255 can be omitted without reducing the functionality of embodiments of the invention.
[0049] FIG. 2B also shows computer system 105 is shown as including identifier 265 and data store modifier 270. Identifier 265 can identify federation points and information cards on computer system 105 that the user is potentially interested in modifying. More particularly, if a user issues a request to modify a federation point or an information card, identifier 265 can identify which federation points and information cards might be covered by the request, so that the user can be shown those federation points and information cards. Then, when the user indicates the desired modification, data store modifier 270 can modify the data store accordingly. This modification can include adding, deleting, or modifying federation points, or adding, deleting, or modifying information cards. (A person skilled in the art will recognize that “modifying” an existing item, such as a federation point or an information card, can be thought of as equivalent to deleting an existing item and adding a new item.)
[0050] Computer system 105 can also include exporter 275, importer 280, federation point merger 285, and information card merger 290. Exporter 275 exports federation point information from computer system 105. (A person skilled in the art will recognize that “federation point information” is not limited to just the combinations of accounts on relying parties and information cards. For example, modifications to information cards can have an impact on federation points as well, and so “federation point information” can include the information cards as well.) For example, the user might have both a work computer and a personal (home) computer, and might want to be able to use the federation point information on both machines. If the federation point information were available on only one of these machines, then the user would be unable to take advantage of embodiments on the invention on the other machine. By synchronizing the two machines, the user would be able to use embodiments of the invention from both machines. Exporting federation point information using exporter 275 enables such synchronization. (A person skilled in the art will recognize that embodiments of the invention do not limit the user to being able to use federation point information on just two machines: federation point information can be synchronized to any number of devices, including, among other possibilities, notebook or laptop computers, cellular telephones, and personal digital assistants (PDA).)
[0051] Corresponding to exporter 275 is importer 280, which imports information exported from another machine. Although FIG. 2B shows exporter 275 and importer 280 on the same machine, as will often be the case (as a machine capable of exporting information for synchronization on another machine is typically capable of receiving information for synchronization from another machine), typically the client that performs the export of federation point information and the client that performs import of federation point information are different machines. Once computer system 105 has imported the federation point information, federation point merger 285 can merge the imported information about federation points into the client, and information card merger 290 can merge the imported information about information cards into the client.
[0052] Not shown in FIGS. 2A-2B are features combining embodiments of the invention with features of related patent applications. Co-pending U.S. patent application Ser. No. 12/044,816, titled “SYSTEM AND METHOD FOR USING WORKFLOWS WITH INFORMATION CARDS”, filed Mar. 7, 2008, which is hereby incorporated by reference for all purposes, describes workflows and cardflows. In some embodiments of the invention, a background, periodic maintenance mechanism can keep federation point information in the information cards in the card store up to date. Cardflows can be defined for all or a subset of the information cards in a given card store. These cardflows can be configured to invoke the relying party endpoint as described below at a specified time and for a specified set of relying parties to update federation point information.
[0053] Co-pending U.S. patent application Ser. No. 12/054,774, titled “CLAIM CATEGORY HANDLING”, filed Mar. 25, 2008, which is hereby incorporated by reference for all purposes, describes how security policies can specify that claims to be included in the security token can be categorized other than simply “required” or “optional. In some embodiments of the invention, claim categories can be used to sort, locate, and present information cards to the user. Federation point information can also be tied to particular categories of claims in the security token. For example, supplying a particular “desirable” claim can result in the relying party granting the user access to an account including a particular capability (that is, including the “desirable” claim could result in a federation point that is different from a federation point if the “desirable” claim were omitted). Additionally, the claim categories can be used to inform the user about “potential” federation points that could be achieved if the user supplies a claim that is not “required”.
[0054] Co-pending U.S. patent application Ser. No. 11/843,991, titled “CREDENTIAL CATEGORIZATION”, filed Aug. 22, 2007, which is herein incorporated by reference for all purposes, can further leverage claim categories by enabling users to define policies indicating which claims are to be included in security tokens. Using such policies can limit the federation points available to the user, but the user might consider that preferable in some circumstances.
[0055] Co-pending U.S. patent application Ser. No. 11/830,492, titled “SYSTEM AND METHOD FOR ORDERED CREDENTIAL SELECTION”, filed Jul. 30, 2007, which is hereby incorporated by reference for all purposes, can be used to tag and order the information cards displayed in a card selector. In some embodiments of the invention, the card selector can tag and order information cards according to federation point information.
[0056] A person skilled in the art will recognize how the features of these and all other related patent applications can be combined and used in embodiments of the invention.
[0057] As discussed above with reference to FIG. 1, information cards can be either managed or self-issued. If the information card is managed, then the security token is generated by an identity provider. In FIG. 3, identity provider 135 includes secure token service 305. Secure token service 305 generates the security token as instructed by identity provider 135, responsive to the security policy received from the relying party, and including the claims specified by the client.
[0058] If the information card is self-issued (that is, the information card is not managed by an identity provider), then the client generates the security token directly. (The relying party can tell the difference between a security token generated by an identity provider and a security token generated by a client by examining the security token. If the relying party wants to, the relying party can refuse a security token based on a self-issued information card.) In FIG. 4, client 105 includes secure token generator 405, which can generate the security token based on the self-issued information card.
[0059] FIG. 5 shows details about federation points on the clients of FIGS. 2A-2B. In contrast to FIG. 2A, where federation points are shown as individual items, FIG. 5 shows the federation points in a table. A person skilled in the art will recognize other ways in which federation point information can be represented. In FIG. 5, information about five federation points is shown, but a person skilled in the art will recognize that there can be any number of federation points stored on the client. Federation points 230 and 505 include a bank account (account 1 with bank 1) and information card 1. Federation point 510 includes account 1 on web site 1 and information card 2. Federation point 515 includes account 2 on web site 1 and information card 3. Finally, federation point 520 includes account 1 on web site 2 and information card 1. (A person skilled in the art will recognize that federation points 230, 505, 510, 515, and 520 do not store the actual relying party, account, or information card, but rather store identifiers of these objects.)
[0060] It might be considered curious that FIG. 5 shows two federation points 230 and 505, both including a single information card (information card 1), but associated with different accounts on the relying party (accounts 1 and 2 on bank 1). The reason for this interesting circumstance is that if security tokens provided to the relying party (bank 1) includes different claim sets, the relying party might grant the user access to different accounts, even though the same information card was used to generate the security token. For example, if the bank in federation points 230 and 505 receives a security token including only the user's name and e-mail address, the bank might grant the user access to an account that permits the user view his current balance, but not let the user transfer funds. But if the security token were to also include a biometric, the bank could be more certain that the user is properly authenticated, and might grant the user access to a different account that also permits the user transfer funds from one account to another. If the bank lists the biometric as a desirable claim but does not require it, then the relying party can determine the level of access to grant the user at the time the relying party receives the security token. A person skilled in the art will recognize that this example can be modified so that the same account is used, but the user is granted different levels of privilege associated with the account. (In this situation, there can be multiple federation points associating a single information card with a single account on a relying party.)
[0061] The potential for accessing different accounts on the relying party, or even of different levels of access to an individual account on the relying party, based on which claims are included in the security token could be information of value to the user. Continuing the example of the bank in federation points 230 and 505, the user might find it valuable to know that including non-required claims in the security token could give the user access to the different accounts or different levels of access in a single account. (The identification of these non-required claims could be handled as described in co-pending U.S. patent application Ser. No. 12/054,774, titled “CLAIM CATEGORY HANDLING”, filed Mar. 25, 2008, which is hereby incorporated by reference for all purposes.) In one embodiment of the invention (not shown in FIG. 5), the system can store a different federation point to represent these different levels of access. This embodiment of the invention can be achieved by specifying the claims included in the security token in the federation point. For example, federation point 230 can specify that the security token includes only the user's name and e-mail address, and federation point 505 can specify that the security token includes the user's name, e-mail address, and biometric. By storing this additional information, the user can be made aware of the different levels of access granted using the same information card.
[0062] FIG. 5 shows that a single information card can be used in multiple federation points. For example, federation points 230 and 520 both include information card 1, using the user's name and e-mail address as claims in the security token. As both account 1 on bank 1 and account 1 on web site 2 request these credentials, the same information card can be used to generate security tokens for both of these accounts. In contrast, federation points 510 and 515 use other information cards: perhaps the user used different e-mail addresses in setting up these accounts, and so different information cards are needed to generate the security token. (A person skilled in the art will recognize other reasons why different information cards might be used for federations 510 and 515: for example, that this relying party will not accept security tokens generated by the identity provider managing information card 1, or this relying party requests a form of encryption not provided by the identity provider managing information card 1.)
[0063] FIG. 6 shows details about accounts on the relying party of FIG. 1, along with levels of access associated with each account, according to a second embodiment of the invention. In FIG. 6, relying party 130 is shown as having four established accounts (605, 610, 615, and 620). For each account, there is a corresponding level of access granted to the user of the account. Thus, for accounts 605, 610, 615, and 620, there are corresponding levels of access 625, 630, 635, and 640.
[0064] Level of access 635, for account 615, is enlarged as an example. In FIG. 6, level of access 635 actually includes two different levels of access, depending on which claims are provided in the security token. If the security token satisfies only claims 1-2 (as shown by level of access 645) then the user receives only level 1 access to the account; if the security token satisfies claims 1-3 (as shown by level of access 650), then the user receives level 2 access to the account. Referring back to the example of a bank described above with reference to FIG. 5, level 1 access 645 can be conditioned on receiving only the user's name and e-mail address in the security token; level 2 access 650 can be conditioned on also receiving the user's biometric in the security token.
[0065] While level of access 635 shows two levels of access for a single account, a person skilled in the art will recognize that there can be any number of levels of access, conditioned on the claims included in the security token. Further, there can be different rules regarding the levels of access for different accounts offered by relying party 130: not all accounts have to be given the same levels of access. For example, level of access 625 could specify only a single level of access for account 605.
[0066] FIG. 7 shows types of requests a user can make in managing federation points and information cards on the client of FIGS. 2A-2B. In FIG. 7, receiver 210 (on the client) can receive any number of different types of requests to manage federation points and information cards. Among the requests the user can make are:
Request 705 to manage all federations points that include a relying party (such management can include adding, deleting, and/or modifying such federation points). Request 710 to manage all information cards that are included in federation points including a particular account on a particular relying party. Request 715 to manage all federation points that include a particular information card. Request 720 to add a federation point for a combination of a relying party account and an information card. Request 725 to delete a federation point. Request 730 to change federation point(s) that include a particular information card. [0073] A person skilled in the art will recognize that requests 705, 710, 715, 720, 725, and 730 are merely exemplary types of requests that a user can make in managing federation points and information cards, and that other requests can be made as well. For example, a user can request to add, delete, or modify information cards (without necessarily being limited to those information cards included in a federation point).
[0074] As discussed above with reference to FIG. 2B, a client can query an endpoint on a relying party for information about how the relying party might process a particular security token. FIG. 8 shows the relying party of FIG. 1 with an endpoint to process such requests for information from the endpoint. In FIG. 8, relying party 130 includes endpoint 805, which receives the query. Data store 810 stores information that can be used to respond to the query, such as information 815. Such information can include, for example, the last time a security token was received, to which account access was granted based on that security token, and what level of access was granted to that account. While the security token can be represented in data store 810 by storing the security token in its entirety, a person skilled in the art will recognize that there are other ways to represent the security token. For example, the security token can be identified based on an identifier of the information card that was used to generate the security token, a signature modulus used in the security token, and/or an encryption key used to encrypt the security token (or a combination of these components), among other possibilities.
[0075] Relying party 130 can also include policy store 820. Policy store 820 stores policies, such as policy 825, that are used to control how relying party 130 responds when it receives a security token. For example, policy 825 can specify what level of access is to be granted to an account, based on the claims included in the security token. (In other words, policy 825 can specify the level of access criteria described above with reference to FIG. 6.)
[0076] After the query has been received and the information that determines the response identified, response generator 830 can generate the response, which can be transmitted to the requester via transmitter 835.
[0077] Although the queries endpoint 805 can receive might inquire about past behavior or potential future behavior of relying party 130, a person skilled in the art will recognize that the response to the query does not guarantee the behavior of relying party 130 when it actually receives a security token. This lack of guarantee applies even if the security token that is later sent exactly matches a previously sent security token, or if the security token includes exactly the information relying party 130 indicates is needed. The reason a response to a query provides no guarantee is simple: data can change, both within the security token and within the policies used by relying party 130 in processing the security token.
[0078] For example, consider the situation where the client queries endpoint 805 about how relying party 130 might respond given a security token: this security token is identified to endpoint 805 by some identifier. Relying party 130 can only respond with how it behaved the last time it received the identified security token. But if the information managed by an identity provider has changed since the last time a security token was generated using that information, the resulting security token will be different. Because relying party 130 cannot guarantee what will happen if the underlying data changes, endpoint 805 can only indicate what has happened previously.
[0079] Alternatively, consider the situation where the client sends a security token to endpoint 805 and inquires about how relying party 130 would treat the security token. Relying party 130 can indicate how the security token would be processed at the time of the query. But if the policies of relying party 130 change between the time the response to the query is sent and when the client submits the security token for identification purposes, relying party 130 might process the security token differently when it is offered for identification purposes.
[0080] Similarly, consider what can happen if the query inquires from endpoint 805 about what alternative levels of access are available for an account on relying party 130, and what claims would need to be provided to receive that alternative level of access. Endpoint 805 can indicate that a greater level of access could be granted if a biometric is included with the security token. But if policy 825 changes between the time endpoint 805 responds to the query and when the security token is actually received, it might be that the inclusion of the biometric claim is now insufficient to receive the alternative level of access. Thus, even a response indicating what kind of security token would be needed in the future is not a guarantee that that security token would actually result in receiving that alternative level of access.
[0081] FIG. 9 shows the client of FIGS. 2A-2B and another client synchronizing federation point information and information cards. As discussed above with reference to FIG. 2B, synchronization of federation points and information cards enables a user to use this information from multiple machines, rather than being limited to a single machine storing the federation point information and information cards. FIG. 9 shows client 105 using exporter 275 to export information 905, which includes both information about the federation points on client 105 (or potentially only some of the federation points on client 105, depending on what information the user chooses to export), and about information cards on client 105. This information can then be imported into another client, such as client 910 or PDA 915 (among other possibilities of devices that can import such information) using importer 280. (A person skilled in the art will recognize that while FIG. 9 shows two potential importing clients 910 and 915 and only one importer 280, each receiving device often has its own importer 280.)
[0082] FIG. 10 shows the details about the federation point merger of FIG. 2B. As discussed above with reference to FIG. 2B, federation point merger 285 merges imported federation point information into the client's stored data. To accomplish this, federation point merger 285 can include absent federation point identifier 1005 and adder 1010: absent federation point identifier 1005 can identify a federation point in the imported data that is absent on the client machine, and adder 1010 can add the absent federation point to the client. Federation point merger 285 can also include modified federation point identifier 1015 and modifier 1020: modified federation point identifier can identify a federation point resident on both clients, but storing different data, and modifier 1020 can modify the federation point on the importing client to match the federation point exported from the other client. Finally, federation point merger 285 can include deleted federation point identifier 1025 and deleter 1030: deleted federation point identifier can identify a federation point that is resident on the importing client but that does not exist in the imported federation point information, and deleter 1030 can delete the identified federation point from the importing client.
[0083] FIG. 11 shows details about the information card merger of FIG. 2B. Similar to federation point merger 285 of FIG. 10, information card merger 290 merges imported information cards into the client's stored data. To accomplish this, information card merger 290 can include absent information card identifier 1105 and adder 1110: absent information card identifier 1105 can identify an information card in the imported data that is absent on the client machine, and adder 1110 can add the absent information card to the client. Information card merger 290 can also include modified information card identifier 1115 and modifier 1120: modified information card identifier can identify an information card resident on both clients, but storing different data, and modifier 1120 can modify the information card on the importing client to match the information card exported from the other client. Finally, information card merger 290 can include deleted information card identifier 1125 and deleter 1130: deleted information card identifier can identify an information card that is resident on the importing client but that does not exist in the imported information card information, and deleter 1130 can delete the identified information card from the importing client.
[0084] While FIGS. 10 and 11 suggest that federation point merger 285 and information card merger 290 are separate elements, a person skilled in the art will recognize that this is not necessarily the case. For example, as discussed above with reference to FIG. 2A, federation point information can be stored as metadata to the information cards on the client. In that situation, federation point merger 285 is implicitly a part of information card merger 290, and might not be a separate element.
[0085] FIGS. 12A-12E show a flowchart of a procedure for the client of FIGS. 2A-2B to perform a transaction with a relying party using federation point information. In FIG. 12A, at block 1203, the client receives a security policy from a relying party. At block 1206, the client identifies the relying party. At block 1209, the client identifies federation points that include the relying party. At block 1212, the client identifies information cards that are included in the identified federation points. This can include requesting information from identity providers that are responsible for managing the identified information cards, so that the card selector can later present the user with the values that would be supplied to the relying party in the various claims: this information can be requested in the form of a security token for use by the client. At 1215 receives from the user a request for federation point information; this request can be embodied in a request to initiate a cardflow pertaining to federation points, as shown in block 1218. Block 1218 and block 1215 are both optional, as shown by dashed arrows 1221 and 1224: the user can skip requesting the cardflow, or requesting the information about the federation point information (that is, the client can omit presenting this information to the user, or the client can automatically display this information, without the user explicitly requesting it).
[0086] In FIG. 12B, the client can access information about how the relying party might respond to a particular security token generated using various information cards. At block 1227, the client can access information about how the relying party might respond to a security token from a local cache.
[0087] Alternatively, at block 1230, the client can query an endpoint on the relying party for the information. This query can be accomplished by initiating a cardflow, as shown in block 1233. Initiating the cardflow is optional, as shown by dashed arrow 1236. At block 1239, the client then receives the information from the endpoint on the relying party, and at block 1242 the client caches this information. Caching the information is optional, as shown by dashed line 1245. Alternatively, the client can skip accessing such information entirely, as shown by dashed line 1248.
[0088] At block 1251 (FIG. 12C), the client presents the user with information about the federation points and information cards. At block 1254, the client informs the user about accounts on the relying party, and the levels of access available for those accounts. At block 1257, the client receives from the user a selected information card, to use in generating the security token.
[0089] At block 1260 (FIG. 12D), the client identifies the type of the information card. If the information card is self-issued, then at block 1263 the client generates the security token using a local security token generator. If the information card is managed, then at block 1266 the client identifies the identity provider managing the information card. At block 1269, the client requests a security token from the identity provider, and at block 1272 the client receives from the identity provider the security token.
[0090] At block 1275 (FIG. 12E), the client forwards the security token (however generated) to the relying party. At block 1278, the client determines if a federation point (identifying the relying party, the account to which the user gains access, and the selected information card) exists. If not, then at block 1281 the client queries an endpoint on the relying party for information about the account on the relying party (this can be useful if the endpoint can provide information that the client does not already have about the federation point). Block 1281 is optional, as shown by dashed arrow 1284. At block 1287, the client creates the federation point, identifying in the federation point the account on the relying party and the information card. At block 1290, the client queries an endpoint on the relying party for information about the federation point, to store for future potential uses of the information card, and at block 1293 the client caches this information locally. Blocks 1290 and 1293 are optional, as shown by dashed line 1296.
[0091] FIG. 13 shows a flowchart of a procedure for the client of FIGS. 2A-2B to query an endpoint on the relying party for information about an account on the relying party. Among the different information a client can query an endpoint about are: information about a previous use of a security token (block 1305); information about a potential use of a security token (block 1310); information about a current use of a security token (1315); and information about accounts (or different levels of access associated with accounts) to which the user might potentially gain access (block 1320). If the client is querying for information about accounts (or different levels of access associated with accounts) to which the user might potentially gain access (block 1320), the client can also query for information about the requirements to access those accounts (block 1325): for example, claims that would need to be in the security token for the user to gain that level of access.
[0092] FIGS. 14A-14B show a flowchart of a procedure for the client of FIGS. 2A-2B to manage federation points and information cards. In FIG. 14A, at block 1405, the client receives a request to manage a federation point and/or an information card. This request can be embodied in a request to initiate a cardflow pertaining to managing federation points and/or information cards, as shown in block 1410. Block 1410 is optional, as shown by dashed arrow 1415: the user can skip requesting the cardflow. At block 1420, the client identifies all federation points to which the request applies. At block 1425, the client identifies all information cards to which the request applies. At block 1430, the client presents to the user the identified federation points and/or information cards. At block 1435, the client receives from the user a requested change.
[0093] At block 1440 (FIG. 14B), the client stores the change (that is, the client implements the requested change). At block 1445, the client queries an endpoint on the relying party for information (for example, how the relying party might respond to a security token generated from a particular information card). This request can be embodied in a request to initiate a cardflow pertaining to managing federation points and/or information cards, as shown in block 1410. This query can be accomplished by initiating a cardflow, as shown in block 1450. At block 1455, the client receives from the endpoint the requested information, and at block 1460 the client caches the received information. Block 1450 and blocks 1445, 1455, and 1460 are optional, as shown by dashed arrows 1465 and 1470.
[0094] FIG. 15 shows a flowchart of a procedure for the relying party of FIG. 1 to respond to a query for information about an account on the relying party. In FIG. 15, at block 1505, the endpoint on the relying party receives a query for information from a requestor (typically a client machine being used by a user). At block 1510, the endpoint determines the requested information, and at block 1515 the endpoint sends the requested information to the requestor.
[0095] FIG. 16 shows a flowchart of a procedure for the relying party to use information derived from an information card to respond to a query for information about an account on the relying party. In FIG. 16, at block 1605, the endpoint can derive information from a security token. This derived information can include an identifier of the security token, a signature modulus, an encryption key, or a combination of these components, among other possibilities. At block 1610, the endpoint uses the derived information in conjunction with a policy on the relying party to predict the acceptance of the security token.
[0096] FIG. 17 shows a flowchart of a procedure for the client of FIGS. 2A-2B to export information about federation points and/or information cards to another client, as part of a synchronization process. At block 1705, the client receives a request to synchronize federation point information; this request can be embodied in a request to initiate a cardflow to synchronize federation point information, as shown in block 1710. Block 1710 is optional, as shown by dashed line 1715. At block 1720, the client identifies a federation point that is to be synchronized. This can entail identifying every federation point on the client, or just specific federation points that the user wants to synchronize. At block 1725, the client identifies an information card that is to be synchronized. As with the federation points, this can entail identifying every information card on the client, or just specific information cards that the user wants to synchronize. At block 1730, the client exports the identified federation points and information cards.
[0097] FIG. 18 shows a flowchart of a procedure for the client of FIGS. 2A-2B to import information about federation points and/or information cards from another client, as part of a synchronization process. At block 1805, the client imports information about federation points and information cards. At block 1810, the client merges the imported federation points, and at block 1815, the client merges the imported information cards.
[0098] FIG. 19 shows a flowchart of a procedure for the client of FIGS. 2A-2B to synchronize information about federation points imported from another client. At block 1905, the client identifies a federation point in the imported information that is not resident on the client; at block 1910, the client then adds the federation point. At block 1915, the client determines that a federation point on the client is modified; at block 1920, the client modifies the federation point to be consistent with the imported federation point. At block 1925, the client identifies a federation point resident on the client that is not in the imported information; at block 1930, the client deletes the federation point.
[0099] While FIG. 19 shows blocks 1905, 1910, 1915, 1920, 1925, and 1930 being performed once, a person skilled in the art will recognize that there are many variations on how federation point information is merged, and that FIG. 19 is merely exemplary. There might be many federation points to add, modify, and/or delete, in which case the appropriate blocks of FIG. 19 can be repeated as necessary to complete the merge operation.
[0100] As with the federation points of FIG. 19, information cards can be merged from imported information. FIG. 20 shows a flowchart of a procedure for the client of FIGS. 2A-2B to synchronize information about information cards imported from another client. At block 2005, the client identifies an information card in the imported information that is not resident on the client; at block 2010, the client then adds the information card. At block 2015, the client determines that an information card on the client is modified; at block 2020, the client modifies the information card to be consistent with the imported information card. At block 2025, the client identifies an information card resident on the client that is not in the imported information; at block 2030, the client deletes the information card.
[0101] While FIG. 20 shows blocks 2005, 2010, 2015, 2020, 2025, and 2030 being performed once, a person skilled in the art will recognize that there are many variations on how information card information is merged, and that FIG. 20 is merely exemplary. There might be many information cards to add, modify, and/or delete, in which case the appropriate blocks of FIG. 20 can be repeated as necessary to complete the merge operation.
[0102] The above discussion defines a federation point as the combination of an identifier of an account on the relying party and an identifier of an information card on a client. A federation point enables a user to learn how a relying party identifies the user, and how that identification can be used. For example, the act of “federation” occurs whenever an information card is presented to a relying party (or more specifically, when a security token, generated using the selected information card, is presented to a relying party). At the time the relying party receives a security token, the relying party determines who the user is to that relying party and what privileges and capabilities are granted to that user. (Because a user might have multiple different identities, represented by different information cards, the relying party is not determining the user's actual identity, but rather who the relying party perceives the user to be.)
[0103] The relying party has complete discretion and control in deciding which factors from the security token are used to determine who the user is and what privileges and capabilities are granted to that user. But these factors are limited to information that is received with the security token: for example, the claims requested by the relying party in the security policy (required, optional, or otherwise-categorized claims, and\or their values), and other security token metadata such as the card issuer, expiration dates, etc.
[0104] If the user is interested in information that goes beyond how the relying party identifies the user, a federation point will not provide sufficient information. For example, the services or privileges the relying party offers can only be guessed at by the user given a federation point since it only contains information about the account to which a user is granted access. In fact, if the relying party does not maintain static information about user accounts, a federation point will not provide the user with any information about how the relying party identifies the user and, thus, nothing to even allow the user to venture a guess at things such as privileges and services that are available, etc. For example, if the relying party defines the account dynamically at the time the user requests access and destroys any information about the account once access is complete, the user is not given access to any single “defined” account, and a federation point would provide no benefit.
[0105] For the user to access information about such services, privileges, features accessible on the relying party, and other functionalities offered by the relying party, the relying party may instead provide the user with a level of service descriptor. In addition, level of service descriptors can be used to provide relying party-defined information that is not defined by any generally-accepted standard. A level of service descriptor is a mechanism that operates similarly to a federation point, but provides the user with information about the nature and level of the service a relying party provides, including among other possibilities the privileges, features, capabilities, temporal constraints, and other relying party-defined information, without necessarily divulging the user's identity to the relying party.
[0106] Note that a level of service descriptor may contain information to identify a particular account on the relying party. In fact, all information in a level of service descriptor may be considered optional and, whether it is predefined or not, its inclusion is totally in the purview of the relying party. The user has a way to discover level of service information and the relying party understands the type of information being requested. For example, as discussed above, the relying party might not have a user account defined for the user—the relying party might dynamically create the user account when presented with the security token, and “close” the account when the transaction is complete. In such an embodiment, the relying party would have no need to create or track users of the relying party's services with formal accounts, and might not use the claims provided in the security token to identify the user.
[0107] In fact, the relying party might have no need to identify the presenter of the security token in the form of a “user” at all. The relying party might only use the security token to specify the privileges or capabilities granted to the party presenting the security token independent of the user's identity. Similarly, the relying party might not identify specific privileges or capabilities for a user, but use the security token to identify a specific account being used. But regardless of how the relying party uses the security token, any relying party can provide level of service descriptor information insofar as it applies to their service. Other examples of information that can be considered optional in a level of service descriptor can include privileges, capabilities, quality of service, and temporal constraints, as well as other potentially relying party-specific level of service information.
[0108] In one embodiment of the invention, a level of service descriptor can be implemented by the relying party to include a federation point in addition to information such as privileges, available features, and temporal constraints, for example. In such an embodiment, a person might consider a level of service descriptor to be a generalization of a federation point. But because a level of service descriptor in general provides a different scope of functionality than a federation point, and because the inclusion of federation point information in a level of service descriptor is optional, it is simplistic to view a level of service descriptor to be a generalization of a federation point: in general, federation points and level of service descriptor have little in common. The information created in a level of service descriptor can be created based on any claims provided in a security token, since those claims can be used by the relying party to provide different levels of service. In contrast, federation points focus on the claims in the security token used by the relying party to identify the user; any claims not relevant to the user's identification are typically not part of the federation point.
[0109] FIG. 21 illustrates a client computer system 105 that is configured to implement a level of service descriptor mechanism in accordance with the disclosed technology. Client 105 is shown as including card selector 205 that is able to access multiple information cards 220 that can be available to a user (e.g., that are stored locally). Client 105 also includes receiver 210, query generator 2105, and transmitter 215. Client 105 can also include display module 2110 for sending information to a visual display: for example, a monitor.
[0110] Card selector 205 enables the user to select one of the information cards 220 that might be available to the user. For example, the user might want to determine what features would be available on a certain relying party (not shown in FIG. 21) should the user decide to access features or services offered by the relying party (e.g., log into an existing account, or create a new account on the relying party) using the selected information card. Once the user selects a particular information card, card selector 205 can provide a security token in response to the user's selection.
[0111] Receiver 210 can be used to enable client 105 to receive certain items from an endpoint on a relying party, for example, such as a security policy for the relying party. In certain embodiments, a relying party's security policy can impact which information cards card selector 205 presents to the user for selection. For example, if certain information cards do not meet the relying party's security policy, card selector 205 can omit these information cards. Receiver 210 can also be used to receive from the relying party information that is generated by the relying party in response to a query transmitted to the relying party from client 105 (e.g., via transmitter 215).
[0112] Query generator 2105 can generate a query based on the selected information card. For example, the generated query can include a request for information from the relying party pertaining to features that are and/or might be available to the user based on the security token and independent of the user's identity. The features can include, but are not limited to, user privileges, relying party services, relying party capabilities, and temporal constraints. In certain embodiments, the features can pertain to a dynamically created account on the relying party.
[0113] Transmitter 215 can transmit information from client 105 to the relying party (e.g., via an endpoint on the relying party). For example, transmitter 215 can transmit to the relying party the query generated by query generator 2105 as well as the security token provided by card selector 205 in response to the selection of the selected information card.
[0114] Once the relying party receives and processes the query and the security token, the relying party can determine what features might be available on the relying party based on the security token. The relying party can then construct a response containing information about the features that might be available and send the response to client 105 via a communication between the endpoint on the relying party and receiver 210 on client 105, for example.
[0115] Display module 2110 can graphically display various aspects of the level of service mechanism implemented in client 105. For example, display module 2110 can enable card selector 205 to visually present information cards 220 to the user during the user selection process. Display module 2110 can also visually present to the user information pertaining to the response received from the relying party. For example, the display module can visually communicate to the user the features that might be available on the relying party based on the provided security token.
[0116] In certain embodiments, a user can use card selector 205 to select two or more information cards 220 during the card selection process. Responsive to the card selections, the card selector 205 can provide a security token for each selected information card. Query generator 2105 can generate a query pertaining to features that might be available on the relying party for each selected card, individually or cumulative. In situations where a user selects two or more information cards 220, card selector 205 can operate with respect to each card separately (e.g., card selector 205 may not initiate any operations with respect to the second selected card until card selector 205 has finished its operations with respect to the first selected card). Alternatively, card selector 205 can carry out some or all of the operations with respect to each of selected cards 220 concurrently.
[0117] Transmitter 215 can transmit the generated query and the provided security tokens to the relying party endpoint. Based on the provided security tokens, and independent of the user's identity, the relying party can determine what features might be available on the relying party and construct a response to the query. The relying party can send the response to client 105, and client 105 can then communicate at least some of the information from the response to the user (e.g., via display module 2110).
[0118] FIG. 22 shows a flowchart of a procedure for the client of FIG. 21 to implement a level of service descriptor mechanism by generating and transmitting a query to determine what features might be available on a relying party based on a security token provided in response to a user selection of a particular information card.
[0119] At block 2205, the client receives a selection of an information card. For example, the card selector on the client can identify and present to a user one or more information cards that are available to him or her. The card selector can present the information cards via the display module, for example. In certain embodiments, the card selector can present some or all of the information cards that satisfy the relying party's security policy. The security policy can be received by the receiver or can be stored locally. Alternatively, the card selector can present additional information cards that might or might not be available to the user. Once the card selector presents the user with the identified information cards, the user can then select one of the information cards and inform the card selector of the selection (e.g., via a user input interface on the client).
[0120] At block 2210, a security token can be provided based on the information card selected at block 2205. In certain embodiments, the security token can be generated responsive to the card selection by the user. Alternatively, the security token can be retrieved from a security token store located on the client or elsewhere.
[0121] At block 2215, a query can be generated based on the selected card. The query can be generated based on the security token provided in response to the user's selection of the information card. The query can pertain to information about features on the relying party that might be available to the user based on the security token and independent of the user's identity. The features can include user privileges, relying party services, relying party capabilities, and temporal constraints, for example. Or, the features might pertain to a dynamically created account.
[0122] At block 2220, the generated query and security token can be transmitted from the client to the relying party. For example, the transmitter on the client can transmit the query and the security token to an endpoint on the relying party. Once the relying party receives the generated query and the security token, the relying party can determine what features might be available to the user based on the security token and independent of the user's identity. The relying party can then provide the client with this information so that the client can inform the user as to what features on the relying party might be available to him or her based on the selected information card and independent of his or her identity.
[0123] In certain embodiments, the card selector can present one or more secondary information cards to the user in response to the information received from the relying party. The secondary cards can include information cards that were originally presented to the user but were not selected during the initial user selection process. The secondary cards can also include additional information cards that were not originally presented to the user. The user can select one of the secondary cards and the card selector can provide a second security token responsive to the selected card. The query generator can generate a second query based on the selected information card and the transmitter can then transmit the second query, as well as the second security token, to the relying party (e.g., via the endpoint on the relying party).
[0124] Once the relying party has received the second query and second security token, the relying party can construct a second response containing information as to what features might be available based on the second security token while still independent of the user's identity. The relying party can send the second response to the client, and the client can then present the user with information pertaining to the second response via the display module, for example.
[0125] There are numerous situations in which tracking federation point or level of service descriptor information is useful. The embodiments of the invention described above illustrate some such situations. Other situations in which tracking federation point or level of service descriptor information can be useful include embodiments where the user is expected to choose an information card, either through the card selector or through some other means, such as those described in co-pending U.S. patent application Ser. No. 12/243,619, titled “SYSTEM AND METHOD FOR APPLICATION-INTEGRATED INFORMATION CARD SELECTION”, filed Oct. 1, 2008, which is herein incorporated by reference for all purposes.
[0126] For example, when a user is interacting with an application that requests a security token (be it an application running on the user's computer or a relying party accessed via a browser), the selector daemon can poll the application for the current state of the federation point or level of service descriptor. Then, when the user is requested to select an information card to use in generating a security token, the user can be presented with the most current state of the federation point or level of service descriptor. As discussed above, the cached information about a past state of the federation point or level of service descriptor is not considered to be a guarantee of what might happen when the security token is sent to the application in the current use. For example, the application might have its security policy or the factors it uses to identify the user's accounts, privileges, and capabilities.
[0127] To gather this federation point or level of service descriptor information (regardless of when the federation point information is requested or the process by which it is gathered), a relying party defines and implements an endpoint. This endpoint would receive the same security token that would be presented to the relying party after an information card was selected by the user. But the endpoint would not use the security token to authenticate the user: the endpoint uses the security token to estimate what might happen if that security token were presented to the relying party after the user's selection of an information card. This allows the relying party to make the same computations it would make if it were actually being presented with the specified token for authentication.
[0128] In the most straightforward embodiment, the card selector is invoked, shows the information cards that satisfy the relying party's security policy, requests the federation point or level of service descriptor information for each such information card, and displays the federation point or level of service descriptor information with each card to enable the user to make an informed selection. This display of the federation point or level of service descriptor information can also include sorting the information cards based on the federation point information, or providing the user with some cues about the information cards and their federation point or level of service descriptor information, as described in co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, and co-pending U.S. patent application Ser. No. 12/112,772, titled “DYNAMIC INFORMATION CARD RENDERING”, filed Apr. 30, 2008, which are herein incorporated by reference for all purposes.
[0129] 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.
[0130] The machine can include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine can utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines can be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication can utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth, optical, infrared, cable, laser, etc.
[0131] The invention can be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, instructions, etc. which, when accessed by a machine, result in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data can be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, and other tangible, physical storage media. Associated data can also be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and can be used in a compressed or encrypted format. Associated data can be used in a distributed environment, and stored locally and/or remotely for machine access.
[0132] 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.
[0133] Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as can come within the scope and spirit of the following claims and equivalents thereto.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS3949501 *Dec 7, 1973Apr 13, 1976Polaroid CorporationNovel identification cardUS4153931 *Nov 6, 1974May 8, 1979Sigma Systems Inc.Automatic library control apparatusUS4568403 *Feb 15, 1985Feb 4, 1986Miller Products, Inc.Method of making laminated memberUS4730848 *May 19, 1986Mar 15, 1988General Credit Card Forms, Inc.Credit card transaction slips pack and method of makingUS5485510 *Sep 1, 1994Jan 16, 1996At&T Corp.Secure credit/debit card authorizationUS5546471 *Oct 28, 1994Aug 13, 1996The National Registry, Inc.Ergonomic fingerprint reader apparatusUS5546523 *Apr 13, 1995Aug 13, 1996Gatto; James G.Electronic fund transfer systemUS5594806 *Jun 20, 1994Jan 14, 1997Personnel Identification & Entry Access Control, Inc.Knuckle profile indentity verification systemUS5613012 *May 17, 1995Mar 18, 1997Smarttouch, Llc.Tokenless identification system for authorization of electronic transactions and electronic transmissionsUS6028950 *Feb 10, 1999Feb 22, 2000The National Registry, Inc.Fingerprint controlled set-top boxUS6055595 *Sep 18, 1997Apr 25, 2000Kabushiki Kaisha ToshibaApparatus and method for starting and terminating an application programUS6363488 *Jun 7, 1999Mar 26, 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS6513721 *Nov 27, 2000Feb 4, 2003Microsoft CorporationMethods and arrangements for configuring portable security token features and contentsUS6721713 *May 27, 1999Apr 13, 2004Andersen Consulting LlpBusiness alliance identification in a web architecture frameworkUS6880155 *Feb 2, 1999Apr 12, 2005Sun Microsystems, Inc.Token-based linkingUS6913194 *Jul 7, 2003Jul 5, 2005Hitachi, Ltd.Method and system to prevent fraudulent payment in credit/debit card transactions, and terminals thereforUS7003501 *Feb 9, 2001Feb 21, 2006Maurice OstroffMethod for preventing fraudulent use of credit cards and credit card information, and for preventing unauthorized access to restricted physical and virtual sitesUS7210620 *Jan 4, 2005May 1, 2007Ameriprise Financial, Inc.System for facilitating online electronic transactionsUS7225156 *Jan 29, 2002May 29, 2007Fisher Douglas CPersistent dynamic payment serviceUS7231369 *Mar 28, 2002Jun 12, 2007Seiko Epson CorporationDigital contents provision system, server device incorporated in the system, digital contents provision method using the system, and computer program for executing the methodUS7343351 *Aug 31, 2000Mar 11, 2008American Express Travel Related Services Company, Inc.Methods and apparatus for conducting electronic transactionsUS7353532 *Aug 30, 2002Apr 1, 2008International Business Machines CorporationSecure system and method for enforcement of privacy policy and protection of confidentialityUS7360237 *Jul 30, 2004Apr 15, 2008Lehman Brothers Inc.System and method for secure network connectivityUS7416486 *Jun 9, 2006Aug 26, 2008Walker Digital, LlcMethod and apparatus for providing insurance policies for gambling lossesUS7487920 *Jun 18, 2004Feb 10, 2009Hitachi, Ltd.Integrated circuit card system and application loading methodUS7494416 *Dec 9, 2004Feb 24, 2009Walker Digital, LlcMethod and apparatus for providing insurance policies for gambling lossesUS7500607 *Oct 23, 2006Mar 10, 2009First Data CorporationSystem for managing risk of financial transactions with location informationUS7529698 *Jan 15, 2002May 5, 2009Raymond Anthony JoaoApparatus and method for providing transaction history information, account history information, and/or charge-back informationUS7537152 *Jul 17, 2007May 26, 2009E2Interative, Inc.Delivery of value identifiers using short message service (SMS)US7555460 *Jun 30, 2009Diversinet Corp.Payment system and method using tokensUS7565329 *Jul 21, 2009Yt Acquisition CorporationBiometric financial transaction system and methodUS7661585 *Sep 16, 2008Feb 16, 2010Raymond Anthony JoaoApparatus and method for providing transaction history information, account history information, and/or charge-back informationUS7664022 *Aug 29, 2006Feb 16, 2010Cingular Wireless Ii, LlcPolicy-based service management systemUS7747540 *Jun 29, 2010Microsoft CorporationAccount linking with privacy keysUS20010007983 *Mar 2, 2001Jul 12, 2001Lee Jong-IiMethod and system for transaction of electronic money with a mobile communication unit as an electronic walletUS20020026397 *Mar 1, 2001Feb 28, 2002Kaname IetaMethod for managing card information in a data centerUS20020029337 *Jun 1, 2001Mar 7, 2002Certco, Llc.Method for securely using digital signatures in a commercial cryptographic systemUS20020029342 *Jul 27, 2001Mar 7, 2002Keech Winston DonaldSystems and methods for identity verification for secure transactionsUS20020046041 *May 10, 2001Apr 18, 2002Ken LangAutomated reputation/trust serviceUS20020095360 *Jan 15, 2002Jul 18, 2002Joao Raymond AnthonyApparatus and method for providing transaction history information, account history information, and/or charge-back informationUS20020103801 *Jan 31, 2001Aug 1, 2002Lyons Martha L.Centralized clearinghouse for community identity informationUS20020116647 *Feb 20, 2002Aug 22, 2002Hewlett Packard CompanyDigital credential monitoringUS20030061170 *Oct 15, 2002Mar 27, 2003Uzo Chijioke ChukwuemekaMethod and apparatus for making secure electronic paymentsUS20030126094 *Jan 29, 2002Jul 3, 2003Fisher Douglas C.Persistent dynamic payment serviceUS20030158960 *Nov 22, 2002Aug 21, 2003Engberg Stephan J.System and method for establishing a privacy communication pathUS20040019571 *Jul 26, 2002Jan 29, 2004Intel CorporationMobile communication device with electronic token repository and methodUS20040034440 *Aug 14, 2002Feb 19, 2004Richard MiddlebrookGolf handicap and merchandising kioskUS20040128392 *Dec 31, 2002Jul 1, 2004International Business Machines CorporationMethod and system for proof-of-possession operations associated with authentication assertions in a heterogeneous federated environmentUS20040162786 *Feb 13, 2003Aug 19, 2004Cross David B.Digital identity managementUS20050033692 *Apr 8, 2002Feb 10, 2005Jarman Jonathan S.Payment systemUS20050044423 *Sep 16, 2004Feb 24, 2005Mellmer Joseph AndrewManaging digital identity informationUS20050091543 *Jul 3, 2001Apr 28, 2005David HoltzmanSystem and method for establishing and managing relationships between pseudonymous identifications and memberships in organizationsUS20050097550 *Nov 23, 2004May 5, 2005Sun Microsystems, Inc.Token-based linkingUS20050124320 *Dec 8, 2004Jun 9, 2005Johannes ErnstSystem and method for the light-weight management of identity and related informationUS20050135240 *Dec 23, 2003Jun 23, 2005Timucin OzugurPresentity filtering for user preferencesUS20060020679 *Jul 21, 2004Jan 26, 2006International Business Machines CorporationMethod and system for pluggability of federation protocol runtimes for federated user lifecycle managementUS20060136990 *Dec 16, 2004Jun 22, 2006Hinton Heather MSpecializing support for a federation relationshipUS20060155993 *Feb 21, 2003Jul 13, 2006Axel BusboonService provider anonymization in a single sign-on systemUS20070016484 *Jul 12, 2005Jan 18, 2007Waters Timothy MMethod for facilitating authorized online communicationUS20070016943 *May 5, 2006Jan 18, 2007M Raihi DavidToken sharing system and methodUS20070043651 *Aug 15, 2006Feb 22, 2007Quan XiaoMethod and system for grouping merchandise, services and users and for trading merchandise and servicesUS20070061567 *Sep 10, 2006Mar 15, 2007Glen DayDigital information protection systemUS20070118449 *Jun 28, 2006May 24, 2007De La Motte Alain LTrust-linked debit card technologyUS20070143835 *Dec 19, 2005Jun 21, 2007Microsoft CorporationSecurity tokens including displayable claimsUS20070192245 *Apr 22, 2007Aug 16, 2007Fisher Douglas CPersistent Dynamic Payment ServiceUS20070203852 *Feb 24, 2006Aug 30, 2007Microsoft CorporationIdentity information including reputation informationUS20070204168 *Feb 24, 2006Aug 30, 2007Microsoft CorporationIdentity providers in digital identity systemUS20070204325 *Jul 28, 2006Aug 30, 2007Microsoft CorporationPersonal identification information schemasUS20080003977 *Jul 17, 2007Jan 3, 2008Chakiris Phil MDelivery of Value Identifiers Using Short Message Service (SMS)US20080010675 *May 24, 2007Jan 10, 2008Incard S.A.Method for accessing structured data in ic cardsUS20080071808 *Sep 14, 2007Mar 20, 2008Sxip Identity CorporationInternet Identity ManagerUS20080098228 *Jun 27, 2007Apr 24, 2008Anderson Thomas WMethod and apparatus for authentication of session packets for resource and admission control functions (RACF)US20080140576 *Feb 20, 2008Jun 12, 2008Michael LewisMethod and apparatus for evaluating fraud risk in an electronic commerce transactionUS20080141339 *Sep 21, 2007Jun 12, 2008Sap AgMethod and system for authenticationUS20080141366 *Dec 8, 2006Jun 12, 2008Microsoft CorporationReputation-Based Authorization DecisionsUS20080162297 *Dec 30, 2006Jul 3, 2008Sap AgSystems and methods for virtual consignment in an e-commerce marketplaceUS20080178271 *Sep 17, 2007Jul 24, 2008Microsoft CorporationProvisioning of digital identity representationsUS20080178272 *Sep 17, 2007Jul 24, 2008Microsoft CorporationProvisioning of digital identity representationsUS20080184339 *Dec 7, 2007Jul 31, 2008Microsoft CorporationRemote access of digital identitiesUS20080189778 *Feb 5, 2007Aug 7, 2008Peter Andrew RowleySecure authentication in browser redirection authentication schemesUS20080196096 *Feb 5, 2008Aug 14, 2008Amiram GrynbergMethods for Extending a Security Token Based Identity SystemUS20090013391 *Jun 13, 2008Jan 8, 2009Johannes ErnstIdentification System and MethodUS20090037920 *Jul 30, 2007Feb 5, 2009Novell, Inc.System and method for indicating usage of system resources using taskbar graphicsUS20090077118 *Nov 25, 2008Mar 19, 2009Novell, Inc.Information card federation point tracking and managementUS20090077627 *Nov 25, 2008Mar 19, 2009Novell, Inc.Information card federation point tracking and managementUS20090089625 *Aug 4, 2008Apr 2, 2009Lakshmanan KannappanMethod and Apparatus for Multi-Domain Identity Interoperability and certificationUS20090089870 *Sep 27, 2008Apr 2, 2009Mark Frederick WahlSystem and method for validating interactions in an identity metasystemUS20090089871 *Jul 5, 2006Apr 2, 2009Network Engines, Inc.Methods and apparatus for digital data processor instantiationUS20090099860 *Oct 15, 2007Apr 16, 2009Sap AgComposite Application Using Security AnnotationsUS20090125558 *Aug 28, 2008May 14, 2009Korea Smart Card Co., LtdCard authorization terminal system and card management method using the sameUS20090131157 *Jan 23, 2009May 21, 2009IgtMachine having a card processing assemblyUS20090138398 *Oct 27, 2008May 28, 2009Citibank, N.A.Method and system for multi-currency escrow service for web-based transactionsUS20090186701 *Nov 17, 2008Jul 23, 2009Bally Gaming, Inc.Networked Gaming System With Stored Value Cards and MethodUS20090199284 *Feb 6, 2008Aug 6, 2009Novell, Inc.Methods for setting and changing the user credential in information cardsUS20090204622 *Feb 11, 2008Aug 13, 2009Novell, Inc.Visual and non-visual cues for conveying state of information cards, electronic wallets, and keyringsUS20100037303 *Aug 8, 2008Feb 11, 2010Microsoft CorporationForm Filling with Digital Identities, and Automatic Password GenerationUS20110023103 *Nov 13, 2008Jan 27, 2011Frank DietrichMethod for reading attributes from an id tokenUSRE40753 *Aug 30, 2005Jun 16, 2009Wang Tiejun RonaldMethod and system for conducting business in a transnational E-commerce network* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS8073783Aug 22, 2007Dec 6, 2011Felsted Patrick RPerforming a business transaction without disclosing sensitive identity information to a relying partyUS8074257Dec 6, 2011Felsted Patrick RFramework and technology to enable the portability of information cardsUS8079069Dec 13, 2011Oracle International CorporationCardspace history validatorUS8083135Dec 27, 2011Novell, Inc.Information card overlayUS8087060Dec 27, 2011James Mark NormanChaining information card selectorsUS8151324Apr 29, 2008Apr 3, 2012Lloyd Leon BurchRemotable information cardsUS8353002Jan 8, 2013Apple Inc.Chaining information card selectorsUS8364600Feb 28, 2011Jan 29, 2013Apple Inc.Performing a business transaction without disclosing sensitive identity information to a relying partyUS8370913Feb 5, 2013Apple Inc.Policy-based auditing of identity credential disclosure by a secure token serviceUS8479254Aug 22, 2007Jul 2, 2013Apple Inc.Credential categorizationUS8561172Aug 29, 2008Oct 15, 2013Novell Intellectual Property Holdings, Inc.System and method for virtual information cardsUS8632003Jan 27, 2009Jan 21, 2014Novell, Inc.Multiple persona information cardsUS8875997Nov 30, 2011Nov 4, 2014Novell, Inc.Information card overlayUS8914842 *Jan 23, 2012Dec 16, 2014Microsoft CorporationAccessing enterprise resource planning data from a handheld mobile deviceUS20080229383 *Aug 22, 2007Sep 18, 2008Novell, Inc.Credential categorizationUS20080229384 *Aug 22, 2007Sep 18, 2008Novell, Inc.Policy-based auditing of identity credential disclosure by a secure token serviceUS20080229398 *Aug 22, 2007Sep 18, 2008Novell, Inc.Framework and technology to enable the portability of information cardsUS20080229410 *Aug 22, 2007Sep 18, 2008Novell, Inc.Performing a business transaction without disclosing sensitive identity information to a relying partyUS20080229411 *Aug 22, 2007Sep 18, 2008Novell, Inc.Chaining information card selectorsUS20080244729 *Sep 11, 2007Oct 2, 2008Fuji Xerox Co.,LtdInformation processing apparatus, information processing method and computer readable mediumUS20090077118 *Nov 25, 2008Mar 19, 2009Novell, Inc.Information card federation point tracking and managementUS20090077627 *Nov 25, 2008Mar 19, 2009Novell, Inc.Information card federation point tracking and managementUS20090077655 *Jan 24, 2008Mar 19, 2009Novell, Inc.Processing html extensions to enable support of information cards by a relying partyUS20090199284 *Feb 6, 2008Aug 6, 2009Novell, Inc.Methods for setting and changing the user credential in information cardsUS20090204542 *Mar 4, 2008Aug 13, 2009Novell, Inc.Privately sharing relying party reputation with information card selectorsUS20090204622 *Feb 11, 2008Aug 13, 2009Novell, Inc.Visual and non-visual cues for conveying state of information cards, electronic wallets, and keyringsUS20090205035 *Feb 12, 2008Aug 13, 2009Novell, Inc.Info card selector reception of identity provider based data pertaining to info cardsUS20090217368 *Feb 27, 2008Aug 27, 2009Novell, Inc.System and method for secure account reset utilizing information cardsUS20090228885 *Mar 7, 2008Sep 10, 2009Novell, Inc.System and method for using workflows with information cardsUS20090249430 *Mar 25, 2008Oct 1, 2009Novell, Inc.Claim category handlingUS20090272797 *Nov 5, 2009Novell, Inc. A Delaware CorporationDynamic information card renderingUS20100011409 *Jul 9, 2008Jan 14, 2010Novell, Inc.Non-interactive information card token generationUS20100031328 *Feb 4, 2010Novell, Inc.Site-specific credential generation using information cardsUS20100095372 *Oct 9, 2008Apr 15, 2010Novell, Inc.Trusted relying party proxy for information card tokensUS20100176194 *Jul 15, 2010Novell, Inc.Information card overlayUS20100187302 *Jan 27, 2009Jul 29, 2010Novell, Inc.Multiple persona information cardsUS20100251353 *Mar 25, 2009Sep 30, 2010Novell, Inc.User-authorized information card delegationUS20110153499 *Jun 23, 2011Novell, Inc.Performing a business transaction without disclosing sensitive identity information to a relying partyUS20130191878 *Jan 23, 2012Jul 25, 2013Microsoft CorporationAccessing enterprise resource planning data from a handheld mobile deviceWO2014001695A1 *Jun 21, 2013Jan 3, 2014OrangeMethod for authenticating a device for access to a service* Cited by examinerClassifications U.S. Classification726/1, 726/20International ClassificationG06F21/00, H04L9/32Cooperative ClassificationH04L63/102, H04L63/20, G06F21/40, G06F21/35European ClassificationG06F21/35, H04L63/10B, G06F21/40, H04L63/20Legal EventsDateCodeEventDescriptionMar 12, 2009ASAssignmentOwner name: NOVELL, INC., UTAHFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DOMAN, THOMA E.;BUSATH, WENDY MICHELLE;BUSS, DUANE F.;REEL/FRAME:022385/0080Effective date: 20090306Mar 13, 2009ASAssignmentOwner name: NOVELL, INC., UTAHFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE NAME OF ASSIGNOR PREVIOUSLY RECORDED ON REEL 022385 FRAME 0080;ASSIGNORS:DOMAN, THOMAS E.;BUSATH, WENDY MICHELLE;BUSATH, DUANE F.;REEL/FRAME:022396/0547Effective date: 20090306May 23, 2012ASAssignmentOwner name: CREDIT SUISSE AG, AS COLLATERAL AGENT, NEW YORKFree format text: GRANT OF PATENT SECURITY INTEREST SECOND LIEN;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028252/0316Effective date: 20120522Owner name: CREDIT SUISSE AG, AS COLLATERAL AGENT, NEW YORKFree format text: GRANT OF PATENT SECURITY INTEREST FIRST LIEN;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028252/0216Effective date: 20120522Aug 24, 2012ASAssignmentOwner name: CPTN HOLDINGS LLC, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028841/0047Effective date: 20110427Aug 27, 2012ASAssignmentOwner name: APPLE INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CPTN HOLDINGS LLC;REEL/FRAME:028856/0230Effective date: 20120614Nov 24, 2014ASAssignmentOwner name: NOVELL, INC., UTAHFree format text: RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0316;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:034469/0057Effective date: 20141120Owner name: NOVELL, INC., UTAHFree format text: RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0216;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:034470/0680Effective date: 20141120RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services