[Openid-specs-fapi] Issue #255: certification clarification request: location of discovery document (openid/fapi)

josephheenan issues-reply at bitbucket.org
Tue Jul 23 10:56:12 UTC 2019


New issue 255: certification clarification request: location of discovery document
https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request

Joseph Heenan:

The FAPI conformance suite currently has a test that checks the following clause from [https://openid.net/specs/openid-connect-discovery-1\_0.html#ProviderConfig](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) :

> OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string `/.well-known/openid-configuration` to the Issuer.

The check retrieves the discovery document, gets the issuer, then checks if url the discovery document came from is ISSUER/.well-known/openid-configuration

The reason for adding this check was that previous discussions on the FAPI WG had revealed that this spec clause was a protection against phishing attacks where the client developer could be fooled into using an incorrect discovery doc which would then \(for example\) allow man-in-the-middle attacks by changing the token endpoint to an attacker-controlled one.

This check seems to be causing issues within the UK OpenBanking ecosystem. Banks are frequently defining multiple discovery endpoints, all of which ultimately point at one authorization server that has a single issuer.

For example:

[https://auth.ob.bankofireland.com/oauth/as/b365/.well-known/openid-configuration](https://auth.ob.bankofireland.com/oauth/as/b365/.well-known/openid-configuration)

[https://auth.ob.bankofireland.com/oauth/as/bol/.well-known/openid-configuration](https://auth.ob.bankofireland.com/oauth/as/bol/.well-known/openid-configuration)

[https://auth.obapi.bankofireland.com/oauth/as/b365/.well-known/openid-configuration](https://auth.obapi.bankofireland.com/oauth/as/b365/.well-known/openid-configuration)

[https://auth.obapi.bankofireland.com/oauth/as/bol/.well-known/openid-configuration](https://auth.obapi.bankofireland.com/oauth/as/bol/.well-known/openid-configuration)

all have the issuer value [https://auth.obapi.bankofireland.com](https://auth.obapi.bankofireland.com) and hence fail the check. Other banks \(e.g. Barclays\) appear to have similar setups.

The reason banks are doing this is I believe primarily because they have different brands on the same backend systems, and hence want to show the correct branding to the user for the brand the user is trying to log in to - the problem becomes particularly acute with app2app, where there are different apps for each brand and hence the Authorization Endpoint url must be unique for each brand so that the correct app is launched \(as each url must be claimed by no more than one app so the mobile OS knows which app to launch\).

I am not sure if the check is an overreach \(the above spec clause doesn’t appear to rule out that other discovery documents are made available at different paths\); but it that was the case then there’s no protection against the potential phishing attacks.

Clarification on how the FAPI WG views this situation would be greatly appreciated.




More information about the Openid-specs-fapi mailing list