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 "Org.eclipse.higgins.iss"

(Overview)
Line 1: Line 1:
 
==Overview==
 
==Overview==
Broadly speaking the [[I-Card Selector Service]] (ISS) negotiates between relying party on the one hand and the user's identity provider(s) on the other. It attempts to discover possible options for authentication and/or other identity related exchanges between the two.
+
The [[I-Card Selector Service]] (ISS) tries to find one or more I-Cards that match the policy it is passed when invoked by the [[ISS Web UI]] or [[ISS Client UI]] on behalf of some relying party
  
 
'''Understanding the relying party's policy'''
 
'''Understanding the relying party's policy'''
Line 18: Line 18:
 
'''Releasing digital information'''
 
'''Releasing digital information'''
  
If the user clicks on a card, then ISS Web/Client UI will invoke one of the I-Card's methods (e.g. getDigitalIdentity() or getURL(), etc.) to retreive the information that it will convey/transmit to the Higgins client.  
+
If the user clicks on a card, then ISS Web/Client UI will invoke one of the I-Card's methods (e.g. getDigitalIdentity() or getURL(), etc.) to retreive the information that it will convey/transmit to the Higgins client.
  
 
==Service==
 
==Service==

Revision as of 16:43, 28 October 2006

Overview

The I-Card Selector Service (ISS) tries to find one or more I-Cards that match the policy it is passed when invoked by the ISS Web UI or ISS Client UI on behalf of some relying party

Understanding the relying party's policy

ISS is invoked by either the ISS Web UI or the [[ISS Client UI] on behalf of a Higgins client. Let's first look at the case of the special Higgins client called the Higgins Browser Extension (HBX). When, as controlled by the user's brower, HBX lands on a new site, HBX discovers the site's policies. Some of these policies are related to authentication, others are related to other kinds of allowable/supported identity exchanges (for which the term policy often seems a bit awkward, but we use it all the same). HBX invokes the ISS Web UI in the attempt to satisfy the site's policy. The policy states what kind of digital exchange protocols, payloads (e.g. token types, RSS feeds), etc. that it supports as well as the required claims and/or the required claimants and/or issuers of these claims.

Analogously, a non-HBX Higgins client (e.g. an enterprise service, RCP app, etc.) may require the user to authenticate into the application. This client would invoke ISS Web UI or ISS Client UI, passing in its authentication policy and attempting to fine one or more I-Cards that satisfy the policy.

Matching against the user's I-Cards

With the RP policy in hand, the ISS iterates through the cards in the I-Card Registry invoking isMatch method on each and making the RP policy available as a parameter. The result is a subset of zero or more I-Cards that match.

Displaying the I-Card Selector

Depending on the results of this matching process and the I-Card's release policy, the ISS Web/Client UI may display an I=Card Selector visual interface. Some or all of the user's I-Cards are displayed in this UI with all but the matching I-Cards greyed-out (diabled). The user can review the relying party's required claims, review the claim data that they may be about to release, etc. Unless the user cancels out of the interaction the user clicks on one of the non-greyed-out cards and thereby approves the release of the digital information.

Releasing digital information

If the user clicks on a card, then ISS Web/Client UI will invoke one of the I-Card's methods (e.g. getDigitalIdentity() or getURL(), etc.) to retreive the information that it will convey/transmit to the Higgins client.

Service

  • ISS API
  • Requirement: ISS need to run in both normal and headless modes. Headless mode means that a web or rich client UI is not available, and that all (if any) matching i-cards should be returned based on a given "input" policy

See Also

Back to the top