Difference between revisions of "I-Card"

Revision as of 01:09, 16 November 2006

This page describes the Higgins concept of an I-Card.

What is an I-Card?

• A visual metaphor representing identity information about one or more Digital Subjects in a context
• I-Cards are icons that are displayed, created, edited, and selected in a graphical user interface
• The card metaphor is related to things we know like library cards, association cards, business cards, credit cards, badges, etc. but in other ways it is different.
• Unlike physical cards, I-Cards are not limited as to size/length/capacity, and they can be easily copied (if desired)
• An I-Card holds only metadata. The metadata references identity information that is external to the card itself, and stored locally or remotely
• I-Cards are created by an issuer and made available to an external web site or service. In authentication interactions these recipients are called relying parties.
• Some kinds of I-Cards are used for authentication interactions where the holder of the card is presenting its claims to a relying party. If the claims are trusted by the relying party, it will allow the holder to take some further action, be granted access to resources, etc. In this usage the card acts like a key.
• Some I-Cards can be used to enable to long term, dynamic, sharing of identity information between two or more parties. Which information fields are editable by which party depends on the context.

Supported Claims Schema

• I-Cards declare the schema of the claims/attributes they support.
• This schema is used by Higgins I-Card Selector Service to match against the relying system’s policy requirements
• At its simplest, the schema of this data is a single set of literal attributes (e.g. first name) and values (e.g. “Paul”). These attributes are called claims. The attribute/claim types are represented as URIs.
• An I-Card can reference information about multiple Digital Subjects (e.g. a buddy list or directory). In this case there are N sets of attributes, one for each Digital Subject.
• Beyond literal values a Digital Subject referenced by a card may contain complex attribute types (e.g. a postal address)
• The schema of these more complex I-Cards is captured in an OWL-DL(?) schema
• The set of Digital Subjects referenced by an I-Card may contain links called Subject Relationships to other Digital Subjects within the same I-Card (e.g. a social network)

I-Card Types

• Higgins defines several I-Card Interfaces one or more of which are implemented by specific types of I-Cards
• I-Cards are implemented, instantiated, managed by I-Card Providers that plug in to the I-Card Registry
• Note: See I-Card Provider for a description of the types of I-Cards under development or planned
• I-Cards do not talk to relying parties directly. The RP Protocol Support component consumes I-Cards and uses their data to interact with RP sites & systems.
• Example 1
  • Some types of I-Cards can package and encrypt their information as a Digital Identity in token form that can be used by relying parties for authentication purposes.
  • Higgins is developing a CardSpace compatible I-Card type that can interoperate with CardSpace-compatible relying parties, as well as request Digital Identities from CardSpace/WS-Trust compatible identity providers (STSes).
  • Higgins plans to develop a card compatible with OpenID relying parties and OpenID servers.
• Example 2
  • Other types of I-Cards can be used to support a periodic or continuous, uni- or bi-directional data exchange channels with external network endpoints.
  • RP Protocol Support will support an RSS-SSE channel between the RP site and a site-specific I-Card
  • This can allow the external site or service some level of authentication/recognition but can also allows it to update, and/or append information represented by the I-Card.

Appearance

• I-Cards appear in the ISS Web UI, ISS Client UI or the I-Card Manager UI as rectangular icons
• Cards have a name that is displayed as a text string (called the CardName) that is set by the card’s issuer
• Cards display in a text string the name of the issuer who originated the card (IssuerName)
• Cards may have a (GIF or JPEG) background image (CardImage) set by the card’s issuer
• Cards that contain information about a single Digital Subject display in a text string in the center the most identifying information field(s) of the Digital Subject (e.g. first&last name) that is available

Token Issuing I-Cards

• Token issuing cards encrypt and digitally sign a set of claims about a single Digital Subject
• Technically speaking, this signing process (e.g. STS) is the card issuer, although for unsigned cards we call the card creator the issuer.
• As an example, an I-Card used to present credit card information would used signed data

I-Card Issuers

• The creator/originator of a card is called the issuer.
• Cards store (and display) the human-friendly name of the issuer (IssuerName)
• Cards may store (and display) an image provided by the issuer.
• Depending on the type of card, the issuer refer to a Token Issuer endpoint or it may refer to an IdAS endpoint, or some other kinds of identity information provider endpoint. The specifics of how this endpoint is referenced, authenticated to, etc. is left to the specific card type implementation. Some examples:
  • Instances of the Higgins developed CardSpaceCard class (a type of I=Card) will, for self-signed cards, define issuer to mean the endpoint of the local STS Token Issuer; For managed CardSpace cards, the issuer is a remote STS.
  • Instances of the Higgins developed RSSPCard class (a type of I-Card) will define issuer to mean a local or remote Identity Attribute Service endpoint. In this case no Digital Identity tokens, STS, etc. are involved at all.
• Cards also store the date and time when the card was created (TimeIssued). They may also store the date and time after which the card should be treated as expired and invalid (TimeExpires)

Provider vs. Personal I-Cards

• Provider cards reference identity data from the issuer entity that provided the card to the person
• For example, CardSpace provider cards retrieve their Digital Identities (in token form) from an external Identity Provider using WS-Trust
• Personal cards are created by a person for their own use

Access Control

• Each card has an Access Control List (ACL)
• The ACL is a list of URLs (or XRIs).
• Each URL is a site that has been granted access. (Each XRI is an i-card identifier)
• Future: support regular expressions, wildcards and exceptions

Release Policy

• Each card is marked one of: (EveryTime, FirstTime, Never).
• As in “ask the user (EveryTime, FirstTime, or Never) before releasing this information to an external site/person”

Editability

• Varies by card...
• Personal cards (e.g. those issued by you) may be completely editable by you
• Some cards (e.g. a CardSpace provider card) are not editable at all by you
• Some cards (e.g. a RSS-P provider card) may have some fields that you can edit and some fields that you can’t

I-Card Accessed List

• Each card has an accessed list that provides the history of what parties have at one time or another been granted access to the card
• It is list of triples:
  • Relying Party’s URL/XRI
  • Timestamp of first access
  • Timestamp of most recent access

Static vs. Dynamic Data Flows

• Some cards convey static sets of digital identity information to the relying party
• Others are used in various kinds of data sharing between the person’s system and one or more external systems. These data flows may be implemented as pull or push. They may be periodic or continuous. The may be uni-directional, bi-directional or omni-directional

See Also

• I-Card Interfaces, I-Card Provider
• Higgins Wiki