Difference between revisions of "OpenID in Smartphones"
From MgmtWiki
(Created page with "==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...") |
(→Preconditions) |
||
| (17 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==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 | + | 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== | ==References== | ||
[[Category: Identifier]] | [[Category: Identifier]] | ||
Latest revision as of 14:16, 20 December 2020
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.
