<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">Resurrecting this thread.
I'm somewhat concerned about requiring prompt=create meaning the
OpenID Provider MUST create a new account. I'm OK with
'RECOMMENDED' wording that the user be taken to the account
creation page. However, if say, the user enters an email address
that is already an identity within the system the AS should be
able to help the user get logged in and respond with a code to
complete the authentication flow. In this context a new user is
NOT created. The goal is to help the user get logged in; hopefully
not with creating a brand new account if they user already has
one. However, if the user selects something in the app that causes
the client to send the parameter, the user should land on the
"account creation" page rather than the "sign in" page.<br>
<br>
Thoughts?<br>
</font><br>
<div class="moz-cite-prefix">On 8/7/19 6:26 AM, Filip Skokan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALAqi_9=SO0=RL7rtiPOXYzepgS=VeTaFEKYzDKRKmnzpE3CGA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div>Comments inline as well</div>
<br clear="all">
<div>
<div dir="ltr" class="m_7569543702985805722gmail_signature"
data-smartmail="gmail_signature">S pozdravem,<br>
<b>Filip Skokan</b></div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 7 Aug 2019 at 15:11,
George Fletcher <<a href="mailto:gffletch@aol.com"
target="_blank" moz-do-not-send="true">gffletch@aol.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 bgcolor="#FFFFFF"> <font face="Helvetica, Arial,
sans-serif">Comments inline...</font><br>
<br>
<div
class="m_7569543702985805722gmail-m_9202707321501439989moz-cite-prefix">On
8/6/19 2:21 PM, Vittorio Bertocci wrote:<br>
</div>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div><br>
</div>
<div>FS: I am aligned with Vittorio on this, ultimately a
`hint`-like semantic does not fall in line with the other
prompt values we have today (they all bring assurances) and
my preference would be to have prompt=create used for
guarantees as Vittorio described and a new param defined for
UI hints should they be needed. But at this point I think
the UI part is pretty much OP specific and doesn't really
apply to all.</div>
<div><br>
</div>
<div>?? > What should the OP do if the browser is already
logged into a valid user?</div>
<div>That is already a ? for existing use of prompt=login. For
one my implementation, when the subject changes after
"interactions", will trigger a clean logout of the existing
session including triggering front/back channel mechanisms
to let the RPs know.</div>
<div><br>
</div>
<div>?? > 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.</div>
<div>Given that any prompt combined with `none` results in an
error already this is not means for checking support.</div>
<div>??</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"> <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">
<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">
<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">
<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"
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">
<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="m_7569543702985805722gmail-m_9202707321501439989gmail-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="m_7569543702985805722gmail-m_9202707321501439989gmail-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="m_7569543702985805722gmail-m_9202707321501439989gmail-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>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>