Credential categorization

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.

Description

FIELD OF THE INVENTION

This invention pertains to performing on-line transactions, and more particularly to managing information cards used in performing on-line transactions.

BACKGROUND OF THE INVENTION

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.

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.

But even with new systems such as Microsoft Windows CardSpace, the concern exists that information cards can increase in numbers to levels difficult to manage. A single card store might include any number of cards that could be accepted by a single relying party—for example, if the card store is shared among a number of users, as might occur on a family computer. In addition, a single user might have a number of information cards, issued by different issuers—such as federal and state agencies and private organizations (e.g., Visa)—all of which could be accepted by any number of different relying parties.

A need remains for a way to provide users with the ability to manage their information cards in accordance with user preferences that addresses these and other problems associated with the prior art.

SUMMARY OF THE INVENTION

In an embodiment of the invention, a machine stores at least one information card. Associated with the information card is metadata. This metadata can be used to manage the information cards stored on the machine.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a sequence of communications between a client, a relying party, and an identity provider.

FIG. 2 shows a system designed to provide the ability to manage information cards, according to an embodiment of the invention.

FIG. 3 shows examples of different types of metadata that can be associated with an information card in the system of FIG. 2.

FIG. 4 shows a graphic display for use in managing information cards in the system of FIG. 2.

FIG. 5 shows a flowchart of a procedure for associating metadata with an information card in the system of FIG. 2.

FIG. 6 shows a flowchart of different procedures for associating particular types of metadata with an information card in the system of FIG. 2.

FIGS. 7A-7B show a flowchart of a procedure for managing information cards in the system of FIG. 2.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Before explaining the invention, it is important to understand the context of the invention. FIG. 1 shows a sequence of communications between a client, a relying party, and an identity provider. For simplicity, each party (the client, the relying party, and the identity provider) may be referred to by their machines. Actions attributed to each party are taken by that party's machine, except where the context indicates the actions are taken by the actual party.

In FIG. 1, computer system 105, the client, is shown as including computer 110, monitor 115, keyboard 120, and mouse 125. A person skilled in the art will recognize that other components can be included with computer system 105: for example, other input/output devices, such as a printer. In addition, FIG. 1 does not show some of the conventional internal components of computer system 105; for example, a central processing unit, memory, storage, etc. Although not shown in FIG. 1, a person skilled in the art will recognize that computer system 105 can interact with other computer systems, such as relying party 130 and identity provider 135, either directly or over a network (not shown) of any type. Finally, although FIG. 1 shows computer system 105 as a conventional desktop computer, a person skilled in the art will recognize that computer system 105 can be any type of machine or computing device capable of providing the services attributed herein to computer system 105, including, for example, a laptop computer, a personal digital assistant (PDA), or a cellular telephone.

Relying party 130 is a machine managed by a party that relies in some way on the identity of the user of computer system 105. The operator of relying party 130 can be any type of relying party. For example, the operator of relying party 130 can be a merchant running a business on a website. Or, the operator of relying party 130 can be an entity that offers assistance on some matter to registered parties. Relying party 130 is so named because it relies on establishing some identifying information about the user.

Identity provider 135, on the other hand, is managed by a party responsible for providing identity information (or other such information) about the user for consumption by the relying party. Depending on the type of information identity provider 135 stores for a user, a single user might store identifying information with a number of different identity providers 135, any of which might be able to satisfy the request of the relying party. For example, identity provider 135 might be a governmental agency, responsible for storing information generated by the government, such as a driver's license number or a social security number. Or, identity provider 135 might be a third party that is in the business of managing identity information on behalf of users.

The conventional methodology of releasing identity information can be found in a number of sources. One such source is Microsoft Corporation, which has published a document entitled Introducing Windows CardSpace, which can be found on the World Wide Web at http://msdn2.microsoft.com/en-us/library/aa480189.aspx and is hereby incorporated by reference. To summarize the operation of Windows CardSpace, when a user wants to access some data from relying party 130, computer system 105 requests the security policy of relying party 130, as shown in communication 140, which is returned in communication 145 as security policy 150. Security policy 150 is a summary of the information relying party 130 needs, how the information should be formatted, and so on.

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 username and password combination, the information cards that will satisfy this security policy will 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.

Once the user has selected an acceptable information card, computer system 105 uses the selected information card to transmit a request for a security token from identity provider 135, as shown in communication 155. This request can identify the data to be included in the security token, the credential that identifies the user, and other data the identity provider needs to generate the security token. Identity provider 135 returns security token 160, as shown in communication 165. Security token 160 includes a number of claims, or pieces of information, that include the data the user wants to release to the relying party. Security token 160 is usually encrypted in some manner, and perhaps signed and/or time-stamped by identity provider 135, so that relying party 130 can be certain that the security token originated with identity provider 135 (as opposed to being spoofed by someone intent on defrauding relying party 130). Computer system 105 then forwards security token 160 to relying party 130, as shown in communication 170.

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.

In this model, a person skilled in the art will recognize that because all information flows through computer system 105, the user has a measure of control over the release of the user's identity information. Relying party 130 only receives the information the user wants relying party 130 to have, and does not store that information on behalf of the user (although it would be possible for relying party 130 to store the information in security token 160: there is no effective way to prevent such an act).

The problem with this model is, as noted above, that the system identifies all information card(s) that can be used to satisfy the needs of the relying party. Even with computer system 105 identifying only information cards that satisfy security policy 150, there might be still be a large number of information cards to consider.

This problem exists even for a single user: as discussed above, a user might have a number of information cards issued by federal or state agencies and private organizations, many of which might satisfy security policy 150. Thus, the user would need to select which information card to use in dealings with relying party 130. This problem can be compounded when the user has multiple identities—not in the sense of fraudulent identities, but in the sense of different mindsets. For example, a user might have some information cards used when the user is working, another set of information cards for personal use, a third set of information cards for use when gaming, and so on.

The picture can get even more complicated when multiple users use the same computer. For example, if a family shares a computer, all the information cards can be stored in a single card store. Because parents might want to have some control over their children's activities, parents may want to be able to review their children's information cards. Or parents might want to be able to apply policies to limit their children's use of their information cards.

Another situation in which information card management becomes more complicated occurs where one user needs to proxy for another user. For example, an administrator might need to be able to act on behalf of a user. Or a financial planner might need to be able to act on behalf of client (for example, to electronically file a tax return). In these situations, being able to manage information cards can simplify the use of information cards.

Now that the problem—managing information cards—is understood, a solution to the problem can be explained. FIG. 2 shows a system to manage information cards on computer system 105, according to an embodiment of the invention. In FIG. 2, computer system 105 includes card selector 205, receiver 210, and transmitter 215. Card selector 205 is responsible for enabling a user to select information card 220 that satisfies the security policy. Receiver 210 is responsible for receiving data transmitted to computer system 105, and transmitter 215 is responsible for transmitting information from computer system 105. These components are the same as those found in computer system 105 as shown in FIG. 1.

To manage the information cards, card selector 205 includes filter selector 225. Filter selector 225 can be used to select filters to be used in identifying information cards that can be used in satisfying the security policy from the relying party. Filter selector 225 offers the user the ability to select any desired filter. Examples of filters that can be used are discussed below with reference to FIGS. 3-4.

FIG. 3 shows examples of different types of metadata that can be associated with an information card in the system of FIG. 2. In FIG. 3, information card 215 is shown. Assigned to information card 215 are a number of different types of metadata. String name 305 is a string that the user can assign to the information card. The user can then search for information cards with the associated string as a filter. The user can associate any desired strings (one or many) with a particular information card, and can associate the same string with multiple information cards.

Icon 310 is an iconic representation that can be associated with information card 215. In FIG. 3, icon 310 is a representation of a house, which can mean that the associated information card is used primarily used for personal reasons. Icons can be used to represent any desired filter: for example, work, personal, gaming, child, parent, financial, etc. Icons can be selected from a pre-defined set of graphics, or the user can add custom icons, either drawn from another location or newly created. The user can then specify a name to be associated with the icon, if desired: this information can be used to help remind the user of the icon's purpose. The user can then filter information cards based on the associated icons. A person skilled in the art will recognize that there can be any number of icons associated with a particular information card, and that the same icon can be associated with any number of information cards.

Policy 315 represents a policy that limits the use of the associated information card. Any desired policy can be used, without limitation. For example, policy 315 specifies a time range during which information card 215 is available. Policy 315 indicates that information card 215 is available between 5:00 PM and 10:00 PM. Such a policy might be applied by a parent to an information card used by a child (for example, to authenticate the child to their MySpace account). While policy 315 specifies just a time range, a person skilled in the art will recognize that policy 315 can be more complicated, if desired. For example, policy 315 could specify different time ranges for different days (for example, prohibiting use of information card 215 after 8:00 PM on weeknights, but permitting the child to use information card 215 during most hours of the weekend). Or policy 315 could permit use of information card 215 on certain days at all hours, but deny use of information card 215 on other days.

A person skilled in the art will also recognize that policy 315 can be defined specifically for information card 215, or it can be defined in the abstract and then specifically associated with information card 215. For example, a data structure can store the policy (in FIG. 3, limiting use of information card 215 to the hours of 5:00 PM and 10:00 PM); the data structure can then be associated with information card 215 and any other information cards, as desired. Examples of how policies can be defined and stored are described in co-pending U.S. patent application Ser. No. 11/768,755, filed Jun. 26, 2007, and co-pending U.S. patent application Ser. No. 12/323,177, filed Nov. 25, 2008, which are incorporated by reference herein. While co-pending U.S. patent application Ser. No. 11/768,755, filed Jun. 26, 2007, describes policies that can be used in authorizing access to resources, a person skilled in the art will recognize that information card 215 can be considered a form of resource, and policy 315 can be a control on the authorized use of information card 215.

Between co-pending U.S. patent application Ser. No. 11/768,755, filed Jun. 26, 2007, and co-pending U.S. patent application Ser. No. 12/323,177, filed Nov. 25, 2008, a person skilled in the art will recognize numerous different forms policy 315 can take. For example, policy 315 might specify that before a user is permitted to use information card 215, such use must be confirmed by a third party: a parent might want to know each time a child logs into his or her MySpace account, In that case, policy 315 would specify that the parent needs to be informed in-line of the attempt to log in and provide authorization before login is completed. This is similar to the audit capability described in co-pending U.S. patent application Ser. No. 12/323,177, filed Nov. 25, 2008, but interposes the in-line audit capability before the information card can even be selected (an earlier point in the process than the audit capability).

As discussed above, a person can associate the same policy with multiple information cards. The user can also associate multiple policies with an individual information card. For example, a user might choose to establish one policy that applies to an information card during working hours, and another policy that applies to an information card during off hours. If the policies are identified in some manner (e.g., by names or some other description), the user can filter information cards based on policies.

Container 320 identifies a container with which information card 215 is associated. Information cards, like any other object in the computer system, can be stored somewhere on some storage of the computer system. The storage itself can be any desired form of storage: for example, a hard drive, a floppy disk, an optical disc (such as a compact disc (CD) or digital video disc (DVD)), flash memory, among other possibilities.

As with most computer systems, containers can be organized in a container hierarchy. Container hierarchy 325 is an example of such a container hierarchy. Different containers can be used to organize the contents of the folders. For example, in the Microsoft Windows operating system, a folder named Windows is often used to store the files that make up the operating system, using subfolders to store various components of the operating system. In a similar manner, container hierarchy 325 can be used to organize information cards into different containers. The user can select a particular container in which to store a particular information card. In FIG. 3, the user has associated information card 215 with container 330, as shown by container 320. The user could instead have chosen to associate information card 215 with any of containers 335, 340, or 345.

In the above description, the terms “folder” and “container” are both used. In this specification, a folder can be a form of container. But a person skilled in the art will recognize that containers can be structured in forms other than folders, if desired.

Although FIG. 3 suggests that an information card can be associated with only one container, embodiments of the invention are not so limited. A single information card can be associated with any number of containers, if desired. One way to achieve this would be to store the information card in one container and then link that information card into other containers, but a person skilled in the art will recognize other ways in which an information card can be associated with multiple containers.

One reason to use containers is to take advantage of containers that nest. For example, in container hierarchy 325, container 345 is nested within container 330 and containers 330 and 340 are both nested within container 335. (This has the added implication that container 345 is also nested within container 335.) Nesting containers does not mean that the contents of the nested container are directly stored within the outer container, but the contents can be considered part of the “hierarchy” of that outer container. For example, an object stored in container 340 is not in the hierarchy starting at container 330, but an object stored in container 345 is in the hierarchy of container 330. As a result, using a container as a filter enables locating not only objects stored directly in that container, but also objects nested within the container. For example, using container 330 as a filter would identify information card 215 based on its association with container 330, but could also identify information cards associated with container 345. (Whether a filter based on a container also identifies information cards associated with sub-containers can be an option that the user can control.)

Finally, hierarchy 350 enables filtering based on fields in the information cards. For example, identity provider 135, which stores the details (that is, the actual data) about information card 215, can store information card 215 in a hierarchical storage. The hierarchy used to store information card 215 can be used to filter information cards, in a manner similar to the containers in container hierarchy 325. But whereas container hierarchy 325 is stored on the user's computer system, hierarchy 350 is stored on identity provider 135 (or some other system separate from the user's computer system). Any folder in the hierarchy can be used to filter information cards, and as with container hierarchy 325, the selected folder can filter just information cards stored in that folder, or the selected folder can filter all information cards stored or nested in that container.

As mentioned above, in FIG. 3 one of each type of metadata is shown as associated with information card 215. A person skilled in the art will recognize that any number of each type of metadata can be associated with an individual information card, including zero. Thus, an information card might have three string names associated with it, one container associated with it, and no icons, policies, or hierarchies.

FIG. 4 shows a graphic display for use in managing information cards in the system of FIG. 2. In FIG. 4, display 405 is shown. In the main part 410 of display 405, the information cards can be displayed. Surrounding main part 410 are various filter options the user can use. Search field 415 enables a user to input a search string—in FIG. 4, the entered search string is “Gaming”. Search field 415 enables filtering based on string names.

Icon section 420 provide the user with options to filter based on icons. In FIG. 4, icon section 420 only shows a single icon, but as discussed above with reference to FIG. 3, if the user has used more than one icon, the available filter icons can be shown in icon section 420. (Alternatively, all icons can be shown in icon section 420, even if not used; in that situation, the unused icons can be grayed out, so that the user is aware as to which icons would make a difference to the results).

One alternative shown to using icon section 420 is to display the icons directly on the information cards, as shown by icon 425 on information card 215. While this embodiment is shown only with reference to icons, a person skilled in the art will recognize that the other filter options can also be displayed directly on the information cards. A person skilled in the art will also recognize that where filter options are displayed directly on the information cards, the corresponding filter option sections can be removed from display 405, if desired.

Policy section 430 enables the user to filter based on policies. As with icon section 420, only policies that would affect the filtering results can be shown, or all policies can be included with unused policies grayed out, among other possibilities.

Container section 435 enables the user to filter based on containers. As with icon section 420 and policy section 430, only containers that would affect the filtering results can be shown, or all containers can be included with unused containers grayed out, among other possibilities. For example, if information cards are only associated with one container and the user opts to filter based on container 2, the entry for container 1 would not affect the results, so that entry could be grayed out. But if information cards can be associated with multiple containers, then there might be an information card associated with both containers 1 and 2, and so the user's selecting container 2 would not necessarily mean that selecting container 1 would make no difference.

Hierarchy section 440 enables the user to filter based on hierarchy information. As discussed above with FIG. 3, the hierarchy can depend on where the actual data for the information card is stored. Hierarchy section 440 can operate in a manner similar to that of icon section 420, policy section 430, and container section 435, in that hierarchy selections that would not make a difference can be removed or grayed out, as desired.

The various filter options (search field 415, icon section 420, policies section 430, container section 435, and hierarchy section 440) can be combined in any manner desired. For example, the filter options can be combined disjunctively (where an information card that satisfies any of the filter options is included) or conjunctively (where an information card that satisfies all of the filter options is included). FIG. 4 does not show the user being able to control whether filter options combine disjunctively or conjunctively, but a person skilled in the art will recognize how this functionality can be added. In addition, other filter options can be added if desired. For example, display 405 could include a “No Filters” button, which could be used to remove all enabled filters responsive to a single action by a user. A person skilled in the art will recognize other ways in which filter options can be modified.

Once the user has identified the filter options, main part 410 displays or otherwise identifies the information cards that satisfy the filter options. For example, information card 215 meets the filter options, and so is shown in main part 410 of display 405. In contrast, information card 445 does not meet the filter options, and so can be grayed out (shown by the dashed line to information card 445). A person skilled in the art will also recognize that information card 445, as not meeting the filter options, can simply be omitted from main part 410.

While FIG. 4 suggests that filters can be applied, perhaps at different times, a person skilled in the art will also recognize that filters can be “unapplied”: that is, removed. For example, if the user decides that search filter for the term “gaming” does not help identify the desired information card, the user can remove that filter option, thereby broadening the filter. In a similar manner, the other filter sections can be applied and “unapplied” as desired.

FIG. 5 shows a flowchart of a procedure for associating metadata with an information card in the system of FIG. 2. At block 505, the user identifies an information card. At block 510, the user identifies metadata, which is associated with the information card. At block 515, the metadata is stored, associated with the information card.

FIG. 6 shows a flowchart of different procedures for associating particular types of metadata with an information card in the system of FIG. 2. At block 605, the system can associate a string name, an icon, or a policy with the information card. At block 610, the system can associate a container with the information card. And at block 615, the system can associate a hierarchy with the information card.

FIGS. 7A-7B show a flowchart of a procedure for managing information cards in the system of FIG. 2. In FIG. 7A, at block 705, the system receives a security policy from a relying party. At block 710, the system identifies information cards that satisfy the security policy. At block 715, the system presents to the user an initial list of information cards that satisfy the security policy. At block 720, the system presents to the user the available filters. As discussed above with reference to FIG. 4, the available filters might be limited to just filters that can affect the list of available information cards, or the available filters can include all filters.

At block 725 (FIG. 7B), the system determines the user's choice of action. If the user has opted to change the filter options (either by narrowing or broadening the filter), then at block 730, the system receives from the user the selected filter change. At block 735, the system updates the list of information cards to those that also satisfy the selected filter. This can also include updating the available filters, as discussed above with reference to FIG. 4. Control then returns to block 725.

If the user selects an information card, then at block 740, the system receives the user's card selection, and at block 745, the system uses the selected information card in satisfying the relying party's security policy.

The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention may 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 may 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.

The machine may 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 may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may 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 may 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.

The invention may 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 may 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, etc. Associated data may 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 may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.

Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles, and may 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 may reference the same or different embodiments that are combinable into other embodiments.

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 may come within the scope and spirit of the following claims and equivalents thereto.

Claims

1. An apparatus to manage information cards, comprising: a computer;storage on the computer;at least one information card stored in the storage on the computer;metadata associated with the at least one information card that is stored in the storage on the computer, the metadata specified by a user;a card selector operative to identify the at least one information card as satisfying a security policy; anda filter selector to allow the user to select a user-specified filter for the at least one information card, the user-specified filter using the metadata associated with the at least one information card; wherein the filter selector reduces the number of information cards that satisfy the security policy displayed to the user;wherein the card selector is operative to identify the at least one information card as satisfying both the security policy and the user-specified filter;wherein metadata associated to the information card includes metadata associating the information card with at least one of a plurality of identifiers of a plurality of containers.

2. An apparatus according to claim 1, wherein the metadata includes at least one item drawn from a set including a string name, an icon, and a user policy to the information card.

3. An apparatus according to claim 1, wherein the metadata includes at least one of a plurality of identifiers of a plurality of containers.

4. An apparatus according to claim 1, wherein the metadata includes a hierarchy of information cards.

5. An apparatus according to claim 1, wherein the card selector is operative to enable the user to select the at least one information card satisfying the security policy and the user-specified filter.

6. A method for managing information cards, comprising: identifying an information card;associating metadata to the information card stored on a computer;storing the metadata associated with the information card;receiving a security policy from the relying party;receiving from a user a user-specified filter using the metadata associated with the information card; wherein the user-specified filter reduces the number of information cards displayed to the user;selecting the information card for display to the user when the information card satisfies the security policy 4404 and the user-specified filter; andpresenting to the user the information cards that satisfy both the security policy and the user-specified filter;wherein associating metadata to the information card includes associating the information card with at least one of a plurality of identifiers of a plurality of containers.

7. A method according to claim 6, further comprising: receiving from the user a selected information card that satisfies both the security policy and the user-specified filter; andusing the selected information card to provide a security token to the relying party responsive to the security policy.

8. A method according to claim 6, wherein receiving from a user a user-specified filter includes presenting the user a graphic display of available user-specified filters.

9. A method according to claim 8, wherein receiving from a user a user-specified filter further includes receiving from the user an indication of one the available user-specified filters.

10. A method according to claim 6, wherein: the method further comprises presenting to the user a list of information cards satisfying the security policy; andreceiving from a user a user-specified filter further includes updating the list of information cards presented to the user to include information cards satisfying both the security policy and the identified user-specified filter

11. A method according to claim 8, wherein presenting to the user a graphic display of available user-specified filters includes displaying an icon for the user-specified filter with the information card.

12. A method according to claim 6, wherein associating metadata to the information card includes associating at least one item from a set including a string name an icon and a user policy to the information card.

13. A method according to claim 6, wherein associating metadata to the information card includes identifying a location for the information card in a hierarchy of information cards.

14. An article, comprising a non-transitory storage medium, said non-transitory storage medium having stored thereon instructions that, when executed by a machine, result in: identifying an information card;associating metadata to the information card;storing the metadata associated with the information card;receiving a security policy from the relying party;receiving from a user a user-specified filter using the metadata associated with the information card wherein the user-specified filter reduces the number of information cards displayed to the user;selecting the information card for display to the user when the information card satisfies the security policy and the user-specified filter; andpresenting to the user the information cards that satisfy both the security policy and the user-specified filter;wherein associating metadata to the information card includes associating the information card with at least one of a plurality of identifiers of a plurality of containers.

15. An article according to claim 14, wherein said non-transitory storage medium has stored thereon further instructions that, when executed by said machine, result in: receiving from the user a selected information card that satisfies both the security policy and the user-specified filter; andusing the selected information card to provide a security token to the relying party responsive to the security policy.

16. An article according to claim 14, wherein receiving from a user a user-specified filter includes presenting to the user a graphic display of available user-specified filters.

17. An article according to claim 16, wherein receiving from a user a user-specified filter further includes receiving from the user an indication of one the available user-specified filters.

18. An article according to claim 14, wherein: the method further comprises presenting to the user a list of information cards satisfying the security policy; andreceiving from a user a user-specified filter further includes updating the list of information cards presented to the user to include information cards satisfying both the security policy and the identified user-specified filter.

19. An article according to claim 16, wherein presenting to the user a graphic display of available user-specified filters includes displaying an icon for the user-specified filter with the information card.

20. An article according to claim 14, wherein associating metadata to the information card includes associating at least one item from a set including a string name, an icon, and a user policy to the information card.

21. An article according to claim 14, wherein associating metadata to the information card includes associating the information card with at least one of a plurality of identifiers of a plurality of containers.

22. An article according to claim 14, wherein associating metadata to the information card includes identifying a location for the information card in a hierarchy of information cards.

23. An apparatus according to claim 4, wherein the hierarchy of information cards is stored remote from the computer.

24. A method according to claim 13, wherein identifying a location for the information card in a hierarchy of information cards includes identifying the location for the information card in the hierarchy of information cards, the hierarchy of information cards stored remote from the computer.

25. An article according to claim 22, wherein identifying a location for the information card in a hierarchy of information cards includes identifying the location for the information card in the hierarchy of information cards, the hierarchy of information cards stored remote from the computer.

26. An apparatus according to claim 2, wherein the metadata does not include data that can be included as a claim in a security token.

27. A method according to claim 12, wherein associating metadata to the information card includes associating metadata to the information card, where the metadata does not include data that can be included as a claim in a security token.

28. An article according to claim 20, wherein associating metadata to the information card includes associating metadata to the information card, where the metadata does not include data that can be included as a claim in a security token.

29. An apparatus according to claim 3, wherein the plurality of container are stored on the computer.

30. A method according to claim 6, wherein associating metadata to the information card further includes storing the information card in a container identified by the at least one of a plurality of identifiers.

31. An article according to claim 21, wherein associating metadata to the information card further includes storing the information card in a container identified by the at least one of a plurality of identifiers.