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 Provider"

(Self-Issued Cards)
 
(41 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 
__NOTOC__
 
__NOTOC__
==Overview==
+
Higgins supports multiple kinds of i-cards with differing characteristics. It does so by using multiple kinds of i-card providers, each of which implements one specific class of i-card. Although all i-cards implement the base "ICard" interface, some may implement one or more of the optional interfaces, and thus provide more or different characteristics.  
* An [[I-Card Provider]] is responsible for instantiating and managing [[I-Card]] instances (that implement the [[I-Card Interfaces]])
+
* A Provider is also responsible for importing I-Cards from serialized data formats. For example a CardSpace [[I-Card Provider]] would be responsible for being able to import CardSpace format data files.
+
* A Provider must somehow configure itself with resources that may be needed by its [[I-Card]]s. For example, a CardSpace [[I-Card Provider]] must know the endpoint for the local [[Token Issuer]] (STS).
+
* Different [[I-Card Provider]] implementations use different protocols for retreiving identity information. Some might use WS-Trust to request a [[Digital Identity]] from a local STS (for self-issued cards), others from a remote STS (managed cards). Still others might retrieve identity information stored in the [[Identity Attribute Service]]
+
* The Higgins project is developing these types of I-Card Providers:
+
** Cardspace-compatible (managed)
+
** Cardspace-compatible (self-issued)
+
** IdAS (variants:)
+
*** Username & Password - each card stores one of the user's unique un/pw combinations (pullled from browser's password manager)
+
*** Single Website - stores a copy of user's personal information on a website (e.g. linkedin.com, flikr, etc.)
+
*** Persona/Role {e.g. Shopper, Travel, Home&Personal, Health, Friends, Family} cards --for the multiple hats you wear
+
  
==CardSpace-compatible I-Card Provider==
+
==Service/API==
* This provider will support interoperability with CardSpace relying parties and CardSpace/WS-Trust compatible IdPs.  
+
An [[I-Card Provider]] is responsible for:
* It will support both ''managed'' and ''self-issued'' CardSpace-compatible I-Cards
+
* Instantiating [[I-Card]]s that implement the [[I-Card Interfaces]]
* It will be able to import CardSpace-format managed cards
+
* Managing the persistence of i-cards (e.g. to/from working storage)
 +
* Supporting the [[I-Card Registry]] in importing I-Cards from one of the supported card data formats.  
 +
** [[I-Card Provider]]s implements a ''canImportICard'' method that declares what formats it can support
 +
* Supporting the [[I-Card Registry]] in exporting I-Cards to one of the supported card data formats.
  
====Self-issued and Managed Cards====
+
[[Category:Higgins Components]]
* Are single [[Digital Subject]] [[I-Card]]s
+
* The [[I-Card]]s implements the ''I-Card'' and ''TokenIssuerCard'' [[I-Card Interfaces]]:
+
* The ''TokenIssuerCard'' impl code manages the metadata necessary to request a [[Digital Identity]] token from a local or remote STS
+
 
+
====Self-Issued Cards====
+
* The self-issued card instances will implement the ''IdASCard'' interface (see [[I-Card Interfaces]])
+
* The ''TokenIssuerCard'' impl code will leverage a local STS that can create Idemix compatible-tokens (in addition to the usual CardSpace-compatible token types)
+
* The ''IdASCard'' impl code manages manages the metadata necessary to retreive claims that are provided to the local STS [[Token Issuer]]
+
 
+
==See Also==
+
* [[I-Card]], [[I-Card Interfaces]]
+
* [[I-Card Registry]], [[I-Card Registry API]]
+
* [[Core Components]]
+

Latest revision as of 09:37, 15 December 2008

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins supports multiple kinds of i-cards with differing characteristics. It does so by using multiple kinds of i-card providers, each of which implements one specific class of i-card. Although all i-cards implement the base "ICard" interface, some may implement one or more of the optional interfaces, and thus provide more or different characteristics.

Service/API

An I-Card Provider is responsible for:

  • Instantiating I-Cards that implement the I-Card Interfaces
  • Managing the persistence of i-cards (e.g. to/from working storage)
  • Supporting the I-Card Registry in importing I-Cards from one of the supported card data formats.
    • I-Card Providers implements a canImportICard method that declares what formats it can support
  • Supporting the I-Card Registry in exporting I-Cards to one of the supported card data formats.

Back to the top