<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>- 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>- 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><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">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">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">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>
        </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">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">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">http://georgefletcher.photography</a>
</pre>
  </div>

_______________________________________________<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></div>