I-Card

This page describes the Higgins (abstract) concept of a protocol-agnostic I-Card. Pages describing specific, concrete kinds 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.
• Some kinds 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
• Other kinds 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
• Different kinds of I-Cards interact with external entities using different protocols (e.g. Cardspace/WS-Trust, etc.)

Where do they live in the Higgins architecture?

• I-Cards are instantiated and managed by I-Card Providers that plug in to the I-Card Registry
• I-Card instances implement the I-Card Interface.
• I-Card Providers interact with external relying parties, and may also interact with identity providers.

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

Signed I-Cards

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

Supported Claims/Attributes

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

Who Creates Them?

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

I-Cards are really "Virtual" Containers

• 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

Access Control

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

Who can edit them?

• 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

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

I-Card Providers and Protocols

• 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

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