Patent application number | Description | Published |
20080229384 | POLICY-BASED AUDITING OF IDENTITY CREDENTIAL DISCLOSURE BY A SECURE TOKEN SERVICE - A user defines an audit policy. The audit policy identifies one or more triggers that, when related information is included in a security token, trigger the performance of the audit. The audit can include notifying the user in some manner that the trigger occurred. The audit can require in-line confirmation of the audit, so that the security token is not transmitted until the user confirms the audit. | 09-18-2008 |
20080229410 | PERFORMING A BUSINESS TRANSACTION WITHOUT DISCLOSING SENSITIVE IDENTITY INFORMATION TO A RELYING PARTY - A user engages in a transaction with a relying party. The relying party requests identity information from the user in a security policy and identifies transaction elements for an on-line business transaction. Typically, the security policy and transaction elements are transmitted together; the security policy can be as little as a request to conduct the on-line business transaction. The user identifies an information card that satisfies the security policy. The computer system requests a security token from the identity provider managing the information card, which can include requesting a transaction receipt for the transaction elements. The computer system then returns the security token (and the transaction receipt) to the relying party, to complete the transaction. | 09-18-2008 |
20090077118 | INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT - A client can store information about federation points. A federation point is a combination of an identifier of an account on a relying party and an identifier of an information card. The client can track which information cards are included n various federation points, and can use this information to assist the user in performing a transaction with relying parties. | 03-19-2009 |
20090077627 | INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT - A client can store information about federation points. A federation point is a combination of an identifier of an account on a relying party and an identifier of an information card. The client can track which information cards are included n various federation points, and can use this information to assist the user in performing a transaction with relying parties. | 03-19-2009 |
20090178112 | LEVEL OF SERVICE DESCRIPTORS - An 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 can generate a query based on the selected information card, wherein the query pertains to information about features that are available on a relying party based on the security token and independent of a user's identity. The transmitter can transmit the generated query and the security token to an endpoint on the relying party. | 07-09-2009 |
20090204542 | PRIVATELY SHARING RELYING PARTY REPUTATION WITH INFORMATION CARD SELECTORS - A computer system accesses reputation information about a relying party. The reputation information can be stored locally or remotely (for example, at an identity provider or reputation service). A reputation information engine can be used to provide the reputation information to the user. The user can then use the reputation information in performing a transaction with the relying party. | 08-13-2009 |
20090204622 | VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS - A user desires to select information about himself. The system uses policies applicable to the display of the user's information and metadata about the user and the information to determine modified presentations of the user's information. The modified information can include visual and non-visual cues (such as aural, olfactory, or tactile). The system then displays the modified information, presenting the user with the visual and non-visual cues about the information. | 08-13-2009 |
20090205014 | SYSTEM AND METHOD FOR APPLICATION-INTEGRATED INFORMATION CARD SELECTION - A selector daemon can run in the background of a computer. Applications that are capable of processing information cards directly, without requiring the use of a card selector, can request the selector daemon to list information cards that satisfy security policy. Upon receiving such a request, selector daemon can determine the information cards available on the computer that satisfy the security policy, and can identify these information cards to the requesting application. The applications can then use the identified information cards in any manner desired, without having to use a card selector: for example, by requesting a security token based on one of the information cards directly from an identity provider. | 08-13-2009 |
20090205035 | INFO CARD SELECTOR RECEPTION OF IDENTITY PROVIDER BASED DATA PERTAINING TO INFO CARDS - A computer system accesses metadata about an information card. The metadata can be stored locally or remotely (for example, at an identity provider). A metadata engine can be used to generate data to be provided to the user from the metadata: this data can take any desired form, such as an advertisement, a state of the user's account, or a policy update, among other possibilities. | 08-13-2009 |
20090217368 | SYSTEM AND METHOD FOR SECURE ACCOUNT RESET UTILIZING INFORMATION CARDS - New claim identifiers allow account reset and supplemental authorizations to be performed utilizing information cards. The new claim identifiers include claims for simple challenge questions, simple challenge answers, generated-challenge answers, and challenge methods. Each of the new claims can include a tuple. Methods of utilizing the new claim identifiers for account reset and supplemental authorization are also provided. | 08-27-2009 |
20090271856 | RESTRICTED USE INFORMATION CARDS - A system and method for utilizing restricted user information cards is provided. An identity provider issues a restricted use information card responsive to a relying party's restricted use policy. The identity provider can issue security tokens associated with the restricted use information card that include a unique-id claim. A broker can act as an intermediary between a user and the relying party to protect the user's personal information but still uniquely identity the user to the relying party. The relying party, the identity provider, or the broker can be responsible for enforcing the restricted use policy. | 10-29-2009 |
20090272797 | DYNAMIC INFORMATION CARD RENDERING - A system and method for dynamic rendering of information cards is provided. A card selector uses policies and rendering content to modify the presentation of information cards in the card selector. The policies and rendering content can be obtained from identity providers and relying parties. The rendering content can be obtained each time the card selector is invoked, just prior to rendering the information cards, or at other times specified in the policy. The rendering content can be displayed in a display area of the information card or in a content canvas outside the display area of the information card. | 11-05-2009 |
20100187302 | MULTIPLE PERSONA INFORMATION CARDS - A computer-implemented method can include selecting an information card from a group of identified information cards, selecting a persona from a group of identified personae that are associated with the selected information card, and generating a Request for Security Token (RST) based on the selected information card and the selected persona. | 07-29-2010 |
20110153499 | PERFORMING A BUSINESS TRANSACTION WITHOUT DISCLOSING SENSITIVE IDENTITY INFORMATION TO A RELYING PARTY - A user engages in a transaction with a relying party. The relying party requests identity information from the user in a security policy and identifies transaction elements for an on-line business transaction. Typically, the security policy and transaction elements are transmitted together; the security policy can be as little as a request to conduct the on-line business transaction. The user identifies an information card that satisfies the security policy. The computer system requests a security token from the identity provider managing the information card, which can include requesting a transaction receipt for the transaction elements. The computer system then returns the security token (and the transaction receipt) to the relying party, to complete the transaction. | 06-23-2011 |
20130014207 | POLICY-BASED AUDITING OF IDENTITY CREDENTIAL DISCLOSURE BY A SECURE TOKEN SERVICE - A user defines an audit policy. The audit policy identifies one or more triggers that, when related information is included in a security token, trigger the performance of the audit. The audit can include notifying the user in some manner that the trigger occurred. The audit can require in-line confirmation of the audit, so that the security token is not transmitted until the user confirms the audit. | 01-10-2013 |
20130018984 | INFORMATION CARD FEDERATION POINT TRACKING AND MANAGEMENT - A client can store information about federation points. A federation point is a combination of an identifier of an account on a relying party and an identifier of an information card. The client can track which information cards are included n various federation points, and can use this information to assist the user in performing a transaction with relying parties. | 01-17-2013 |
20130024908 | SYSTEM AND METHOD FOR APPLICATION-INTEGRATED INFORMATION CARD SELECTION - A selector daemon can run in the background of a computer. Applications that are capable of processing information cards directly, without requiring the use of a card selector, can request the selector daemon to list information cards that satisfy security policy. Upon receiving such a request, selector daemon can determine the information cards available on the computer that satisfy the security policy, and can identify these information cards to the requesting application. The applications can then use the identified information cards in any manner desired, without having to use a card selector: for example, by requesting a security token based on one of the information cards directly from an identity provider. | 01-24-2013 |