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

Filip Skokan panva.ip at gmail.com
Tue Aug 6 13:30:24 UTC 2019

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.

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

More information about the Openid-specs-ab mailing list