Abstract: A sub-archive is initiated. The sub-archive saves changes that have occurred since a previous final archive. Changes to an operational database (i.e., the operational database that is being archived) are allowed during the first sub-archive. A final archive is initiated in series after the sub-archive has completed. The final archive does not allow changes to the operational database when the final archive is active. In one embodiment, the sub-archive may comprise a plurality of sub-archives that depend on an amount of outstanding changes that exist in the operational database.

Abstract: A sub-archive is initiated. The sub-archive saves changes that have occurred since a previous final archive. Changes to an operational database (i.e., the operational database that is being archived) are allowed during the first sub-archive. A final archive is initiated in series after the sub-archive has completed. The final archive does not allow changes to the operational database when the final archive is active. In one embodiment, the sub-archive may comprise a plurality of sub-archives that depend on an amount of outstanding changes that exist in the operational database.

Abstract: A sub-archive is initiated. The sub-archive saves changes that have occurred since a previous final archive. Changes to an operational database (i.e., the operational database that is being archived) are allowed during the first sub-archive. A final archive is initiated in series after the sub-archive has completed. The final archive does not allow changes to the operational database when the final archive is active. In one embodiment, the sub-archive may comprise a plurality of sub-archives that depend on an amount of outstanding changes that exist in the operational database.

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

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: An accessor function interfaces among a client, a relying party, and an identity provider. The identity provider can “manage” personal (i.e., self-asserted) information cards on behalf of a user, making the personal information cards available on clients on which the personal information cards are not installed. The client can be an untrusted client, vulnerable to attacks such as key logging, screen capture, and memory interrogation. The accessor function can also asked as a proxy for the relying party in terms of invoking and using the information cards system, for use with legacy relying parties.

Abstract: A machine includes card stores to store information cards. For each card store, one or more card selectors can be provided. When performing a transaction involving information cards, a generic card selector, using a selector policy engine, can identify a card selector to use for the transaction. The identified card selector can be used to identify an information card in a card store to use in performing the transaction, which can be used to provide a security token to the relying party.

Abstract: A machine includes card stores to store information cards. For each card store, one or more card selectors can be provided. When performing a transaction involving information cards, a generic card selector, using a selector policy engine, can identify a card selector to use for the transaction. The identified card selector can be used to identify an information card in a card store to use in performing the transaction, which can be used to provide a security token to the relying party.

Abstract: An accessor function interfaces among a client, a relying party, and an identity provider. The identity provider can “manage” personal (i.e., self-asserted) information cards on behalf of a user, making the personal information cards available on clients on which the personal information cards are not installed. The client can be an untrusted client, vulnerable to attacks such as key logging, screen capture, and memory interrogation. The accessor function can also asked as a proxy for the relying party in terms of invoking and using the information cards system, for use with legacy relying parties.

Abstract: An accessor function interfaces among a client, a relying party, and an identity provider. The identity provider can “manage” personal (i.e., self-asserted) information cards on behalf of a user, making the personal information cards available on clients on which the personal information cards are not installed. The client can be an untrusted client, vulnerable to attacks such as key logging, screen capture, and memory interrogation. The accessor function can also asked as a proxy for the relying party in terms of invoking and using the information cards system, for use with legacy relying parties.

Abstract: A machine includes card stores to store information cards. For each card store, one or more card selectors can be provided. When performing a transaction involving information cards, a generic card selector, using a selector policy engine, can identify a card selector to use for the transaction. The identified card selector can be used to identify an information card in a card store to use in performing the transaction, which can be used to provide a security token to the relying party.

Abstract: A machine includes card stores to store information cards. For each card store, one or more card selectors can be provided. When performing a transaction involving information cards, a generic card selector, using a selector policy engine, can identify a card selector to use for the transaction. The identified card selector can be used to identify an information card in a card store to use in performing the transaction, which can be used to provide a security token to the relying party.

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

Abstract: When a user connects a pluggable card store to a machine, the machine plugs a pluggable card provider into a card provider registry. The pluggable card store can be an object portable to the user, or can be a remote store available via some connection, such as an FTP connection. The user can then use the information cards stored on the pluggable card store in a transaction.

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

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: An apparatus can include a secret mapping module running on a machine and configured to create a mapping that maps a secret to a claim stored in an information card, a receiver running on the machine and configured to receive a request for the secret from a remote application, a mapping query module running on the machine and configured to perform a search for the mapping, a credential provider application running on the machine and configured to retrieve the secret based at least in part on the claim, and a transmitter configured to transmit the secret to the remote application.