<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Comments inline...</font><br>
<br>
<div class="moz-cite-prefix">On 8/6/19 2:21 PM, Vittorio Bertocci
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO_FVe5qxnh3+2EeAY46uT=9cSumd1jWNhOp9rxmSUSyHaeC2A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hey George,
<div>thank you for contributing this and moving this forward!</div>
<div>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.</div>
<div><br>
</div>
<div>- 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.<br>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<blockquote type="cite"
cite="mid:CAO_FVe5qxnh3+2EeAY46uT=9cSumd1jWNhOp9rxmSUSyHaeC2A@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>- 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<br>
</div>
</div>
</div>
</blockquote>
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 :)<br>
<blockquote type="cite"
cite="mid:CAO_FVe5qxnh3+2EeAY46uT=9cSumd1jWNhOp9rxmSUSyHaeC2A@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>- 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</div>
</div>
</div>
</blockquote>
Yes, this makes sense.<br>
<blockquote type="cite"
cite="mid:CAO_FVe5qxnh3+2EeAY46uT=9cSumd1jWNhOp9rxmSUSyHaeC2A@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>WDYT???</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Aug 6, 2019 at 8:29
AM George Fletcher via Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net"
moz-do-not-send="true">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">
<div bgcolor="#FFFFFF"> <font face="Helvetica, Arial,
sans-serif">Thanks so much for the feedback. Duly noted
for the next draft :)</font><br>
<br>
<div class="gmail-m_-3536630719421467512moz-cite-prefix">On
8/6/19 9:30 AM, Filip Skokan wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">And some nits around the examples
<div><br>
</div>
<div>- Figure 1 and 2 examples are not `openid`
requests (missing scope "openid")</div>
<div>- Figure 1 is not an OpenID Connect response_type
(token)</div>
<div>- I think these figures can be reduced down to
one, regular code flow with openid scope.</div>
<div><br clear="all">
<div>
<div dir="ltr"
class="gmail-m_-3536630719421467512gmail_signature">Best,<br>
<b>Filip Skokan</b></div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 6 Aug 2019
at 15:23, Filip Skokan <<a
href="mailto:panva.ip@gmail.com" target="_blank"
moz-do-not-send="true">panva.ip@gmail.com</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">
<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-m_-3536630719421467512gmail-m_-2303894390680212269gmail_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"
target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre class="gmail-m_-3536630719421467512moz-signature" cols="72">--
Identity Standards Architect
Verizon Media Work: <a class="gmail-m_-3536630719421467512moz-txt-link-abbreviated" href="mailto:george.fletcher@oath.com" target="_blank" moz-do-not-send="true">george.fletcher@oath.com</a>
Mobile: +1-703-462-3494 Twitter: <a class="gmail-m_-3536630719421467512moz-txt-link-freetext" href="http://twitter.com/gffletch" target="_blank" moz-do-not-send="true">http://twitter.com/gffletch</a>
Office: +1-703-265-2544 Photos: <a class="gmail-m_-3536630719421467512moz-txt-link-freetext" href="http://georgefletcher.photography" target="_blank" moz-do-not-send="true">http://georgefletcher.photography</a>
</pre>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Identity Standards Architect
Verizon Media Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@oath.com">george.fletcher@oath.com</a>
Mobile: +1-703-462-3494 Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
Office: +1-703-265-2544 Photos: <a class="moz-txt-link-freetext" href="http://georgefletcher.photography">http://georgefletcher.photography</a>
</pre>
</body>
</html>