Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "I-Card"

(→‎What is an I-Card?)
(→‎I-Card: Representation in Personal Data Model)
 
(113 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
This page describes the Higgins (abstract) concept of a protocol-agnostic I-Card. Pages describing specific, concrete types of cards including CardSpace, RSS, SSFF, OpenID-H that build on this abstraction will be added later.
+
{{#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 ==
−
* An abstract concept. A visual metaphor representing, in a context, either a single [[Digital Subject]] or (less commonly) a group of [[Digital Subject]]s that may be interconnected into a network.
+
−
* I-Cards exist in concrete form as one of a number of speific [[I-Card]] ''types''
+
−
* Higgins defines the base [[I-Card Interface]], as well as optional composable interfaces which a specific ''type'' of I-Card implements
+
−
* [[I-Card]]s are instantiated and managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]
+
−
* Different kinds of [[I-Card]]s interact with external entities using different protocols (e.g. Cardspace/WS-Trust, etc.)
+
−
* Examples
+
−
** Some types of [[I-Card]]s can package and encrypt this information as a [[Digital Identity]] in token form that can be used by relying parties for authentication purposes. Higgins is developing a CardSpace compatible I-Card type that can interoperate with CardSpace-compatible relying parties, as well as request [[Digital Identity|Digital Identities]] from CardSpace/WS-Trust compatible identity providers (STSes). Higgins plans to develop a card compatible with OpenID relying parties and OpenID servers.
+
−
** Other types of [[I-Card]]s create a periodic or continuous, uni- or bi-directional data exchange channels with external network endpoints. This can allow the external site or service some level of authentication/recognition but can also allows it to update, and/or append information represented by the [[I-Card]]. Higgins is developing an RSS-P card that uses RSS (with SSE extensions) to exchange information with
+
  
−
===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 2D rectangular regions
+
−
* Cards display a text string called the (''CardName'') that is set by the card’s ''issuer'' 
+
−
* Cards also display a text string called the (''IssuerName'')
+
−
* Cards may have a background color or a (GIF or JPEG) background image (''CardImage'') set by the card’s issuer
+
−
* Cards that contain information about 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) that is available
+
  
−
===I-Cards are really "Virtual" Containers===
+
== I-Cards: As implemented in Higgins [[I-Card Service 1.1]] ==
−
* Cards usually don’t really contain (i.e. store) their information.
+
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
−
* Instead, they usually hold the metadata necessary to retrieve their contents on demand
+
* [[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
−
* Examples:
+
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements
−
** CardSpace "managed" cards retrieve their Digital Identities using WS-Trust from an external Identity Provider/STS
+
−
** RSS-P cards retreive their attribute data from IdAS
+
−
* Specific types of cards maintain one or more endpoint references that specify from where the card information (ie. claims or attributes) should be retreived. The specific syntax of these endpoint references and the protocol used to retreive the information depends on the card type
+
  
−
===Supported Claims===
+
===I-Card Types===
−
* We call the information that an [[I-Card]] can (if approved by the user) provide to a relying party, [[Claim]]s.
+
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]  
−
* ''Note: We call the underlying information that is used to support a claim [[Identity Attribute]]s. There are times when this distinction is meaningful (e.g. a true/false claim of a person being over 21, vs. the uderlying date-of-birth attribute data), but there are also times when there is no mapping between the underlying attribute and the claim conveyed to the relying party.''
+
* See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned
−
* For compatibility with legacy systems, we make a distinction between ''simple'' types of [[Claim]]s and ''complex'' types of [[Claim]]s
+
Higgins defines three [[I-Card Interface]]s. Two are required and one is optional
−
* Simple types of [[Claim]]s are represented as URIs with associated literal string or numeric values [Is this correct? Are there (in practice) no "claimants" for each claim in legacy systems]
+
−
* [[I-Card]]s declare the set of all possible claim types
+
−
* For simple claim type cards this is declared as a list of URIs
+
−
* For complex claim type cards this is declared as an OWL-DL schema (This schema must be based on the [[Higgins Ontology]])
+
  
−
===Who Creates Them?===
+
===I-Card Types: Required Interfaces===
−
* The creator/originator of a card is called the issuer.
+
* 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.  
−
* Cards store (and display) the human-friendly name of the issuer (''IssuerName'')
+
* 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
−
* Cards may store (and display) an image provided by the issuer.
+
−
* Depending on the type of card, the issuer refer to a [[Token Issuer]] endpoint or it may refer to an IdAS endpoint, or some other kinds of identity information provider endpoint. The specifics of how this endpoint is referenced, authenticated to, etc. is left to the specific card type implementation. Some examples:
+
−
** Instances of the Higgins developed CardSpaceCard class (a type of I=Card) will, for self-signed cards, define ''issuer'' to mean the endpoint of the local STS Token Issuer; For managed CardSpace cards, the issuer is a remote STS.
+
−
** Instances of the Higgins developed RSSPCard class (a type of I-Card) will define ''issuer'' to mean a local or remote [[Identity Attribute Service]] endpoint. In this case no [[Digital Identity]] tokens, STS, etc. are involved at all.
+
−
* Cards also store the date and time when the card was created (''TimeIssued''). They may also store the date and time after which the card should be treated as expired and invalid (''TimeExpires'')
+
  
−
 
+
==[[I-Card]]s and the [[I-Card Registry]]==
−
 
+
* [[I-Card]]s are implemented, instantiate and managed by plug-ins called [[I-Card Provider]]s
−
===Access Control===
+
* All [[I-Card Provider]]s must support the two required interfaces (including ''ITokenCard'')
−
* The contents of a card are protected by an ACL
+
* Managed [[I-Card Provider]]s are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
−
* The ACL is a list of endpoints to which the card's contents may be exposed (if and when requested and/or needed).
+
* [[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)
−
* Some of these endpoints are conventional relying party sites (e.g. Amazon.com, etc.) and others are references to i-card instances (on Higgins servers) that represent the identities of Higgins users
+
−
* 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===
 
===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
+
* 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/XRI
+
** Relying Party’s URL
 
** Timestamp of first access
 
** Timestamp of first access
 
** Timestamp of most recent access
 
** Timestamp of most recent access
−
 
+
* Notes
−
===I-Card Providers and Protocols===
+
** Valery thinks that this accessed list maintenance should be an [[I-Card Provider]] responsibility
−
* I-Cards are implemented by plug-ins called I-Card Providers
+
** This ''accessed list'' history is not exported with the card when a card is exported.
−
* Different I-Card Providers use different identity exchange protocols with external systems
+
** Should the ''accessed list'' be "clearable" by the user?
−
* For example, a CardSpace provider uses the WS-Trust protocol to retrieve Digital Identities from an Identity Provider
+
** Should we be able to export an entire [[I-Card Registry]]?
−
* 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
+
  
  
 +
== See Also ==
 +
* [[R-Card]]
  
−
==See Also==
+
[[Category:Higgins Data Model]]
−
* [[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 Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top