Abstract: Embodiments provide for detecting viruses and other malware in executing process threads based on thread patterns. According to one embodiment, detecting previously unknown malware associated with process threads can comprise capturing context information for each thread of a plurality of threads executing on a processor. The context information can define a thread pattern for the thread. The thread pattern for each thread can be compared to stored information defining one or more known patterns for thread execution based on previous execution of one or more threads. A thread pattern variation can be detected when the thread pattern for one or more threads does not match the stored information defining the known thread patterns. A determination can be made as to whether the detected thread pattern variation indicates presence of malware and actions can be performed based on determining the detected thread pattern variation indicates the presence of malware.

Abstract: 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.

Abstract: The user can associate metadata with information cards. The metadata can include, among other possibilities, string names, icons, user policies, containers, and hierarchies. The metadata is stored by the computer system. The metadata can then be used to filter the set of information cards that can satisfy a security policy from a relying party.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A relying party can have a security policy. The security policy can include claims that are categorized other than “required” and “optional”. The user can specify, in a user policy, whether or not to include in a request for a security token from an identity provider claims that are not “required”.

Abstract: A system and method for managing information cards using workflows is provided. A workflow manager in a card selector allows the user to initiate cardflows in the card selector. The workflow manager is extensible and programmable so that additional user-defined or industry-defined cardflows can be added to the workflow manager.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.