[Openid-specs-ab] Initiating User Registration via OpenID Connect spec draft published

George Fletcher gffletch at aol.com
Mon Sep 30 21:24:01 UTC 2019


Resurrecting this thread. I'm somewhat concerned about requiring 
prompt=create meaning the OpenID Provider MUST create a new account. I'm 
OK with 'RECOMMENDED' wording that the user be taken to the account 
creation page. However, if say, the user enters an email address that is 
already an identity within the system the AS should be able to help the 
user get logged in and respond with a code to complete the 
authentication flow. In this context a new user is NOT created. The goal 
is to help the user get logged in; hopefully not with creating a brand 
new account if they user already has one. However, if the user selects 
something in the app that causes the client to send the parameter, the 
user should land on the "account creation" page rather than the "sign 
in" page.

Thoughts?

On 8/7/19 6:26 AM, Filip Skokan wrote:
> Comments inline as well
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 7 Aug 2019 at 15:11, George Fletcher <gffletch at aol.com 
> <mailto:gffletch at aol.com>> wrote:
>
>     Comments inline...
>
>     On 8/6/19 2:21 PM, Vittorio Bertocci wrote:
>>     Hey George,
>>     thank you for contributing this and moving this forward!
>>     I wanted to chime in and report on some discussions we had about
>>     this during IETF with Nat, John, Brian and Daniel, plus internal
>>     alignment I just reached with Filip.
>>
>>     - IMO this prompt value should not have hint semantic, but offer
>>     a guarantee to developers that (provided that OP supports this
>>     new prompt value, more later) either the operation led to the
>>     creation of a new account in the context of the RP (e.g. new sub)
>>     or it errors out (e.g. user cancelled). The scenario here is the
>>     client presenting affordances clearly stating intent to the user
>>     (e.g. "Sign up" button) and ensuring that the intent is preserved
>>     regardless of errors, unintentional SSO pre-empting showing sign
>>     up affordances and the like.
>     I think there are some use cases that Filip has raised that make
>     changing it from a hint difficult. What should the OP do if the
>     browser is already logged into a valid user? Do they log the user
>     out? Display an interstitial asking the user if they want to
>     logout to create a new account? I can see returning an error if
>     the 'create' value is combined with the 'none' value as a way to
>     check whether the environment will work to flow directly to create.
>
>
> FS: I am aligned with Vittorio on this, ultimately a `hint`-like 
> semantic does not fall in line with the other prompt values we have 
> today (they all bring assurances) and my preference would be to have 
> prompt=create used for guarantees as Vittorio described and a new 
> param defined for UI hints should they be needed. But at this point I 
> think the UI part is pretty much OP specific and doesn't really apply 
> to all.
>
> ?? > What should the OP do if the browser is already logged into a 
> valid user?
> That is already a ? for existing use of prompt=login. For one my 
> implementation, when the subject changes after "interactions", will 
> trigger a clean logout of the existing session including triggering 
> front/back channel mechanisms to let the RPs know.
>
> ?? > I can see returning an error if the 'create' value is combined 
> with the 'none' value as a way to check whether the environment will 
> work to flow directly to create.
> Given that any prompt combined with `none` results in an error already 
> this is not means for checking support.
>
>
>     From a mobile app perspective, my expectation is that the mobile
>     app would display some native UI that would ask the user whether
>     they want to 'sign in' or 'sign up' and then trigger the flow in
>     the system browser that way.
>>     - besides the "new sub" guarantee, which might not be easily
>>     verifiable by the client, there should be something in the
>>     resulting IDtoken proving that the OP understood/honored
>>     "create". Something like "created_at" would work
>     I'm ok with this if there is general consensus that it is useful.
>     For a mobile app, I don't think this provides much value. For a
>     server side RP, it might be more valuable though RPs should only
>     be using the iss:sub pair as a pointer to their internal identity
>     record :)
>>     - adding something like a collection of "prompt_values_supported"
>>     to the discovery doc might help to broadcast the OPs support for
>>     this and other future values
>     Yes, this makes sense.
>>
>>     WDYT???
>>
>>     On Tue, Aug 6, 2019 at 8:29 AM George Fletcher via
>>     Openid-specs-ab <openid-specs-ab at lists.openid.net
>>     <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>
>>         Thanks so much for the feedback. Duly noted for the next draft :)
>>
>>         On 8/6/19 9:30 AM, Filip Skokan wrote:
>>>         And some nits around the examples
>>>
>>>         - Figure 1 and 2 examples are not `openid` requests (missing
>>>         scope "openid")
>>>         - Figure 1 is not an OpenID Connect response_type (token)
>>>         - I think these figures can be reduced down to one, regular
>>>         code flow with openid scope.
>>>
>>>         Best,
>>>         *Filip Skokan*
>>>
>>>
>>>         On Tue, 6 Aug 2019 at 15:23, Filip Skokan
>>>         <panva.ip at gmail.com <mailto:panva.ip at gmail.com>> wrote:
>>>
>>>             Hello George, everyone,
>>>
>>>             Thank you for this note, I agree this hint is useful,
>>>             regardless of the form or shape it takes - a new
>>>             parameter or prompt value.
>>>
>>>             a couple points from my side
>>>
>>>                 For authorization requests sent as a JWTs, such as
>>>                 when using JWT Secured Authorization Request, a
>>>                 single prompt parameter value is represented as a
>>>                 JSON string *while multiple values are represented
>>>                 as an array of strings.*
>>>
>>>
>>>             Aside from `resource` which is a parameter that can be
>>>             passed multiple times all parameters (with maybe claims
>>>             as an exception) should be passed as JSON primitives
>>>             such as string (scope, client_id, ...) or number
>>>             (max_age) inside Request Objects. We could propose an
>>>             errata on the specific parameter handling inside Core
>>>             but I think the interoperable behaviour we have today is
>>>             that parameters such as scope or prompt that regularly
>>>             get values as space-delimited string of values are
>>>             passed the same way in a Request Object. As mentioned
>>>             the only exception is `claims` which makes sense to pass
>>>             as a JSON object and `resource` which is allowed to be
>>>             passed multiple times e.g.
>>>             `&resource=urn:example:foo&resource=urn:example:foo2`.
>>>
>>>                 If the OpenID Provider fails to parse the provided
>>>                 value(s) it should ignore the prompt parameter value
>>>                 and proceed as if the prompt parameter was not
>>>                 specified.
>>>
>>>
>>>             At the moment I believe it's up to each implementer to
>>>             either be strict in checking supported `prompt` values
>>>             or lax and simply ignoring unsupported values. I think
>>>             this would be worth clarifying in Core, since this and
>>>             possible future `prompt` values may have behaviours tied
>>>             to them and ignoring a provided but not supported prompt
>>>             value could lead to confusion.
>>>
>>>             I'd like to propose that the draft focuses on the actual
>>>             new value and its semantics and strays away from
>>>             defining new authorization request and request object
>>>             processing rules of existing parameters.
>>>
>>>             Best,
>>>             *Filip Skokan*
>>>
>>>
>>>             On Tue, 6 Aug 2019 at 14:47, George Fletcher via
>>>             Openid-specs-ab <openid-specs-ab at lists.openid.net
>>>             <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>>
>>>                 The Initiating User Registration via OpenID Connect
>>>                 draft has been
>>>                 published here:
>>>
>>>                 https://openid.net/specs/openid-connect-prompt-create-1_0.html
>>>
>>>                 This very simple extension to the prompt parameter
>>>                 allows the client to
>>>                 indicate to the OpenID Provider that the user
>>>                 requested to be sent
>>>                 through the registeration/signup flow rather than be
>>>                 shown the
>>>                 authentication screen and have to find the "create
>>>                 new account" option.
>>>
>>>                 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
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190930/1f43b6d1/attachment-0001.html>


More information about the Openid-specs-ab mailing list