I-Card

From Wikipedia, the free encyclopedia

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.

Contents

[edit] 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 meeting notes and 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 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 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.

[edit] 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.

[edit] 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.

[edit] Managed Cards

[edit] 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 Identity Selector Interoperability Profile (pdf) (see here for a more complete list), in combination with open standards including 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.

[edit] 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.

[edit] Personal Cards

[edit] 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 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.

[edit] 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.

[edit] Self-Issued R-card

[edit] Third-Party R-card

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

[edit] 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 a Higgins Relation (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 or ISIP-p-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). However, the issuer may or may not have authorization to edit one or more attributes in the identity data set identified by the Higgins Relation.
  • Editability: As with ISIP-m-cards or ISIP-p-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 ISIP-m-cards or ISIP-p-cards. The field holds a Higgins Relation (URI) that "points to" a digital subject (person, organization, application, digital object, etc.) represented in the Higgins dataweb. The issuer sets the value of this data field. The set of attributes supported by this digital subject is distinct from (though usually a superset of) the "supported claims" of the underlying ISIP-m-card or ISIP-p-card.

[edit] Reliance on the Higgins Data Model

Conceptually an ISIP-m-card or ISIP-p-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 (acting as the authority). An r-card, on the other hand, adds a "pointer" to a set of attributes for a digital subject in the Higgins dataweb.

This pointer is called a Higgins Relation (see Higgins Data Model). A Relation consists of a ContextId and a (local) SubjectId. Briefly, a ContextId is an identifier of a data store called a context that contains one or more digital subjects. A digital subject is a set of attributes that are a representation of some entity (e.g. a human person). All digital subjects in a context have exactly one identifier unique to a context called a SubjectId.

The Higgins project includes an Identity Attribute Service (see IdAS) that can be used to resolve relation pointers to digital subjects in containing contexts. Once resolved, consumers of this service can inspect, and potentially modify the attributes of the digital subject as well as get the schema as described in Web Ontology Language (OWL) of its containing context.

In addition to basic identity attribute values like strings and numbers, a digital subject referred to by an r-card can have complex attribute values consisting of aggregates of basic attribute types. This digital subject can also have links to other digital subjects both within the same context or in other contexts.

[edit] See also

[edit] References

[edit] External links