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"

(→‎Editability)
Line 1: Line 1:
−
==The User's Point of View==
+
== Generic Definitions ==
−
An [[I-Card]] is a credit card-shaped icon display in the user interface of an [[Identity Selector]] that represents a [[Digital Identity]]--a set of claims about a digital subject. This digital subject is a contextualized representation of an entity (usually the user entity). The metaphor is related to familiar things like library cards, association cards, business cards, credit cards, badges, etc. but in other ways it is different. Unlike physical cards, [[I-Card]]s are not limited as to size/length/capacity, and they can be easily copied (if desired).
+
* 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)
−
Microsoft's CardSpace Identity Agent (included as a part of Windows Vista) uses and card-based user interface. A Microsoft CardSpace card, that they often refer to as an "information card," is a kind of [[I-Card]] as defined here.
+
* For the good of the industry Paul and Mike are *trying* to converge these two wiki pages into one. 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.  
−
 
+
−
===Appearance===
+
−
* [[I-Card]]s are created by an entity known as a ''issuer''
+
−
* [[I-Card]]s have a text string name (''cardName'') that is set by the card’s ''issuer'' (user-editable)
+
−
* [[I-Card]]s display in a text string the name of the issuer (''IssuerName'')
+
−
* [[I-Card]]s may have a (GIF or JPEG) background image (''cardImage'') set by the card’s issuer (user-editable)
+
−
* In most [[I-Card]]s the user is able to see the value of the claims.
+
−
** Note: in CardSpace this is contained in a special ''display'' token
+
−
* An [[I-Card]] either:
+
−
** Holds its data within itself (a "Personal" [[I-Card]])
+
−
** Holds a "pointer" to where its data is (a "Managed" or "URI" [[I-Card]]s)
+
−
 
+
−
===Kinds of I-Cards===
+
−
* ''Managed'' [[I-Card]]s are cards issued by an external party (person or organization) and made available to the Identity Agent user. They retrieve identity data from the [[I-Card]]'s issuer. For example, CardSpace Managed [[I-Card]]s retrieve their [[Digital Identity | Digital Identities]] (in token form) from an external Identity Provider using WS-Trust
+
−
* ''Personal'' [[I-Card]]s are created by you and contain self-asserted data. You are the issuer of these [[I-Card]]s.
+
−
* ''URI'' [[I-Card]]s retrieve information from a service located at the URI held by the [[I-Card]]. They may be created by the user's Identity Agent or someone else's Identity Agent.
+
−
 
+
−
=== Supported Claims/Attributes ===
+
−
* [[I-Card]]s declare the schema of the claims/attributes they support and the claim space (claim namespace) of each
+
−
* At its simplest, (and as supported by CardSpace format [[I-Card]]s) the schema is a set of claim/attribute types each consisting of a URI (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname for "surname"), although more complex claim/attribute types maybe used by other kinds of [[I-Card]]s.
+
−
 
+
−
=== Authentication and Relationship Management===
+
−
* Some kinds of [[I-Card]]s are used for authentication interactions where the presenter of the card is presenting its associated claims to a relying party. If the claims are trusted by the relying party, they allow the presenter 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 as apart of a relationship between two parties. Whether or not attributes supported by the card are editable and by which party, depends on the context.
+
−
 
+
−
=== Editability ===
+
−
* Personal [[I-Card]]s are editable by the [[Identity Selector]] User
+
−
* Managed [[I-Card]]s are not editable by the user (except the ''cardName'' and ''cardImage'')
+
−
* URI I-Cards may allow user editing and/or appending of some (or all) fields. They may also allow other parties (e.g. a Vendor in the [[Vendor Relationship Management]] concept) to edit and/or append fields
+
  
 
== I-Cards: Higgins Implementation Point of View==
 
== I-Cards: Higgins Implementation Point of View==
 
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
 
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
−
* [[I-Card]]s are the basis for user-visible [[I-Card]]s (described previously) appear in the [[ISS Web UI]] (now part of [[Higgins Browser Extension]]), [[ISS Client UI]] or the [[I-Card Manager]] UI as rectangular icons
+
* [[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
 
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements  
 
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements  
−
 
−
===Multiple or Single===
 
−
* [[I-Card]]s that point to CardSpace or OpenID IdP/STSes contain information about a single [[Digital Subject]]. This [[Digital Subject]] is an implicit object not modeled by these kinds of cards
 
−
* [[I-Card]]s that hold ContextIds (i.e. URICards) may point to [[Context]]s containing multiple [[Digital Subject]]s representing the user and/or some other [[Digital Subject]]s (e.g. a buddy list)
 
  
 
===More Complex Schema===
 
===More Complex Schema===

Revision as of 18:54, 19 January 2008

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 these two wiki pages into one. 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-Cards: Higgins Implementation Point of View

More Complex Schema

  • A URI I-Card may support complex attribute types (e.g. postal address) whose values contain structure
  • The schema of these more complex I-Cards is accessed using getModel methods on the IContext interface

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

URICards

  • Some I-Cards implement the IURICard interface whose salient feature is the getURI method that returns a ContextId--the identifier of a Context holding the underlying data.

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?

Access Control(Proposal)

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

Release Policy(Proposal)

  • 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”
  • Notes
    • We don't yet know whether the convenience advantages of Never or FirstTime are worth the risk for certain kinds of I-Cards
    • Valery thinks that this accessed list maintenance should be an I-Card Provider responsibility

Links

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

Back to the top