<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>