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"

m (RSS-P I-Card Provider)
 
(48 intermediate revisions by 4 users not shown)
Line 1: Line 1:
==Overview==
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
* An [[I-Card Provider]] is responsible for instantiating and managing [[I-Card]] instances (that implement the [[I-Card Interfaces]])
+
__NOTOC__
* 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.
+
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.  
* 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 provide RSS feeds to identity information stored in the [[Identity Attribute Service]]
+
* The Higgins project is developing these types of I-Card Providers:
+
** Cardspace-compatible
+
** RSS-P
+
** SSFF (ScreenScrapeFormFill)
+
** planned: OpenID-H-compatible Managed
+
** ...others
+
  
==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]]
+
 
+
==RSS-P I-Card Provider==
+
* This provider "projects" a [[Digital Identity]] to an external site as an RSS+SSE feed. The relying site may optionally also be able to provide a feed in the reverse direction to allow the relying site to update the identity information
+
* RSS-P I-Card Providers implment the ''I-Card,'' ''URLIssuerCard,'' and ''IdASCard'' interfaces
+
 
+
==SSFF Provider==
+
* Implements the ''I-Card'', ''IdASCard'', and ''SSFFCard'' [[I-Card Interfaces]]
+
* The ''IdASCard'' implementation code uses IdAS to manage the identity data that is being synchronized (via HTML scraping and form filling)
+
* The ''SSFFCard'' implementation code returns to HBX the script necessary to perform screen scraping and form filling on the target site
+
 
+
==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