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"

(→‎I-Card Issuers)
(→‎I-Card: Representation in Personal Data Model)
 
(28 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
This page describes the Higgins concept of an [[I-Card]].  
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 +
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 +
== Generic Definitions ==
 +
* See http://en.wikipedia.org/wiki/I-card (The page Paul started)
 +
* See http://en.wikipedia.org/wiki/Information_Card (The page Mike Jones (Microsoft) started)
 +
* For the good of the industry Paul and Mike are *trying* to converge the definitions. This involves compromises on both sides. Microsoft claims that "Information Card" is a generic term, but historically has used it to mean the two kinds of cards supported by CardSpace. Through discussion they've been updating Information Card wikipedia page to be less CardSpace-limited.
  
−
===What is an I-Card?===
+
== I-Card: Representation in Persona Data Model ==
−
* Overview
+
−
** Are displayed as card icons. These icons provide a visual metaphor representing identity information about one or more [[Digital Subject]]s in a context.
+
−
** Have a schema describing their ''supported claims''
+
−
** Are implemented in code by [[I-Card Provider]]s
+
−
* 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-Card]]s 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-Card]]s 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===
+
* See [[Persona Data Model 2.0]]
−
* [[I-Card]]s 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: As implemented in Higgins [[I-Card Service 1.1]] ==
−
* [[I-Card]]s declare the schema of the claims/attributes they support and the claim space (claim namespace) of each
+
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
−
* This schema is used by Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements
+
* [[I-Card]]s are the basis for user-visible [[I-Card]]s (described previously) appear in the [[ISS Web UI]] (On Firefox, currently part of [[Higgins Browser Extension]]), [[ISS Client UI]] or the [[I-Card Manager]] UI as rectangular icons
−
* At its simplest, the schema is a linear list of claim/attribute types described as a URI (e.g. a URI for "surname")
+
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements
−
* An [[I-Card]] may reference information about multiple [[Digital Subject]]s (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-Card Types===
−
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]
+
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]  
−
* See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned
+
* See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned  
−
* I-Cards do not talk to relying parties directly. The [[RP Protocol Support]] component consumes [[I-Card]]s and uses their metadata to obtain data with which to exchange with RP sites & systems.
+
Higgins defines three [[I-Card Interface]]s. Two are required and one is optional
−
* Higgins defines several [[I-Card Interfaces]] one or more of which are implemented by specific types of I-Cards
+
−
* All [[I-Card]]s 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-Card]]s 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-Card]]s 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-Card]]s may implement both of the above, etc.
+
−
 
+
−
 
+
−
 
+
−
===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 Types: Required Interfaces===
 +
* All [[I-Card]]s implement the generic, base ''ICard'' 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 retrieveable by the card, a way to retrieve the current value(s) of the claim(s) of the card, and so on.
 +
* All [[I-Card]]s implement the ''ITokenCard'' interface whose prominent feature is the ''getDigitalIdentity'' method that returns a signed security token that includes the claims and their values
  
 +
==[[I-Card]]s and the [[I-Card Registry]]==
 +
* [[I-Card]]s are implemented, instantiate and managed by plug-ins called [[I-Card Provider]]s
 +
* All [[I-Card Provider]]s must support the two required interfaces (including ''ITokenCard'')
 +
* Managed [[I-Card Provider]]s are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
 +
* [[I-Card Provider]]s are responsible for persistence and encryption of their I-Card instances (user can control where (e.g. on the net, in thumbdrive) each card is stored)
  
 
===I-Card Accessed List===
 
===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
+
* 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:
 
* It is list of triples:
 
** Relying Party’s URL
 
** Relying Party’s URL
Line 74: Line 37:
 
** Timestamp of most recent access
 
** Timestamp of most recent access
 
* Notes
 
* Notes
 +
** Valery thinks that this accessed list maintenance should be an [[I-Card Provider]] responsibility
 
** This ''accessed list'' history is not exported with the card when a card is exported.
 
** 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 the ''accessed list'' be "clearable" by the user?
Line 79: Line 43:
  
  
 +
== See Also ==
 +
* [[R-Card]]
  
−
==See Also==
+
[[Category:Higgins Data Model]]
−
* [[I-Card Interfaces]], [[I-Card Provider]]
+
−
* [[Higgins Wiki]]
+

Latest revision as of 09:17, 3 May 2010

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

Generic Definitions

  • See http://en.wikipedia.org/wiki/I-card (The page Paul started)
  • See http://en.wikipedia.org/wiki/Information_Card (The page Mike Jones (Microsoft) started)
  • For the good of the industry Paul and Mike are *trying* to converge the definitions. This involves compromises on both sides. Microsoft claims that "Information Card" is a generic term, but historically has used it to mean the two kinds of cards supported by CardSpace. Through discussion they've been updating Information Card wikipedia page to be less CardSpace-limited.

I-Card: Representation in Persona Data Model

I-Cards: As implemented in Higgins I-Card Service 1.1

I-Card Types

Higgins defines three I-Card Interfaces. Two are required and one is optional

I-Card Types: Required Interfaces

  • All I-Cards implement the generic, base ICard 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 retrieveable by the card, a way to retrieve the current value(s) of the claim(s) of the card, and so on.
  • All I-Cards implement the ITokenCard interface whose prominent feature is the getDigitalIdentity method that returns a signed security token that includes the claims and their values

I-Cards and the I-Card Registry

  • I-Cards are implemented, instantiate and managed by plug-ins called I-Card Providers
  • All I-Card Providers must support the two required interfaces (including ITokenCard)
  • Managed I-Card Providers are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
  • I-Card Providers are responsible for persistence and encryption of their I-Card instances (user can control where (e.g. on the net, in thumbdrive) each card is stored)

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
    • Valery thinks that this accessed list maintenance should be an I-Card Provider responsibility
    • 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

Retrieved from "https://wiki.eclipse.org/index.php?title=I-Card&oldid=198966"

This page was last modified 09:17, 3 May 2010 by Paul Trevithick. Based on work by Anna Gorb, Paul Trevithick and Tom Carroll and others.

Back to the top