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.
I-Card
This page captures the idea of a protocol-agnostic I-Card
Contents
- 1 What is an I-Card?
- 2 Appearance
- 3 I-Cards as Containers (sort of)
- 4 Unsigned I-Cards
- 5 Available Claims/Attributes
- 6 Who Creates Them?
- 7 I-Cards are really "Virtual" Containers
- 8 Who See's their Contents?
- 9 Who can edit them?
- 10 I-Card Accessed List
- 11 I-Card Providers and Protocols
- 12 Static vs. Dynamic Data Flows
- 13 See Also
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 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