Org.eclipse.higgins.iss

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} The org.eclipse.higgins.iss uses a policy engine to attempt to determine a matching between the Relying Party's Security Policy and one or more I-Cards that can satisfy that policy.

Service

I-Card Selector Service is an extension of Registry which manages loading and configuration of plugins that implements IICardSelector interface.

Responsibilities

• Determine a matching between the Relying Party's Security Policy and one of IICardSelectors that in turn determine matching I-Cards that can satisfy that policy.
• Provide convinient way to call getIdentityToken method of apropriate IICardSelector.

Dependencies

• I-Card Registry
• Token Service???

API

// Iterate through cards in the I-Card Registry, use Policy engine
// to examine the supported claim of each to find one or more cards that 
// singly or together satisfy the policy. Invoke the ISS Web UI 
// if 'hbx' is true, else invoke the ISS Client UI to display all cards
// highlighting matching card(s). After user selects card(s), 
// getDigitalIdentity from the card(s) (combining DIs if needed?)
IDigitalIdentity getDigitalIdentity(RPSPolicy policy, boolean hbx)

// (Presuming that only one card matched, and of course that the
// card was a URICard for which IdAS can connect and open a Context)
// Return the Context of the selected card.
IContext getContext(RPSPolicy policy)

// Return a URI to a network endpoint (e.g. an OpenID IdP) that the
// RP will interact with directly --Higgins steps out of the flow
URI getURI(RPSPolicy policy)

// Matching functionality is now exposed by the ISS
Choices match(RPSPolicy policy) throws UnsatisfiablePolicyException

PolicyFactory Interface

PolicyFactory: This class has one method which instantiates a class that exposes the Policy interface below for the given policy type.

 Policy ParsePolicy(String policy, String type) throws PolicyParseException, UnsupportedPolicyTypeException

The factory implementation is quite simple, but it allows for extensibility---various different policies can be registered and instantiated dynamically, etc.

Policy Interface

 // contains the parser for the policy string
 new(String policy) throws PolicyParseException
 
 // matches the policy and returns a list of lists indicating the user choices
 // can return an empty Choices structure if no choices are needed
 Choices match(Icard Registry) throws UnsatisfiablePolicyException
 
 // makes a token which satisfies this policy using the Selection of credentials
 DigitalIdentity getDigitalIdentity(Selection) throws InvalidSelectionException

The Cardspace Policy Class

The cardspace policy class implementation of _new_ would parse the policy. The _match_ method would subsume the role of the ISS as it is currently described. In particular, it would iterate through the list of cards retrieved from the registry, call isMatch on each one, and return a list of those which matched.

The getDigitalIdentity would simply call the similar function of the underlying I-card.

Idemix Policy Class

An Idemix policy class implementation would have the flexibility to do more complicated matching, and more complicated processing to get the token.

Given these two classes, the RP protocol support class would then handle the details of marshalling/unmarshalling, formatting parameters and inputs, and making the right calls to the PolicyFactory and resulting Policy class.

This architecture allows for many more interop possibilities. Anyone who can implement a policy language for _requesting_ such credentials can plug into this.

Links

• Higgins Home