User Apps with Identifiers: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
No edit summary
Line 16: Line 16:


===Native App Solutions===
===Native App Solutions===
The app is loaded from a trusted app store and has full access to the features of the device.
* 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.


===Web App Solutions===
===Web App Solutions===
The app is loaded from a trusted web site and has access to the service broker features in the DOM.
* The app is loaded from a trusted web site and has access to the service broker features in the DOM.
* The app is only available then running on a smartphone, but the web address will respond if the if app is not running.
===Hybrid App Solutions===
===Hybrid App Solutions===
The app works with a  
*The app works with a website that can present information about user choices at all times.


==References==
==References==


[[Category: Article]]
[[Category: Concept]]
[[Category: Identifier]]
[[Category: Identifier]]

Revision as of 23:38, 12 January 2021

Full Title

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

Context

The example 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.

Solutions

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.

Web App Solutions

  • The app is loaded from a trusted web site and has access to the service broker features in the DOM.
  • The app is only available then running on a smartphone, but the web address will respond if the if app is not running.

Hybrid App Solutions

  • The app works with a website that can present information about user choices at all times.

References