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"

(→‎I-Card: Representation in Personal Data Model)
 
(181 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
This page captures the idea of a protocol-agnostic 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 ==
−
* A visual metaphor for a container of information about [[Digital Subject]]s --usually people or organizations
+
−
* Cards can be offered (released to) to Relying Parties (well, technically Relying Party Agents)
+
−
* Cards are presented for selection and release by the [[ISS Web UI]] or [[ISS Client UI]]
+
−
* Cards can be acquired and managed by the Higgins [[I-Card Manager]]
+
  
−
===Appearance===
+
* See [[Persona Data Model 2.0]]
−
* Cards appear in the [[I-Card Selector Service]] (ISS) UI or the [[I-Card Manager]] UI as flat 2D rectangular regions with radius corners
+
−
Cards are labeled by a display name string set by the card’s issuer
+
−
A card may have a background color or a background image set by the card’s issuer
+
−
Cards that contain 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)
+
  
−
===I-Cards as Containers (sort of)===
+
== I-Cards: As implemented in Higgins [[I-Card Service 1.1]] ==
−
* Loosely speaking, (and to the naive user) cards can be thought of as containers of identity data
+
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
−
* Two kinds of data: '''signed''' and '''unsigned'''
+
* [[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
−
* Signed cards encrypt and digitally sign a set of claims about a single DS
+
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements
−
** Technically speaking this signing process (e.g. STS) is the card issuer, though for unsigned cards we call the card creator the issuer.
+
−
* A credit card is an example of a signed card
+
  
−
===Unsigned I-Cards===
+
===I-Card Types===
−
* Unsigned cards contain and make available (statically or dynamically) information about one or more [[Digital Subject]]s
+
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]
−
* An example of a card with multiple [[Digital Subject]]s would be an enterprise directory or social network
+
* See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned
−
* Each [[Digital Subject]] contains a set of Attributes
+
Higgins defines three [[I-Card Interface]]s. Two are required and one is optional
−
* Attributes may be simple literals (e.g. firstName), complex (e.g. postalAddress), or represent relationships with other DSes
+
  
−
===Available Claims/Attributes===
+
===I-Card Types: Required Interfaces===
−
* Signed cards declare the schema of the set of claims they contain/offer
+
* 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.  
−
* Unsigned cards declare the schema of the set of attributes they contain/offer
+
* 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
−
* Schema format TBD (hmm.. OWL-DL would be overkill for CardSpace cards, but required for RSS-P cards)
+
  
−
===Who Creates Them?===
+
==[[I-Card]]s and the [[I-Card Registry]]==
−
* The original creator of a card is called the issuer
+
* [[I-Card]]s are implemented, instantiate and managed by plug-ins called [[I-Card Provider]]s
−
* Managed cards are cards issued by an external party (person or organization) and made available to you
+
* All [[I-Card Provider]]s must support the two required interfaces (including ''ITokenCard'')
−
* Examples of managed cards include credit cards and driver’s licenses
+
* Managed [[I-Card Provider]]s are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
−
* You can also create your own cards (and for these you are the issuer)
+
* [[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-Cards are really "Virtual" Containers===
+
−
* Managed cards usually don’t really contain (i.e. store) their information
+
−
* Instead, many hold the metadata necessary to retrieve their contents on demand
+
−
* For example, managed CardSpace cards retrieve their Digital Identities using WS-Trust from an external Identity Provider  
+
−
 
+
−
===Who See's their Contents?===
+
−
* Each card has an Access Control List (ACL)  
+
−
* The ACL is a list of URLs (or XRIs).
+
−
* Each URL is a site that has been granted access. (Each XRI is an i-card identifier)
+
−
* 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 Paul Trevithick. Based on work by Anna Gorb, Paul Trevithick and Tom Carroll and others.

Back to the top