[Openid-specs-ab] Submission: prompt=create draft spec
George Fletcher
gffletch at aol.com
Fri Feb 1 17:31:10 UTC 2019
I thought about a different parameter, but I'm not crazy about adding
parameters if we don't need to. I'm open to feedback here though:)
I'm not sure it's always the case that using an existing session is
better than creating a new one. For example, a use case where multiple
people use the same device. In that context, if the user says they want
to create a new identity, and a session exists for a different person,
using that existing session silently is not good.
Thanks,
George
On 2/1/19 12:02 PM, Filip Skokan wrote:
> Hello George,
>
> i’m torn about using a prompt parameter for this. An OP may already
> have a session established and this would prevent it being used. A
> common authz pipeline will halt the request processing when prompt
> parameter is encountered.
>
> In the past we’ve dealt with this using a custom parameter
> when_anonymous=login/register (pick one, default to OP policy).
>
> This would tell the OP the client’s preference in the initial view
> *only in case there’s no session*, since having a session and hitting
> just the consent screen is preferred over both login and registration.
>
> Best,
> Filip
>
> Odesláno z iPhonu
>
> 1. 2. 2019 v 16:54, George Fletcher via Openid-specs-ab
> <openid-specs-ab at lists.openid.net
> <mailto:openid-specs-ab at lists.openid.net>>:
>
>> So we've run into situation in our mobile apps where the app allows
>> the user to choose "sign up" and we want to skip the login form
>> completely. This allows the app (if it chooses) to present a native
>> button for sign up rather than just sending the user to the OP login
>> form and having the user "hunt" for the signup link to click it.
>>
>> Just as an example, on first launch of an app that may require
>> authentication, having the app show a native UI that allows the user
>> to choose (login with existing identity or create a new one) can be
>> helpful to the user.
>>
>> Thanks,
>> George
>>
>> On 1/31/19 7:40 PM, Brock Allen wrote:
>>> Do you have a concrete example of how a client would know to send
>>> prompt=create?
>>>
>>> I ask because my first reaction is that given the client doesn't
>>> authenticate the user, it has no idea if the user has an account or
>>> not, so how/why would it know to send this value?
>>>
>>> Or are you simply imaging the scenario where the client shows a
>>> "login" or "register" link, rather than getting the OP to do that?
>>>
>>> -Brock
>>>
>>>> On 1/31/2019 3:46:26 PM, George Fletcher via Openid-specs-ab
>>>> <openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>> Thanks so much for the quick feedback William! Comments inline...
>>>>
>>>> On 1/31/19 12:45 PM, William Denniss wrote:
>>>>> Hi George,
>>>>>
>>>>> Some quick review thoughts:
>>>>>
>>>>> Section 4 Why is there a prohibition on combining "create" with
>>>>> other prompt values? What if a future prompt value was added that
>>>>> was compatible with "create"?
>>>> My thinking (though I'm open to options) is that there are many
>>>> values that can be mutually exclusive. For example, what does
>>>> prompt="create consent" mean? I'm happy to reduce this to SHOULD to
>>>> allow for future possibilities. Or change the wording to explain
>>>> that other prompt values that conflict with "create" should not be
>>>> used.
>>>>>
>>>>> Section 4.1, "the account creation experience" isn't defined by
>>>>> any OpenID spec, so requiring it with a MUST could be problematic.
>>>>> Also, most guidance on the UI shown by the OP is generally in the
>>>>> form of recommendations not normative requirements (e.g. around
>>>>> scope consent screens).
>>>> OK, I'm fine changing this to a SHOULD if that makes things more
>>>> acceptable :)
>>>>>
>>>>> As background, how would you expect this to be shown on the
>>>>> client? Two different buttons, one to connect an existing account,
>>>>> one to create a new account? Might be worth a non-normative
>>>>> discussion in the doc about how the clients might use this.
>>>> More or less, yes:) There are some use cases where the client may
>>>> want to allow the user to choose between the options (sign-up vs
>>>> sign-in) before starting the authentication flow. I don't think it
>>>> precludes the OP from having to know that a client started an
>>>> authenticate flow, the user chose the sign-up link/button and then
>>>> at the end of registration the OP needs to redirect back to the
>>>> client with a code. However, it does allow the client to optimize
>>>> the experience.
>>>>
>>>> Thanks again,
>>>> George
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>> On Thu, Jan 31, 2019 at 9:19 AM George Fletcher via
>>>>> Openid-specs-ab <openid-specs-ab at lists.openid.net
>>>>> <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>>>>
>>>>> I've attached both the XML and Text versions of a very small
>>>>> spec that
>>>>> defines a new parameter value for the 'prompt' parameter that
>>>>> allows the
>>>>> client to request the user go directly to the account creation
>>>>> flow and
>>>>> when the user has successfully created the account, return a
>>>>> 'code' to
>>>>> the client. This improves the user experience by allowing the
>>>>> client to
>>>>> direct the user directly to the account creation page.
>>>>>
>>>>> Feedback greatly appreciated!
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> <mailto:Openid-specs-ab at lists.openid.net>
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
--
Identity Standards Architect
Verizon Media Work: george.fletcher at oath.com
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190201/9158e7db/attachment.html>
More information about the Openid-specs-ab
mailing list