I-Card

An i-card is a rectangular icon displayed in the user interface of an identity selector (sometimes also called an identity agent) that represents a digital identity--a set of claims about some entity (typically a person, but it could also be an organization, application, service, digital object, etc.).

The i-card metaphor is based on familiar physical identity credentials like business cards, credit cards, library cards, association cards, driver's licenses, badges, etc. However, just as computer file folders are similar to but more powerful than real-world file folders, i-cards are similar to but more powerful than real-world identification cards. The i-card metaphor is identical to the information card metaphor used in numerous identity selectors.

History of the Terms "i-card" and "information card"

The term information card was introduced by Microsoft in May 2005 as a name for the visual information card metaphor to be introduced in its forthcoming Windows CardSpace software. Until early 2006, information cards were also sometimes referred to by the code-name “InfoCard”, which was not a name that was freely available for all to use. The name information card was specifically chosen as one that would be freely available for all to use, independent of any product or implementation. The name “information card” is not trademarked and is so generic as to not be trademarkable.

The term i-card was introduced at the June 21, 2006 Berkman/MIT Identity Mashup conference (see [http://wiki.idmashup.org/I-cards meeting notes] and [http://www.equalsdrummond.name/?p=72 Drummond Reed's blog post] ). The intent was to define a term that was not associated with any industry TM or other IP or artifact. At the time, Microsoft had not yet finished applying the [http://www.microsoft.com/interop/osp/ Open Specification Promise] to the protocols underlying Windows CardSpace and there was also a misunderstanding that the term information card was not freely available for use by all, so to be conservative, the term i-card was introduced.

Mike Jones, of Microsoft, explained to participants of a session at [http://iiw.idcommons.net/index.php/Iiw2007b IIW 2007b] that Microsoft always intended the term information card to be used generically to describe all kinds of information cards and to be freely usable by all, and tried to correct the earlier misunderstanding that the term might apply only to the kinds of information cards originally defined by Microsoft. He made the case that the industry would be better served by having everyone use the common term information card, than having two terms in use with the same meaning, since there remains no legal or technical reason for different terms. In this case the term i-card would become just the short form of information card, just like e-mail has become the short form of electronic mail.

Generic Qualities

* I-cards are created by an entity known as a "issuer".
* I-cards display the name of the issuer ("issuerName") in a text string.
* I-cards have a text string to identify the card ("cardName") that is initially set by the card issuer. Typically this card name is user-editable.
* I-cards may have a (GIF or JPEG) background image ("cardImage") set by the card issuer (user-editable).
* In most i-cards the user is able to see the value of the claims.

Kinds of Cards

Just as there are many kinds of physical cards such as business cards for contact data, credit cards for payment, library cards for library access, driver's licenses for motor vehicle privileges, etc.), there are many kinds of I-Cards. They can be grouped into three broad categories:; Managed: A managed card (m-card) allows an Identity Provider (other than yourself) to make claims about you to sites. A managed card is issued by this Identity Provider.; Personal: A personal card (p-card) allows you to make claims about yourself to sites. Personal cards are issued by you and as such are sometimes called self-issued cards.; Relationship: A relationship card (r-card) is one in which: a) two or more parties make claims, and b) the card may instantiate an ongoing data sharing relationship between the parties, much like a social networking link. Like a managed card, an r-card has a set of "supported" claims from a third-party identity provider makes, and for which they are authoritative. But unlike managed cards, a relationship card also exposes a second set of claims that are made by you or others that you delegate. Like a Personal card, you control the values of these claims.

Managed Cards

ISIP-M-Card

The first kind of managed card was introduced as part of Microsoft’s Windows CardSpace software in November 2006. The behavior, file format and interoperability characteristics of these kinds of managed cards are defined by Microsoft documents such as the [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf Identity Selector Interoperability Profile (pdf)] (see [http://self-issued.info/?p=8 here] for a more complete list), in combination with open standards including [http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf WS-Trust] and others.

Summary of characteristics:
* "Data format:" an XML file containing: network endpoint of the STS, set of claim type URIs, name of the card, "cardImage", "issuerName", a unique cardID, etc. The XML file format is defined in the ISIP documents.
* "Issuer:" An external, third party token service (representing an external person or organization).
* "Genesis:" An ISIP-m-card is generated by a Security Token Service running at an Identity Provider site and imported into the user's Identity Selector
* "Claims:" The list of supported claim types (claim type URIs) is defined by the issuer.
* "Authority:" The issuer is the sole authority for the claim values contained within the token it issues.
* "Data flow:" ISIP-m-cards contain a network endpoint reference to a Security Token Service (STS) that, when requested by the identity selector (using WS-Trust, etc.) generates/provides a security token containing the required claims.
* "Editability:" Underlying attribute data is not "directly" editable by the user.
* "Attribute data source:" Determined by the issuer, and generally managed by the issuer.
* The Bandit project demonstrated an additional kind of managed card backed by OpenIDs at the BrainShare conference in March 2007.

Z-Card

Under development by the Higgins project. A z-card's security token handling differs from an m-card (or an r-card) in three privacy-enhancing ways. First, the token produced by the z-card is generally fetched from the external STS very infrequently and is always cached locally. This has certain privacy benefits. Second, it produces a new kind of token called an idemix token. This token supports selective disclosure of claims (e.g. the ability to retrieve a sub-set of the claims and to perform privacy enhancing transformation (e.g. converting the claim "age=35" to the claim "age>21"). Lastly it supports the ability of an identity selector to generate "zero knowledge proofs" that can be conveyed by the agent to the relying party without revealing any more than is absolutely necessary and while maintaining the chain of trust back to the original token issuer.

Summary of characteristics:
* "Data format:" z-cards contain the same metadata fields as an m-card
* "Issuer:" An external party (person or organization).
* "Genesis:" A z-card is imported into the user's identity selector, typically by downloading from the issuer's website.
* "Claim Schema:" The schema (a list of supported claims) is defined by the external party.
* "Authority" The issuer is the sole authority for the claim values.
* "Data flow:" z-cards contain a network endpoint reference to an STS that, when requested by the identity selector generates/provides an idemix security token containing the required claims. This token is typically cached in the identity selector and only re-fetched if it has expired.
* "Editability:" Underlying attribute data is not "directly" editable by the user.
* "Attribute data source:" Determined by the issuer.

Personal Cards

ISIP-P-Card

The first kind of personal information cards were also introduced as part of Microsoft’s Windows CardSpace software in November 2006. Their behavior is also defined by the same documents covering the Microsoft-defined ISIP-m-cards (see above).

Summary of characteristics:
* "Data format" an XML file containing: set of claim type URIs as well as the (user-defined) values of these claims, "cardImage", a unique cardID, etc. This data format is defined in the ISIP documents.
* "Issuer:" The user's own identity selector. P-cards can be described as "self-issued"
* "Genesis:" Created by the user's identity selector.
* "Claims:" 15 pre-defined claim types (e.g. firstname, surname, email address, etc.) are defined in the [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf Identity Selector Interoperability Profile V1.0] .
* "Authority:" The user's identity selector is the authority for the issued token's set of claim values.
* "Data flow:" On demand (e.g. as needed by a relying site), an STS local to the identity selector creates a security token with the current values.
* "Editability:" The claim values are directly editable by the user.
* "Attribute data source:" The ISIP-p-card file itself contains claim values. When imported into an identity selector these data values are then managed internally by the selector.

Relationship Cards

Relationship cards are under development by the Higgins project. They can be either self-issued, where your identity selector defines and issues the card on your behalf, or third-party, where an entity other than you defines and issues the r-card. With r-cards, this distinction is less important because in both cases an r-card represents a mutual relationship and agreement to share certain claims/attributes.

Self-Issued R-card

* "Issuer:" The user.
* "Genesis:" Created by the user using their identity selector.

Third-Party R-card

* "Issuer:" An external entity.
* "Genesis:" Generated by external entity (the third party) and imported into the user's identity selector

Common Characteristics of Self-Issued and Third-Party R-Cards

* "Data format:" An XML file containing all of the fields of an ISIP-m-card or ISIP-p-card plus the addition of Entity [http://parity.com/udi UDI] (a URI that points to the attribute data source).
* "Supported Claims:" Like all ISIP-m-cards (or ISIP-p-cards), r-cards include a list of supported claim types (expressed as URIs) as defined by the issuer. This set defines the maximal set of claims that issuer will include in its generated security token. These claims are inherited from underlying ISIP-m-card upon which it is based and are used for the same purposes.
* "Authority:" The issuer is the authority for the issued token's set of claim values (as per a normal ISIP-m-card or ISIP-p-card).
* "Editability:" As with ISIP-m-cards, supported claim values are defined by the issuer and not editable by any other party. However, the values of those claims (as distinct from the types of the supported claims) "may" be editable by parties other than the issuer.
* "Supported Attributes:" As mentioned, r-cards contain one additional data field beyond the fields found in an ISIP-m-card. The field holds an Entity [http://parity.com/udi UDI] (URI) that "points to" a data entity (representing a person, organization, or other object). The issuer sets the value of this data field. The set of attributes of this data entity is distinct from (though usually a superset of) the "supported claims" mentioned above.

Reliance on the Higgins Data Model

Conceptually an ISIP-m-card is essentially a human-friendly "pointer" to a Token Service--a web service (e.g. a WS-Trust Security Token Service) from which security tokens can be requested. A security token is a set of attribute assertions (aka claims) about some party that is cryptographically signed by the issuer (the token service acting as the authority). An r-card, adds a "pointer" that typically points to a data entity whose attribute's values are the raw materials consumed by the token service. By including this second "pointer" on the r-card, r-card holders have the potential to access and update some subset of these underlying attributes. The card issuer maintains an access control policy to control who has what level of access.

This second pointer is an Entity [http://parity.com/udi UDI] --a reference to an "Entity" object in the Higgins [http://wiki.eclipse.org/index.php?title=Context_Data_Model Context Data Model] . Entity UDIs may be dereferenced and the underlying Entity's attributes accessed by using the [http://higgins-project.org Higgins] project's "Identity Attribute Service" (see [http://wiki.eclipse.org/Identity_Attribute_Service IdAS] ). Once resolved, consumers of this service can inspect, and potentially modify the attributes of the entity as well as get its schema as described in Web Ontology Language (OWL).

In addition to basic identity attribute values like strings and numbers, the data entity referred to by an r-card can have complex attribute values consisting of aggregates of basic attribute types as well as UDI links to other entities.

See also

* Information Card
* Information Card Foundation
* Identity Selector
* Higgins project
* Bandit project
* Windows CardSpace
* [http://www.mac.com/icards Apple iCards (part of the soon to be discontinued .Mac service)]

References

* [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf Identity Selector Interoperability Profile] , Arun Nanda, April 2007.
* [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1-Guide.pdf An Implementer's Guide to the Identity Selector Interoperability Profile V1.0] , Microsoft Corporation and Ping Identity Corporation, April 2007.
* [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1-Web-Guide.pdf A Guide to Using the Identity Selector Interoperability Profile V1.0 within Web Applications and Browsers] , Michael B. Jones, April 2007.

External links

* [http://www.eclipse.org/higgins/ Higgins Project home]
* [http://www.microsoft.com/interop/osp/ Microsoft Open Specification Promise] , May 2007.