<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>A mapping like the one you propose can definitely work. Since the
      user will be making the choice which endpoint to take with the
      client app, having the logo_uri is a good idea. If the branded
      endpoints differ somehow in policy one could also allow inclusion
      of the op_policy_uri and op_tos_uri params from Discovery.</p>
    <p><a class="moz-txt-link-freetext" href="https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery">https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery</a></p>
    <p>Vladimir<br>
    </p>
    <div class="moz-cite-prefix">On 20/05/2020 19:16, Joseph Heenan
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:72D97116-747B-47FE-A4D7-E729B708E723@fintechlabs.io">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Thanks for your thoughts Vladimir!
      <div class=""><br class="">
      </div>
      <div class="">The client_id based solution I wasn’t previously
        aware of - unfortunately it doesn’t solve the problem for
        app2app, as the mobile OS selects the app to use based purely on
        the URL (and in at least the iOS case will not offer the user a
        choice if multiple apps claim to handle the same url).</div>
      <div class=""><br class="">
      </div>
      <div class="">I think some kind of mapping like you suggest will
        work and fallback, I wonder about a structure in the
        authorization server metadata something like this:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div class="">{</div>
        <div class="">  ...</div>
        <div class="">  "alternative_authorization_endpoints": [</div>
        <div class="">    {</div>
        <div class="">      "authorization_endpoint": "<a
            href="https://loadsamoney/business/auth" class=""
            moz-do-not-send="true">https://loadsamoney/business/auth</a>",</div>
        <div class="">      "description": "loadsmoney business banking
          customers",</div>
        <div class="">      "logo_url": "<a
            href="https://loadsamoney/business/logo.png" class=""
            moz-do-not-send="true">https://loadsamoney/business/logo.png</a>"</div>
        <div class="">    },</div>
        <div class="">    {</div>
        <div class="">      "authorization_endpoint": "<a
            href="https://loadsamoney/consumer/auth" class=""
            moz-do-not-send="true">https://loadsamoney/consumer/auth</a>",</div>
        <div class="">      "description": "loadsmoney personal
          customers",</div>
        <div class="">      "logo_url": "<a
            href="https://loadsamoney/consumer/logo.png" class=""
            moz-do-not-send="true">https://loadsamoney/consumer/logo.png</a>"</div>
        <div class="">    }</div>
        <div class="">  ]</div>
        <div class="">}</div>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">And as you say, the existing authorization_endpoint
        can be a fallback for clients that are unaware of the new spec
        or prefer the simpler option of just using a single
        authorization endpoint. Supporting the new spec would allow a
        better UX though so there’s advantages to client to do so.</div>
      <div class="">
        <blockquote type="cite" class="">
          <div class="">
            <p class="">Speaking of mTLS, I'm not sure how the
              "mtls_endpoint_aliases" can be sensibly combined with the
              proposed multi-brand spec.</p>
          </div>
        </blockquote>
      </div>
      <div class="">
        <div class="">
          <p class="">I think that particular part is not really an
            issue as mtls isn’t used at the authorization endpoint.</p>
        </div>
      </div>
      <div class="">Thanks</div>
      <div class=""><br class="">
      </div>
      <div class="">Joseph</div>
      <div class=""><br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On 20 May 2020, at 16:07, Vladimir Dzhuvinov
              <<a href="mailto:vladimir@connect2id.com" class=""
                moz-do-not-send="true">vladimir@connect2id.com</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8" class="">
              <div class="">
                <p class="">Hi Dave,</p>
                <p class="">In the absence of such a "multi-brand" spec
                  we have tackled this issue in the past by letting the
                  "brand" be encoded in the client_id. An alternative
                  scenario is to do a "brand" lookup by client_id. Then
                  let the AS render the "branded" authZ endpoint.</p>
                <p class="">You're probably aware the mTLS spec is
                  allowing for endpoint aliases, so this is not the
                  first time such as need has occurred:</p>
                <p class=""><a class="moz-txt-link-freetext"
                    href="https://tools.ietf.org/html/rfc8705#section-5"
                    moz-do-not-send="true">https://tools.ietf.org/html/rfc8705#section-5</a></p>
                <p class="">One could devise a similar JSON object with
                  mappings "label" - "authorization_endpoint".</p>
                <p class="">Clients that are aware of the new spec will
                  look it up, those that are not will fall back to the
                  std "authorization_endpoint".</p>
                <p class="">Speaking of mTLS, I'm not sure how the
                  "mtls_endpoint_aliases" can be sensibly combined with
                  the proposed multi-brand spec.</p>
                <p class=""><br class="">
                </p>
                <p class="">Vladimir<br class="">
                </p>
                <p class=""><br class="">
                </p>
                <div class="moz-cite-prefix">On 20/05/2020 15:07, Dave
                  Tonge wrote:<br class="">
                </div>
                <blockquote type="cite"
cite="mid:CAP-T6TTehOT7U_fniZdHsei1C1phOWQfK7o=fHSNciXSTjviPA@mail.gmail.com"
                  class="">
                  <meta http-equiv="content-type" content="text/html;
                    charset=UTF-8" class="">
                  <div dir="ltr" class="">
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif">Dear
                      OAuth WG</div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><br
                        class="">
                    </div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif">We
                      have an <a
href="https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request"
                        moz-do-not-send="true" class="">issue</a> in the
                      OpenID FAPI Working Group that we believe affects
                      the wider OAuth community.</div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><br
                        class="">
                    </div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif">In
                      summary: <b class="">what is the recommended
                        approach to discovery (RFC8414) for
                        Authorization Servers who support multiple
                        "brands" .</b></div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><br
                        class="">
                    </div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif">If
                      brands are completely separate, then it seems
                      sensible that each brand must have its own
                      `issuer` and therefore its own discovery document
                      at the correct location (i.e. brand 1 would have
                      an issuer of "<a href="https://as/brand1"
                        moz-do-not-send="true" class="">https://as/brand1</a>"
                      and a discovery document available at  <a
                        href="https://as/.well-known/"
                        moz-do-not-send="true" class="">https://as/.well-known/</a><span
                        style="font-size: 13.3333px; font-family: Arial,
                        Helvetica, sans-serif;" class="">oauth-authorization-server/brand1).</span></div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><span
                        style="font-size: 13.3333px; font-family: Arial,
                        Helvetica, sans-serif;" class=""><br class="">
                      </span></div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><span
                        style="font-size: 13.3333px; font-family: Arial,
                        Helvetica, sans-serif;" class="">However in the
                        real world it is not always so simple. We have
                        many existing implementations in UK open banking
                        that support multiple authorization endpoints.
                        Here is an example (thanks to <a
                          class="gmail_plusreply" id="plusReplyChip-4"
                          href="mailto:joseph.heenan@fintechlabs.io"
                          tabindex="-1" moz-do-not-send="true">@Joseph
                          Heenan</a> )</span></div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><span
                        style="font-size: 13.3333px; font-family: Arial,
                        Helvetica, sans-serif;" class=""><br class="">
                      </span></div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif">>
                      Bank “loadsamoney” has one idp and, for internet
                      banking, one “login page” for both business and
                      personal customers.<br class="">
                      <br class="">
                      > They have separate mobile apps for
                      business/personal, and are required to support
                      app2app. This means they will definitely be
                      exposing multiple authorization endpoints (as
                      there’s a 1:1 mapping of authorization endpoints
                      to mobile apps) - the choice is how they do this.<br
                        class="">
                      <br class="">
                      > Their choices are:<br class="">
                      <br class="">
                      > 1. Multiple discovery endpoints (one for
                      business, one for personal), each with a different
                      authorization endpoint, multiple issuers (if their
                      vendor allows this)<br class="">
                      > 2. Single discovery endpoint, single issuer,
                      multiple authorization endpoints listed in one
                      discovery doc (one for business, one for personal)
                      some of which are hardcoded by the 3rd party<br
                        class="">
                      > 3. Multiple discovery endpoints each with a
                      different authorization endpoint, same issuer in
                      all cases (breaks RFC8414 and OIDC Discovery)<br
                        class="">
                    </div>
                    <div class=""><br class="">
                    </div>
                    <div class="">
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">Option 3 is invalid and
                        that leaves us with options 1 and 2. </div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">Option 1 can be problematic
                        as often it is in reality the same `issuer`
                        behind the scenes.</div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif"><br class="">
                      </div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">We would like to get
                        feedback on this issue and potentially an
                        extension to RFC8414 to allow the definition of
                        multiple authorization endpoints.</div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif"><br class="">
                      </div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">Thanks in advance</div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif"><br class="">
                      </div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">Dave Tonge</div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">Co-Chair FAPI WG</div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif">Open ID Foundation</div>
                      <div class="gmail_default"
                        style="font-family:"trebuchet
                        ms",sans-serif"><br class="">
                      </div>
                    </div>
                    <div class="gmail_default"
                      style="font-family:trebuchet ms,sans-serif"><br
                        class="">
                    </div>
                  </div>
                </blockquote>
                <br class="">
              </div>
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Vladimir Dzhuvinov</pre>
  </body>
</html>