User Apps with Identifiers

Full Title

This article addresses the various solutions to creation of a synchronized Identifier between a user app and a Relying Party

Context

• The use case addressed here is a Smartphone app that is uses to establish a user's identifier with a Website over the internet.
• The working assumption here is the the Front Channel Authentication enabled with OpenID Connect 1.0 is the primary source of its good User Experience and hence of its tremendous success with user and with Relying Party adoption.

Problems

1. The user needs to trust that the app will honor the user's wishes.
2. The web site needs to trust that the app correctly informs it of the user's preferred identifier with:
   1. the appropriate Identity Assurance Level (IAL) aka identity proofing.
   2. the appropriate Authentication Assurance Level (AAL) aka proof of presence and control by the user.
   3. the appropriate Federation Assurance Level (FAL) aka follows the federation rule and regulations. (optional)
3. The peculiarities of the existing browsers have been backed into multi-site federations that are being adversly affected by changes now working their way though the W3C process, including:
   1. Companies like Verizon that have web sites with different names like: aol.com and yahoo.com.
   2. Companies like Amazon that operating in different parts of the world under different legal regimes like: amazon.com and amazon.co.uk.
   3. Research and education consortia like Internet2 that have thousands of organizations and millions of users.

Two major category of app are considered along with a hybrid that lies between the two.

Native App Solutions

• The app is loaded from a trusted app store and has full access to the features of the device.
• If the smart phone browser is available, (the assumption is that) it will be able to start the app.
• The Relying Party web site will present options to the user with each one having a redirect URL. The special URL "openid://" is reserved to start a native app that can act as a SIOP - Self-issued OpenID Provider as described in section 7 of the OIDC specification.

Unsolved Problem

1. The redirection code (e.g. openid://) can be registered, or hijacked) by any app that the user downloads.
2. The RP needs to enable the OpenID with one button (among many others) that redirects to the app for authentication.
3. Once the app have been invoked it requires special code to return control to the user in the same context (browser tab.)

Web App Solutions

• The app is loaded from a trusted web site and has access to the service broker features in the DOM.
• Also known as a Progressive Web App or PWA.
• The user on a web browser can click on a POST button provided by the RP. The POST is to the URL of the site that loaded the Web App service broker on the user's device. The browser can direct that POST to the Web App for processing. Eventually the Web App will respond to the user's browser with the AuthZ code (or token) for redirection as a GET to RP, which results in the response from the RP with a new page that puts the user back in control.
• The app is only available when running on a smartphone, but the web address will (should?) respond if the if app is not running.

Unsolved Problem

1. Each app has its own URL which corresponds to the site where it was loaded. The RP needs to know which app are loaded in order to redirect the request to the app for authentication.
2. TBD on how the user gets control back to the app that called it.
3. In OIDC the AuthN Request goes from the RP to the OP, presumably as a redirected HTTPS GET from the user agent, which is captured by the Web App. Since the packet was encrypted for the OP, how can the Web App decrypt the data?
4. A large number of solutions that will not all be accommodated in Relying Party web sites without some sort of discovery.

Hybrid App Solutions

• The app works with a website that can present information about user choices at all times.
• For an example, in the Solid project, a user stores personal data in "pods" (personal online data stores) hosted wherever the user desires.

Unsolved Problem

1. Who pays for hosting the PODS
2. TBD on how control flows from the RP to the app and back to the user.

Solutions

Lots of solutions have been proposed to the problems listed above, but all of them require changes from the browsers.

1. The browser records all authentications as a part of existed password storage and know what to do the next time a web site asks for creds.
2. The credential manager (credman) enables credential control in the DOM.
3. First party manifests.
4. etc. etc. etc.

References

• A related problem is described in the Over 21 with Proof of Presence Use Case.