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

Filip Skokan panva.ip at gmail.com
Wed Aug 7 13:26:45 UTC 2019


Comments inline as well

S pozdravem,
*Filip Skokan*


On Wed, 7 Aug 2019 at 15:11, George Fletcher <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> 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> 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> 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
>>>> 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
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> 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/395af2b9/attachment-0001.html>


More information about the Openid-specs-ab mailing list