Authentication Service 2.0

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

This page describes a new network Authentication Service 1.1. The idea would be move Higgins services to a federated model. This would mean that both the Higgins Selector app (e.g. GTK Selector 1.1-Win) and all supporting services (e.g. I-Card Service 1.1, CardSync Service 1.1, etc.) would rely on this new, external Authentication Service 1.1.

Requirements

1. Use OpenID/OAuth where possible
2. Allow Authentication Service 1.1 to also control the metadata (e.g. location) of $contexts via XRD discovery
3. Allow unmodified OpenID OP to be used (optionally) to auth to selector app
4. Allow XRI OP to be used to auth to selector app
5. Preserve today's "local" un/pw auth to be used as another option
6. All identifiers must use http[s] scheme
7. Authentication Service 1.1 requires another factor when directly accessing selector data (e.g. cloud selector functionality)
8. Client side must use native code for auth UI
9. Client code must use secure storage for "saved" passwords
10. Security must be at least as good as overall selector system today

Implementation

Service

• First version should be an OpenID OP and use OAuth for returning the access token
• Would authenticate using a combination of (i) a manually typed in un/pw + (ii) POP of a client-serialized-key + (perhaps) (iii) some digital fingerprint data from the machine
• Returns access token in browser redirect

Selector changes: LICS Authentication

Changes required to the un/pw login dialog box:

• Allow the user to login not just with a "local" un/pw approach, but also via one of a number of trusted OpenID providers. This would mean that the user could choose between "local" login (today's approach) or by clicking on 1..N buttons that represent OpenID or SAML IdPs.
• The login module would initiate an OpenID/OAuth interaction with the IdP. It would only initiate OpenID/OAuth to hard-coded list of IdPs.
• The login module would (through browser redirect back) end up with an access token
• The Local I-Card Service Package would send this access token (in addition to proof of possession of a serialization key) on every message to the I-Card Service 1.1, CardSync Service 1.1, IdAS Proxy Service 1.1 and the Attribute Service 1.1 "meta" Context.

While we're making changes to the login module:

• There could be a checkbox: "Clear all data from this machine when quitting this application". If checked, the LICS would delete all locally stored data from the machine when the Azigo app quit.

Changes to Selector-Supporting Services

The I-Card Service 1.1, CardSync Service 1.1, IdAS Proxy Service 1.1 and the Attribute Service 1.1 would all need to be changed to rely on the access token generated by the Authentication Service 1.1 for authentication.