Difference between revisions of "I-Card"

Revision as of 17:55, 24 February 2007

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

I-Cards from the User's Point of View

• I-Card: a credit card-shaped icon display in the user interface of an Identity Agent that represents a Digital Identity
• This Digital Identity is a set of Claims about a single Digital Subject
• This Digital Subject is a contextualized representation of an Entity (usually the user Entity)
• The 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)
• I-Cards are created by an Entity known as a issuer

Appearance

• I-Cards have a text string name (cardName) that is set by the card’s issuer (user-editable)
• I-Cards display in a text string the name of the issuer (IssuerName)
• I-Cards may have a (GIF or JPEG) background image (cardImage) set by the card’s issuer (user-editable)
• In most I-Cards the user is able to see the value of the claims.
  • Note: in CardSpace this is contained in a special display token
• An I-Card either:
  • Holds its data within itself (a "Personal" I-Card)
  • Holds a "pointer" to where its data is (a "Managed" or "URI" I-Cards)

Kinds of I-Cards

• Managed I-Cards are cards issued by an external party (person or organization) and made available to the Identity Agent user
• Managed I-Cards retrieve identity data from the I-Card's issuer
• For example, CardSpace Managed I-Cards retrieve their Digital Identities (in token form) from an external Identity Provider using WS-Trust
• Personal I-Cards are created by you and contain self-asserted data. You are the issuer of these I-Cards.
• URI I-Cards retrieve information from a service located at the URI held by the I-Card. They may be created by the user's Identity Agent or someone else's Identity Agent.

Supported Claims

• I-Cards declare the schema of the claims/attributes they support and the claim space (claim namespace) of each
• At its simplest, the schema is a set of claim/attribute types described as a URI (e.g. a URI for "surname")

• Are displayed as card icons. These icons provide a visual metaphor representing identity information about one or more Digital Subjects in a context.
• Have a schema describing their supported claims
• Are implemented in code by I-Card Providers

Authentication and Relationship Management

• Some kinds of I-Cards are used for authentication interactions where the presenter of the card is presenting its associated claims to a Relying Party. If the claims are trusted by the Relying Party, they allow the presenter 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 long term, dynamic, sharing of identity information as apart of a relationship between two parties. Whether or not attributes supported by the card are editable and by which party, depends on the context.

Editability

• Personal I-Cards are editable by the Identity Agent User
• Managed I-Cards are not editable by the user (except the cardName and cardImage)
• URI I-Cards may allow user editing and/or appending of some (or all) fields. They may also allow other parties (e.g. a Vendor in the VRM notion) to edit and/or append fields

I-Cards: Higgins Implementation Point of View

• I-Card: An object implemented and managed by an I-Card Provider plug-in
• I-Cards are the basis for user-visible I-Cards (described previously) appear in the ISS Web UI (now part of Higgins Browser Extension), ISS Client UI or the I-Card Manager UI as rectangular icons
• The I-Card schema is used by the Higgins I-Card Selector Service to match against the relying system’s policy requirements

Multiple or Single

• I-Cards that point to CardSpace or OpenID IdP/STSes contain information about a single Digital Subject. This Digital Subject is an implicit object not modeled by these kinds of cards
• I-Cards that hold ContextIds (i.e. URICards) may point to Contexts containing multiple Digital Subjects representing the user and/or some other Digital Subjects (e.g. a buddy list)

More Complex Schema

• A URI I-Card may support complex attribute types (e.g. postal address) whose values contain structure
• The schema of these more complex I-Cards is accessed using getModel methods on the IContext interface

I-Card Types

• I-Cards are implemented, instantiated, managed by I-Card Providers that plug in to the I-Card Registry
• See I-Card Provider for a description of the types of I-Cards under development or planned

Higgins defines three I-Card Interfaces. Two are required and one is optional

I-Card Types: Required Interfaces

• All I-Cards implement the generic, base ICard interface. It includes methods to get the issuer of a card, the background image of a card, the display name of a card, the supported attribute/claim schema of the data retrieveable by the card, a way to retrieve the current value(s) of the claim(s) of the card, and so on.
• All I-Cards implement the ITokenCard interface whose prominent feature is the getDigitalIdentity method that returns a signed security token that includes the claims and their values

URICards

• Some I-Cards implement the IURICard interface whose salient feature is the getURI method that returns a ContextId--the identifier of a Context holding the underlying data.

I-Cards and the I-Card Registry

• I-Cards are implemented, instantiate and managed by plug-ins called I-Card Providers
• All I-Card Providers must support the two required interfaces (including ITokenCard)
• Managed I-Card Providers are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
• I-Card Providers are responsible for persistence and encryption of their I-Card instances (user can control where (e.g. on the net, in thumbdrive) each card is stored)

I-Card Accessed List

• The I-Card Registry maintains an accessed list for each card 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
  • Timestamp of first access
  • Timestamp of most recent access
• Notes
  • Valery thinks that this accessed list maintenance should be an I-Card Provider responsibility
  • This accessed list history is not exported with the card when a card is exported.
  • Should the accessed list be "clearable" by the user?
  • Should we be able to export an entire I-Card Registry?

Access Control(Proposal)

• The I-Card Registry maintains an Access Control List (ACL) for each card
• The ACL is a list of URLs
• Each URL is a site that has been granted access.
• Future: support regular expressions, wildcards and exceptions
• Notes
  • Valery thinks that this accessed list maintenance should be an I-Card Provider responsibility

Release Policy(Proposal)

• The I-Card Registry maintains a release policy for each card.
• This policy is one of: (EveryTime, FirstTime, Never).
• As in “ask the user (EveryTime, FirstTime, or Never) before releasing this information to an external site/person”
• Notes
  • We don't yet know whether the convenience advantages of Never or FirstTime are worth the risk for certain kinds of I-Cards
  • Valery thinks that this accessed list maintenance should be an I-Card Provider responsibility

See Also

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