Difference between revisions of "Authentication UX"

From MgmtWiki
Jump to: navigation, search
(Problems)
(Problems)
Line 11: Line 11:
 
** IsLoggedOn (and its children like IsAutenticated).
 
** IsLoggedOn (and its children like IsAutenticated).
 
* 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.
 
* 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 context.
+
** 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.
 
** 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.
  

Revision as of 14:11, 22 November 2020

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.

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.
    • IsLoggedOn (and its children like IsAutenticated).
  • 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.

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

Focus on W3C

  • 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.

References