<div dir="ltr"><div>Hello George, everyone,</div><div><br></div><div>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.</div><div><br></div><div>a couple points from my side</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <b>while multiple values are represented as an array of strings.</b></blockquote><div><br></div><div>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`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Best,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Aug 2019 at 14:47, George Fletcher via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The Initiating User Registration via OpenID Connect draft has been <br>
published here:<br>
<br>
<a href="https://openid.net/specs/openid-connect-prompt-create-1_0.html" rel="noreferrer" target="_blank">https://openid.net/specs/openid-connect-prompt-create-1_0.html</a><br>
<br>
This very simple extension to the prompt parameter allows the client to <br>
indicate to the OpenID Provider that the user requested to be sent <br>
through the registeration/signup flow rather than be shown the <br>
authentication screen and have to find the "create new account" option.<br>
<br>
Feedback greatly appreciated!<br>
<br>
Thanks,<br>
George<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>