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

George Fletcher gffletch at aol.com
Wed Aug 7 13:11:05 UTC 2019


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.

 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
>>
>
>     -- 
>     Identity Standards Architect
>     Verizon Media                     Work:george.fletcher at oath.com  <mailto:george.fletcher at oath.com>
>     Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
>     Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>
>     _______________________________________________
>     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/20190807/bf666255/attachment.html>


More information about the Openid-specs-ab mailing list