Skip to main content
Jump to: navigation, search

Difference between revisions of "I-Card"

(Links: + r-card link)
(I-Card: Representation in Personal Data Model)
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 +
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 
== Generic Definitions ==
 
== Generic Definitions ==
 
* See http://en.wikipedia.org/wiki/I-card (The page Paul started)
 
* See http://en.wikipedia.org/wiki/I-card (The page Paul started)
Line 4: Line 6:
 
* 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.
 
* 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-Cards: Higgins Implementation Point of View==
+
== I-Card: Representation in Persona Data Model ==
 +
 
 +
* See [[Persona Data Model 2.0]]
 +
 
 +
== I-Cards: As implemented in Higgins [[I-Card Service 1.1]] ==
 
* [[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]] (On Firefox, currently 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  
 
===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 20: 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 44: Line 43:
  
  
 +
== See Also ==
 +
* [[R-Card]]
  
 
+
[[Category:Higgins Data Model]]
 
+
==Links==
+
* [[R-Card]]
+
* [http://eclipse.org/higgins Higgins Home]
+

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

Back to the top