<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">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">https://as/brand1</a>" and a discovery document available at  <a href="https://as/.well-known/">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">@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 class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div></div>