OpenID in Smartphones - Revision history

Tom: /* Preconditions */

2020-12-20T22:16:14Z

‎Preconditions

2020-12-08T05:39:11Z

‎Problem

2020-12-08T05:35:16Z

‎Context

2020-12-08T05:32:31Z

‎Preconditions

2020-12-08T05:32:08Z

‎Preconditions

2020-12-08T05:30:15Z

‎Problem

2020-12-08T05:29:34Z

‎Problem

2020-12-08T05:28:58Z

‎Problem

2020-12-08T05:21:46Z

‎Context

2020-12-08T05:20:09Z

‎Context

@@ Line 20: / Line 20: @@
 ==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.
+* 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==
 [[Category: Identifier]]

@@ Line 12: / Line 12: @@
 * This use case focuses on native user apps because of their access to the keystone in current smartphone operating systems.
-==Problem==
+==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.
 ==Preconditions==

@@ Line 10: / Line 10: @@
 ** 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.
 ==Problem==

@@ Line 18: / Line 18: @@
 ==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 use wallet if it can also store other credentials, but that is outside the scope of this use case.
+* 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==
 [[Category: Identifier]]

@@ Line 18: / Line 18: @@
 ==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 use wallet if it can also store other credentials, but that is outside the scope of this use case.
 ==References==
 [[Category: Identifier]]

@@ Line 8: / Line 8: @@
 * 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 will using Facebook to perform the same function.
+** 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.