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: Representation in Personal Data Model)
 
(15 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
==The User's Point of View==
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
−
An [[I-Card]] is a credit card-shaped icon display in the user interface of an Identity Agent 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).  
+
[[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.
  
−
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.
+
== I-Card: Representation in Persona Data Model ==
  
−
===Appearance===
+
* See [[Persona Data Model 2.0]]
−
* [[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===
+
== I-Cards: As implemented in Higgins [[I-Card Service 1.1]] ==
−
* ''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 Agent]] 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-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===
 
−
* A URI [[I-Card]] may support complex attribute types (e.g. postal address) whose values contain structure
 
−
* The schema of these more complex [[I-Card]]s is accessed using ''getModel'' methods on the IContext interface
 
  
 
===I-Card Types===
 
===I-Card Types===
Line 54: Line 22:
 
===I-Card Types: Required Interfaces===
 
===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 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  
+
* 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
−
 
+
−
===URICards===
+
−
* Some [[I-Card]]s 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-Card]]s and the [[I-Card Registry]]==
 
==[[I-Card]]s and the [[I-Card Registry]]==
Line 77: Line 42:
 
** Should we be able to export an entire [[I-Card Registry]]?
 
** 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)===
+
== See Also ==
−
* The [[I-Card Registry]] maintains a ''release policy'' for each card.
+
* [[R-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-Card]]s
+
−
** Valery thinks that this accessed list maintenance should be an [[I-Card Provider]] responsibility
+
  
−
==See Also==
+
[[Category:Higgins Data Model]]
−
* [http://eclipse.org/higgins Higgins Home]
+
−
* [[Architecture]]
+
−
* [[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