I-Card

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

What is an 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

Appearance

• 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 by a display name string (IssuerName) set by the card’s issuer
• A card may have a background color or a background image 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)

I-Cards as Containers (sort of)

• Loosely speaking, (and to the naive user) cards can be thought of as containers of identity data
• Two kinds of data: signed and unsigned
• Signed cards encrypt and digitally sign a set of claims about a single DS
• Technically speaking this signing process (e.g. STS) is the card issuer, though for unsigned cards we call the card creator the issuer.
• A credit card is an example of a signed card

Unsigned I-Cards

• Unsigned cards contain and make available (statically or dynamically) information about one or more Digital Subjects
• An example of a card with multiple Digital Subjects would be an enterprise directory or social network
• Each Digital Subject contains a set of Attributes
• 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 contain/offer
• Unsigned cards declare the schema of the set of attributes they contain/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, many 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

Who See's their Contents?

• 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

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