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.

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)

Two major category of app are consider 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.

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.
• The user on a web browser can be redirected to get a token from the web site, which the browser redirects to the web app.
• Also known as a Progressive Web App or PWA.
• The app is only available when running on a smartphone, but the web address will 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. Eventually the WEb App (as OP) sends a response to the user's browser for display. Since the Web App cannot sign the response how does the user agent (browser) know the response is valid?

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.