Difference between revisions of "OpenID in Smartphones"
From MgmtWiki
(→Context) |
|||
| Line 7: | Line 7: | ||
* Also no app that resulting in huge drains on the [[Smartphone]] battery would survive for long in the marketplace. | * 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 goal for would be a [[Self-issued OpenID Provider]] [[User Experience]] that is as good as the front channel [[OpenID Connect]] experience. | ||
| − | |||
==Problem== | ==Problem== | ||
* Given the current browser reality, SIOP will not duplicate the same seamless, in-browser window experience, | * 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. | * 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. | ||
| + | |||
| + | ==Preconditions== | ||
| + | * The user has a smartphone that can handle the secure storage of user secrets. | ||
| + | |||
==References== | ==References== | ||
[[Category: Identifier]] | [[Category: Identifier]] | ||
Revision as of 21:16, 7 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.
Problem
- 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.
Preconditions
- The user has a smartphone that can handle the secure storage of user secrets.
