Difference between revisions of "I-Card"

Revision as of 15:19, 28 October 2006

This page describes the Higgins concept of a protocol-agnostic I-Card. Pages describing specific, concrete types of cards including CardSpace, RSS, SSFF, OpenID-H that build on this abstraction will be added later.

What is an I-Card?

• An abstract concept. A visual metaphor representing, in a context, either a single Digital Subject or (less commonly) a group of Digital Subjects that may be interconnected into a network.

I-Card Types

• I-Cards exist in concrete form as one of a number of types of I-Cards
• Higgins defines several I-Card Interfaces one or more of which are implemented by specific types of I-Cards
• I-Cards are instantiated, managed by I-Card Providers that plug in to the I-Card Registry
• Different kinds of I-Cards interact with external entities using different protocols (e.g. Cardspace/WS-Trust, etc.)
• Examples
  • Some types of I-Cards can package and encrypt this 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.
  • Other types of I-Cards create a periodic or continuous, uni- or bi-directional data exchange channels with external network endpoints. 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. Higgins is developing an RSS-P card that uses RSS (with SSE extensions) to exchange information with

Appearance

• I-Cards appear in the ISS Web UI, ISS Client UI or the I-Card Manager UI as 2D rectangular regions
• Cards display a text string called the (CardName) that is set by the card’s issuer
• Cards also display a text string called the (IssuerName)
• Cards may have a background color or 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

I-Cards are really "Virtual" Containers

• Cards usually don’t really contain (i.e. store) their information.
• Instead, they usually hold the metadata necessary to retrieve their contents on demand
• Examples:
  • CardSpace "managed" cards retrieve their Digital Identities using WS-Trust from an external Identity Provider/STS
  • RSS-P cards retreive their attribute data from IdAS
• Specific types of cards maintain one or more endpoint references that specify from where the card information (ie. claims or attributes) should be retreived. The specific syntax of these endpoint references and the protocol used to retreive the information depends on the card type

Supported Claims

• We call the information that an I-Card can (if approved by the user) provide to a relying party, Claims.
• Note: We call the underlying information that is used to support a claim Identity Attributes. There are times when this distinction is meaningful (e.g. a true/false claim of a person being over 21, vs. the uderlying date-of-birth attribute data), but there are also times when there is no mapping between the underlying attribute and the claim conveyed to the relying party.
• For compatibility with legacy systems, we make a distinction between simple types of Claims and complex types of Claims
• Simple types of Claims are represented as URIs with associated literal string or numeric values [Is this correct? Are there (in practice) no "claimants" for each claim in legacy systems]
• I-Cards declare the set of all possible claim types
• For simple claim type cards this is declared as a list of URIs
• For complex claim type cards this is declared as an OWL-DL schema (This schema must be based on the Higgins Ontology)

Who Creates Them?

• 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)

Access Control List

• The contents of a card are protected by an ACL
• The ACL is a list of endpoints to which the card's contents may be exposed (if and when requested and/or needed).
• Some of these endpoints are conventional relying party sites (e.g. Amazon.com, etc.) and others are references to i-card instances (on Higgins servers) that represent the identities of Higgins users
• 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”

Who can edit them?

• It depends on the type of card, on your role/access permissions, etc.
• Examples:
  • Cards issued by you may be completely editable by you
  • Managed CardSpace cards are not editable
  • Managed RSS-P cards 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, digitally signed sets of digital identity information to the relying party
• Others, e.g. RSS-P cards, engage in continuous, dynamic uni- or bi-directional exchange of information with the relying party

See Also

• Higgins Wiki