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

[George Fletcher]

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
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/20190806/cdd6b501/attachment.html>