OpenID in Smartphones

From MgmtWiki
Revision as of 21:39, 7 December 2020 by Tom (talk | contribs) (Problem)

Jump to: navigation, search

Full Title or Meme

This use case focuses on the parts of enabling a Self-issued Identifier within a battery-powered mobile device that will impact the protocol that is used when the device acts as a Self-issued OpenID Provider.

Context

  • This use case assumes the user with a Smartphone that wants to enable a Self-issued Identifier using only that phone
  • Both Apple and Android have learned that energy consuming applications will drain a user's battery and work to limit apps that do that.
  • Also no app that resulting in huge drains on the Smartphone battery would survive for long in the marketplace.
  • The goal for would be a Self-issued OpenID Provider User Experience that is as good as the front channel OpenID Connect experience.
    • The user experience with creating the new identifier must result in 80 - 90% success rate.
    • The user Experience with navigating and registry with a new RP must be nearly as good as that using Facebook to perform the same function.
    • The user experience of loosing access due to accident of technology upgrade must be 90 - 95% successful on first attempt.
  • This use case focuses on native user apps because of their access to the keystone in current smartphone operating systems.

Problems

  • Given the current browser reality, SIOP will not duplicate the same seamless, in-browser window experience,
  • In other words, a user cannot get a signin experience on a RP site for first time signin with a DID that they can get with, say, Google or FB.
  • Facebook and Microsoft have had years to create an account recovery regime that works of a wide range of access denials in the real world. SIOP needs to come close to duplicating that functionality or it will suffer from bad user reports on the technology.
  • The smartphone is first of all a phone and this functionality cannot cause the phone to lose power too quickly or otherwise impact the primary purpose of the smartphone.

Preconditions

  • The user has a smartphone that can handle the secure storage of user secrets.
  • A native app can be down-loaded that will act as a SIOP. Some folk call this a user wallet if it can also store other credentials, but that is outside the scope of this use case.

References