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

Vittorio Bertocci vittorio.bertocci at auth0.com
Tue Aug 6 18:21:13 UTC 2019


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.
- 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
- 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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190806/51121805/attachment-0001.html>


More information about the Openid-specs-ab mailing list