<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Dave,</p>
<p>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>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><a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc8705#section-5">https://tools.ietf.org/html/rfc8705#section-5</a></p>
<p>One could devise a similar JSON object with mappings "label" -
"authorization_endpoint".</p>
<p>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>Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases"
can be sensibly combined with the proposed multi-brand spec.</p>
<p><br>
</p>
<p>Vladimir<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 20/05/2020 15:07, Dave Tonge wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAP-T6TTehOT7U_fniZdHsei1C1phOWQfK7o=fHSNciXSTjviPA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<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>
</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">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>
</div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif">In summary: <b>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>
</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">https://as/brand1</a>"
and a discovery document available at <a
href="https://as/.well-known/" moz-do-not-send="true">https://as/.well-known/</a><span
style="color:rgb(0,0,0);font-size:13.3333px;font-family:Arial,Helvetica,sans-serif">oauth-authorization-server/brand1).</span></div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif"><span
style="color:rgb(0,0,0);font-size:13.3333px;font-family:Arial,Helvetica,sans-serif"><br>
</span></div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif"><span
style="color:rgb(0,0,0);font-size:13.3333px;font-family:Arial,Helvetica,sans-serif">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="color:rgb(0,0,0);font-size:13.3333px;font-family:Arial,Helvetica,sans-serif"><br>
</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>
<br>
> 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>
<br>
> Their choices are:<br>
<br>
> 1. Multiple discovery endpoints (one for business, one
for personal), each with a different authorization endpoint,
multiple issuers (if their vendor allows this)<br>
> 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>
> 3. Multiple discovery endpoints each with a different
authorization endpoint, same issuer in all cases (breaks
RFC8414 and OIDC Discovery)<br>
</div>
<div><br>
</div>
<div>
<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>
</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>
</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>
</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>
</div>
</div>
<div class="gmail_default" style="font-family:trebuchet
ms,sans-serif"><br>
</div>
</div>
</blockquote>
<br>
</body>
</html>