Authentication UX

Full Title or Meme

The successful Authentication schems, like OpenID Connect, have been those that provide a good User Experience. Schemes that impeded the user work flow the least.

Context

• The major feature of OpenID Connect (OIDC) was its ability to operate on the "Front Channel" so that he user browser context was maintained and the user could get on with the work at hand.
• The browser makers are currently completing on which one provides the best privacy considerations. As the security of the user information is increased, it inevitably impedes the flows that worked well for OIDC.
• No implementation of the Self-issued Section 7 of the OIDC has ever received a wide public presence.

Problems

• Especially with Federation Signing, the connections used between different browser widows has make the user extence good, but is indistinguishable from user tracking which the browser manufacturers have vowed to drastically reduce.
  • Web ID wants to know if a web site is acting as an IdP. presentation to blinkON (2020-11-18) work of the WICG of W3C.
  • IsLoggedOn (and its children like IsAutenticated). Work of the privacy CG of the W3C.
• Any Self-issued Identity Provider (SIOP) requires some method to authentication while preserving the user work flow. The existing techniques available from the browser do not do that.
  • Native code can get control from the browser by some well-known URL, but that is subject to be overridden by an attacker and does not allow the native app to return control to the same user browser context.
  • Web apps require a user-owned URL that is used to install the app. That URL must be known to the RP to use the existing front channel solutions. That results is what is know as the "NASCAR problem" of too many choices being presented to the user. It is unlikely that a web site would like more that 3-6 choices to avoid taking the user off track for why they went to the web site in the first place.
• The core problem is that any web page or web app is not inherently trustworthy. Some work-arounds are shown the the Web App page.

Goals

1. At least as good as UX
2. Improve user Privacy by increasing the security of both user data and user Attention.

Possible Solutions

Version 2 of ODIC

• Disruptive innovation requires any business to eat their own childern or someone else will come along and do it first.
• Front channel communication had a long run, it may be time to look seriously at alternatives.

Focus on Browser

Whether version 2 is started or not, it is important to help the W3C, and the browser folk in particular, to work with OpenID and DIF to create a win-win solution.

1. Allow the browser to act like IDP and create a Web ID
2. Allow authentication methods to register like payment methods (some privacy concerns may arise) (or as payment methods) to be:
   1. Read by JavaScript in a DOM API
   2. Insert values into the HTTP Header
3. Web AuthN II is now in development. The case of a web Authenticator integrated into the client device seems to be the most interesting possibility.

• See also wiki pages on Browser and Browser Identity Interactions.

WebAuthn Authenticator

• From Web AuthN II

  A cryptographic entity, existing in hardware or software, that can register a user with a given Relying Party and later assert possession of the registered public key credential, and optionally verify the user, when requested by the Relying Party. Authenticators can report information regarding their type and security characteristics via attestation during registration. A WebAuthn Authenticator could be a roaming authenticator, a dedicated hardware subsystem integrated into the client device, or a software component of the client or client device. In general, an authenticator is assumed to have only one user. If multiple natural persons share access to an authenticator, they are considered to represent the same user in the context of that authenticator. If an authenticator implementation supports multiple users in separated compartments, then each compartment is considered a separate authenticator with a single user with no access to other users' credentials.

• That describes the way that the underlying o/s handles the keys, but does describe how that might be exposed as an API in the DOM.

User Permanent Presence

One intriguing solution is to give the user a URL that is "always on". This would allow very convenient ways for the user to be in control. It is hard to imagine a successful business model that would not create a worse privacy problem for the user than the one that exists today.

• It is interesting to note that the DID can get a DID document from the web in the current design. That document is not currently oriented to the authentication issues addressed here.
• While the IPFS could host user data, it (like the DID doc) is not protected in any way and so could be a major privacy issue. In general, if the user can be given a collection of value from some sort of web presence beyond just authentication, the balance could switch in favor of a permeant presence of some sort.