Difference between revisions of "I-Card"

Revision as of 11:52, 26 October 2006

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 --usually people or organizations
• 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 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

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

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