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"

(→‎Who can edit them?)
(→‎I-Card: Representation in Personal Data Model)
 
(84 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
This page describes the Higgins concept of an [[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 representing identity information about one or more [[Digital Subject]]s in a context
+
−
* [[I-Card]]s are icons that are displayed, created, edited, and selected in a graphical user interface
+
−
* An I-Card holds only metadata. The metadata references identity information that is external to the card itself, and stored locally or remotely
+
−
* [[I-Card]]s are created by an called the ''issuer'' and made available to an external web system or service. In authentication interactions these recipients are called ''relying claims are trusted by the relying party, it will allow the holder to take some further action, be granted access to resources, etc. In this usage the card acts like a key.
+
−
* Some [[I-Card]]s can be used to enable to long term, dynamic, sharing of identity information between two or more parties. Which information fields are editable by which party depends on the context.
+
−
===Supported Claims Schema===
+
−
* [[I-Card]]s declare the schema of the claims/ attributes they support.
+
−
* This schema is used by Higgins ISS to match against the relying system’s policy requirements
+
−
* At its simplest, the schema of this data is a single set of literal attributes (e.g. first name) and values (e.g. “Paul”). These attributes are called claims. The attribute/claim types are represented as URIs.
+
−
* An [[I-Card]] can reference information about multiple Digital Subjects (e.g. a buddy list or directory). In this case there are N sets of attributes, one for each Digital Subject]].
+
−
* Beyond literal values a [[Digital Subject]] referenced by a card may contain complex attribute types (e.g. a postal address)
+
−
* The schema of these more complex [[I-Card]]s is captured in an OWL-DL schema
+
−
* The set of [[Digital Subject]]s referenced by an I-Card may contain links called Subject Relationships to other Digital Subjects within the same I-Card (e.g. a social network)
+
  
−
===I-Card Types===
+
* See [[Persona Data Model 2.0]]
−
* Higgins defines several [[I-Card Interfaces]] one or more of which are implemented by specific types of I-Cards
+
−
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]
+
−
* Note: See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned
+
−
* Different types of [[I-Card]]s interact with external entities using different protocols (e.g. Cardspace/WS-Trust, RSS, 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===
+
== I-Cards: As implemented in Higgins [[I-Card Service 1.1]] ==
−
* [[I-Card]]s appear in the [[ISS Web UI]], [[ISS Client UI]] or the [[I-Card Manager]] UI as rectangular icons  
+
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
−
* Cards have a name that is displayed as a text string (called the ''CardName'') that is set by the card’s ''issuer'' 
+
* [[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
−
* Cards display in a text string the name of the issuer who originated the card (''IssuerName'')
+
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements
−
* Cards may have 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
+
  
−
===Signed I-Cards===
+
===I-Card Types===
−
* Signed cards encrypt and digitally sign a set of claims about a single Digital Subject
+
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]
−
* Technically speaking, this signing process (e.g. STS) is the card issuer, although for unsigned cards we call the card creator the issuer.
+
* See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned
−
* As an example, an I-Card used to present credit card information would used signed data
+
Higgins defines three [[I-Card Interface]]s. Two are required and one is optional
−
===Unsigned I-Cards===
+
−
* Unsigned cards are used to share and sync information about one or more Digital Subjects
+
−
* An example of a card with multiple Digital Subjects would be an enterprise directory or social network
+
  
 +
===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 ''ITokenCard'' interface whose prominent feature is the ''getDigitalIdentity'' method that returns a signed security token that includes the claims and their values
  
−
 
+
==[[I-Card]]s and the [[I-Card Registry]]==
−
===I-Card Issuers===
+
* [[I-Card]]s are implemented, instantiate and managed by plug-ins called [[I-Card Provider]]s
−
* The creator/originator of a card is called the issuer.
+
* All [[I-Card Provider]]s must support the two required interfaces (including ''ITokenCard'')
−
* Cards store (and display) the human-friendly name of the issuer (''IssuerName'')
+
* Managed [[I-Card Provider]]s are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
−
* Cards may store (and display) an image provided by 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)
−
* 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'')
+
−
 
+
−
===Provider vs. Personal I-Cards===
+
−
* ''Provider'' cards reference identity data from the issuer entity that provided the card to the person
+
−
* For example, CardSpace provider cards retrieve their Digital Identities (in token form) from an external Identity Provider using WS-Trust
+
−
* ''Personal'' cards are created by a person for their own use
+
−
 
+
−
===Access Control===
+
−
* 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)
+
−
* Future: support regular expressions, wildcards and exceptions
+
−
 
+
−
===Release Policy===
+
−
* 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”
+
−
 
+
−
===Editability===
+
−
* Varies by card...
+
−
* Personal cards (e.g. those issued by you) may be completely editable by you
+
−
* Some cards (e.g. a CardSpace provider card) are not editable at all by you
+
−
* Some cards (e.g. a RSS-P provider 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
 +
** 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]]?
 +
  
−
===Static vs. Dynamic Data Flows===
+
== See Also ==
−
* Some cards convey static, digitally signed sets of digital identity information to the relying party
+
* [[R-Card]]
−
* Others, e.g. RSS-P cards, engage in continuous, dynamic uni- or bi-directional exchange of information with the relying party
+
  
−
==See Also==
+
[[Category:Higgins Data Model]]
−
* [[I-Card Interfaces]], [[I-Card Provider]]
+
−
* [[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