Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "I-Card"

(Managed vs. Personal I-Cards)
(Managed vs. Personal I-Cards)
Line 47: Line 47:
  
 
===Managed vs. Personal I-Cards===
 
===Managed vs. Personal I-Cards===
* ''Managed'' cards reference identity data from the issuer entity that provided the card to the person
+
* Managed cards are cards issued by an external party (person or organization) and made available to you
 +
* ''Managed'' cards reference identity data from the issuer entity  
 
* For example, CardSpace provider cards retrieve their Digital Identities (in token form) from an external Identity Provider using WS-Trust
 
* For example, CardSpace provider cards retrieve their Digital Identities (in token form) from an external Identity Provider using WS-Trust
 
* ''Personal'' cards are created by a person for their own use
 
* ''Personal'' cards are created by a person for their own use
 +
 
===Editability===
 
===Editability===
 
* Varies by card...
 
* Varies by card...

Revision as of 16:07, 8 December 2006

This page describes the Higgins concept of an I-Card.

What is an I-Card?

  • Overview
    • Are displayed as card icons. These icons provide a visual metaphor representing identity information about one or more Digital Subjects in a context.
    • Have a schema describing their supported claims
    • Are implemented in code by I-Card Providers
  • The card metaphor is related to things we know like library cards, association cards, business cards, credit cards, badges, etc. but in other ways it is different.
  • Unlike physical cards, I-Cards are not limited as to size/length/capacity, and they can be easily copied (if desired)
  • An I-Card holds only metadata. The metadata references identity information that is external to the card itself, and stored locally or remotely
  • I-Cards are created by an entity known as a issuer
  • Some kinds of I-Cards are used for authentication interactions where the holder of the card is presenting its associated claims to a relying party.
  • If the claims are trusted by the relying party, these claims will allow the holder to take some further action, be granted access to resources, etc. In this usage the card acts like a key.
  • Some I-Cards can be used to enable long term, dynamic, sharing of identity information between two or more parties. Whether or not attributes supported by the card are editable and by which party, depends on the context.

Appearance

  • I-Cards appear in the ISS Web UI, ISS Client UI or the I-Card Manager UI as rectangular icons
  • Cards have a name that is displayed as a text string (called the CardName) that is set by the card’s issuer
  • Cards display in a text string the name of the issuer who originated the card (IssuerName)
  • Cards may have a (GIF or JPEG) background image (CardImage) set by the card’s issuer
  • By pressing a "Retrieve" button with a card selected the user can retrieve and display the latest values of the card's contained claims/attributes.

Supported Claims Schema

  • I-Cards declare the schema of the claims/attributes they support and the claim space (claim namespace) of each
  • This schema is used by Higgins I-Card Selector Service to match against the relying system’s policy requirements
  • At its simplest, the schema is a linear list of claim/attribute types described as a URI (e.g. a URI for "surname")
  • An I-Card may reference information about multiple Digital Subjects (e.g. a buddy list or directory).
  • Further, an I-Card may support complex attribute types (e.g. postal address) whose values contain structure
  • The schema of these more complex I-Cards is captured in an OWL-DL schema

I-Card Types

  • I-Cards are implemented, instantiated, managed by I-Card Providers that plug in to the I-Card Registry
  • See I-Card Provider for a description of the types of I-Cards under development or planned
  • I-Cards do not talk to relying parties directly. The RP Protocol Support component consumes I-Cards and uses their metadata to obtain data with which to exchange with RP sites & systems.
  • Higgins defines several I-Card Interfaces one or more of which are implemented by specific types of I-Cards
  • All I-Cards implement the generic, base I-Card interface. It includes methods to get the issuer of a card, the background image of a card, the display name of a card, the supported attribute/claim schema of the data retreiveable by the card, a way to retreive the current value(s) of the claim(s) of the card, and so on.
  • Some I-Cards implement the TokenCard interface whose prominent feature is the getDigitalIdentity() method that returns a signed security token that includes the claims and their values
  • Some I-Cards implement the URICard interface whose prominent feature is the getURI() method that returns a ContextRef --the identifier of a Context holding the underlying data.
  • Note: These interfaces are composable so I-Cards may implement both of the above, etc.

I-Card Issuers

  • 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) called personal (aka self-issued) cards


Managed vs. Personal I-Cards

  • Managed cards are cards issued by an external party (person or organization) and made available to you
  • Managed cards reference identity data from the issuer entity
  • For example, CardSpace provider cards retrieve their Digital Identities (in token form) from an external Identity Provider using WS-Trust
  • Personal cards are created by a person for their own use

Editability

  • Varies by card...
  • Personal cards (e.g. those issued by you) may be completely editable by you
  • Some cards (e.g. a CardSpace managed card) are not editable at all by you (except the cardName)
  • Some cards may have some fields that you can edit and some fields that you can’t

Access Control

  • The I-Card Registry maintains an Access Control List (ACL) for each card
  • The ACL is a list of URLs
  • Each URL is a site that has been granted access.
  • Future: support regular expressions, wildcards and exceptions

Release Policy

  • The I-Card Registry maintains a release policy for each card.
  • This policy is one of: (EveryTime, FirstTime, Never).
  • As in “ask the user (EveryTime, FirstTime, or Never) before releasing this information to an external site/person”
  • Note: We don't yet know whether the convenience advantages of Never or FirstTime are worth the risk for certain kinds of cards


I-Card Accessed List

  • The I-Card Registry maintains an accessed list for each card 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
    • Timestamp of first access
    • Timestamp of most recent access
  • Notes
    • This accessed list history is not exported with the card when a card is exported.
    • Should the accessed list be "clearable" by the user?
    • Should we be able to export an entire I-Card Registry?


See Also

Back to the top