<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">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">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">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">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="m_7569543702985805722gmail-m_9202707321501439989gmail-m_-3536630719421467512moz-signature" cols="72">-- 
Identity Standards Architect
Verizon Media                     Work: <a class="m_7569543702985805722gmail-m_9202707321501439989gmail-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="m_7569543702985805722gmail-m_9202707321501439989gmail-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="m_7569543702985805722gmail-m_9202707321501439989gmail-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>
    </blockquote>
    <br>
    <pre class="m_7569543702985805722gmail-m_9202707321501439989moz-signature" cols="72">-- 
Identity Standards Architect
Verizon Media                     Work: <a class="m_7569543702985805722gmail-m_9202707321501439989moz-txt-link-abbreviated" href="mailto:george.fletcher@oath.com" target="_blank">george.fletcher@oath.com</a>
Mobile: +1-703-462-3494           Twitter: <a class="m_7569543702985805722gmail-m_9202707321501439989moz-txt-link-freetext" href="http://twitter.com/gffletch" target="_blank">http://twitter.com/gffletch</a>
Office: +1-703-265-2544           Photos: <a class="m_7569543702985805722gmail-m_9202707321501439989moz-txt-link-freetext" href="http://georgefletcher.photography" target="_blank">http://georgefletcher.photography</a>
</pre>
  </div>

</blockquote></div></div>