[Openid-specs-ab] Alternative authorization endpoints in discovery doc / server metadata

Joseph Heenan joseph at authlete.com
Wed Jun 3 17:07:20 UTC 2020

Hi all,

One of the discussions on the FAPI working group:

https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request <https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request>

Eventually gave rise to a thread on the OAuth WG:

https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=RDtr2l-e3CxlXpcHobqiieessG8 <https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=RDtr2l-e3CxlXpcHobqiieessG8>

The FAPI WG thought it’d be a good idea to give the connect working group a heads up as well, as it firmly crosses into the area the OIDC discovery spec covers.

In particular there appears to be a possible consensus forming around adding a sub structure something like this to the discovery document:

"alternative_authorization_endpoints": {
    "banking": {
      "authorization_endpoint": "https://loadsamoney/business/auth",
      "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
    "personal": {
      "authorization_endpoint": "https://loadsamoney/consumer/auth",
      "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
This solves at least two issues:

1) Allowing a single authorisation server for companies that have several distinct brands

2) A similar issue where there’s only one brand but there’s segmented user bases that have different mobile apps and app2app is in use, which then requires distinct authorization endpoints for the two apps.

Any thoughts are most welcome.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200603/365d8e02/attachment.html>

More information about the Openid-specs-ab mailing list