I-Card

This page captures the idea of a protocol-agnostic I-Card

A visual metaphor for a container of information about Digital Subjects
Cards can be offered (released to) to Relying Parties (well, technically Relying Party Agents)
Cards are presented for selection and release by the ISS Web UI or ISS Client UI
Cards can be acquired and managed by the Higgins I-Card Manager

Cards appear in the I-Card Selector Service (ISS) UI or the I-Card Manager UI as flat 2D rectangular regions with radius corners
Cards are labeled with text called the (CardName) that is set by the card’s issuer
A card may have a background color or a (GIF or JPEG) background image (CardImage) set by the card’s issuer
Cards that contain 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)

Signed cards encrypt and digitally sign a set of claims about a single Digital Subject
For signed cards the signing process (i.e. a Token Issuer) (e.g. STS) is the card issuer
All CardSpace cards are signed I-Cards

Unsigned cards contain and make available (statically or dynamically) Identity Attribute information about one or more Digital Subjects
An example of an unsigned card with a signle Digital Subject would be a business card, vCard, etc.
The creator of an usigned card is called the issuer
An example of a card with multiple Digital Subjects would be an enterprise directory or social network
Each Digital Subject contains a set of Identity Attributes
Identity Attributes may be simple literals (e.g. firstName), complex (e.g. postalAddress), or represent relationships with other DSes

Signed cards declare the schema of the set of Claims they support/offer
Unsigned cards declare the schema of the set of Idenitty Attributes they support/offer
Schema format TBD (hmm.. OWL-DL would be overkill for CardSpace cards, but required for RSS-P cards)

The original creator of a card is called the issuer
Managed cards are cards issued by an external party (person or organization) and made available to you
Examples of managed cards include credit cards and driver’s licenses
You can also create your own cards (and for these you are the issuer)
Cards store the human-friendly name of the issuer (IssuerName)
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)

Managed cards usually don’t really contain (i.e. store) their information.
Instead, they usually hold the metadata necessary to retrieve their contents on demand
For example, managed CardSpace cards retrieve their Digital Identities using WS-Trust from an external Identity Provider
Each card holds 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 kind of card

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)
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”
Future: support regular expressions, wildcards and exceptions

It depends on the card…
Some cards (e.g. those issued by you) may be completely editable by you
Some cards (e.g. a managed CardSpace card) are not editable at all by you
Some cards (e.g. a managed RSS-P card) may have some fields that you can edit and some fields that you can’t

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

I-Cards are implemented by plug-ins called I-Card Providers
Different I-Card Providers use different identity exchange protocols with external systems
For example, a CardSpace provider uses the WS-Trust protocol to retrieve Digital Identities from an Identity Provider
Support for CardSpace, RSS-P, SSFF (Screen Scrape and Form Fill), and OpenID-H are planned

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

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.