Org.eclipse.higgins.iss

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.

'Understanding the relying party's policy'

ISS is invoked by 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 sites 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 I-Card Selector Service to 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, passing in its authentication policy and desiring/requiring some kind of digital data payload, tokens, URLs, etc. in return that satisfies 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.

'Displaying the I-Card Selector'

Depending on the results of this matching process and the I-Card's release policy, the ISS may invoke the ISS Web UI or ISS Client UI to 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 approves the release, then the information in whatever form and protocol was desired by the RP is released. For RPs involved in traditional authentication interactions, the RP will typically be requesting a Digital Identity in token form as presented over some common identity protocol.

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

• ISS Web UI
• ISS Client UI
• I-Card Registry
• Core Components