[Openid-specs-fapi] Issuers, Discovery Docs & Brands

Dave Tonge dave.tonge at momentumft.co.uk
Wed May 20 12:07:09 UTC 2020


Dear OAuth WG

We have an issue
<https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request>
in the OpenID FAPI Working Group that we believe affects the wider OAuth
community.

In summary: *what is the recommended approach to discovery (RFC8414) for
Authorization Servers who support multiple "brands" .*

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 "https://as/brand1"
and a discovery document available at  https://as/.well-known/
oauth-authorization-server/brand1).

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 @Joseph Heenan
<joseph.heenan at fintechlabs.io> )

> Bank “loadsamoney” has one idp and, for internet banking, one “login
page” for both business and personal customers.

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

> Their choices are:

> 1. Multiple discovery endpoints (one for business, one for personal),
each with a different authorization endpoint, multiple issuers (if their
vendor allows this)
> 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
> 3. Multiple discovery endpoints each with a different authorization
endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)

Option 3 is invalid and that leaves us with options 1 and 2.
Option 1 can be problematic as often it is in reality the same `issuer`
behind the scenes.

We would like to get feedback on this issue and potentially an extension to
RFC8414 to allow the definition of multiple authorization endpoints.

Thanks in advance

Dave Tonge
Co-Chair FAPI WG
Open ID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200520/da54bc10/attachment.html>


More information about the Openid-specs-fapi mailing list