Discovery Metadata for mtls

[Ralph Bragg]

Clause 1.0 for the authorization servers requires banks to use a discovery document defined in OIDD and RFC8414 however additional specific metadata claims are introduced as part of mtls https://datatracker.ietf.org/doc/html/rfc8705

Given that the majority of FAPI endpoints require MTLS (or dpop) can we please make explicit reference to requiring mtls alias’s to be advertised by authorisation servers.

This provision was included in the Brazil Open Banking Security Profile. It is possible to ‘optionally’ have the client present a certificate however for the sake of clarity and ease of implementation making this a must for users of FAPI 2.0 that adopt mtls would reduce fragmentation.

   mtls_endpoint_aliases
      OPTIONAL.  A JSON object containing alternative authorization
      server endpoints that, when present, an OAuth client intending to
      do mutual TLS uses in preference to the conventional endpoints.
      The parameter value itself consists of one or more endpoint
      parameters, such as "token_endpoint", "revocation_endpoint",
      "introspection_endpoint", etc., conventionally defined for the top
      level of authorization server metadata.  An OAuth client intending
      to do mutual TLS (for OAuth client authentication and/or to
      acquire or use certificate-bound tokens) when making a request
      directly to the authorization server MUST use the alias URL of the
      endpoint within the "mtls_endpoint_aliases", when present, in
      preference to the endpoint URL of the same name at the top level
      of metadata.

‌

‌

[Nat Sakimura]

June 2 call pointed out that the support of alias would not help interoperability. The majority of FAPI implementation does not support MTLS alias endpoint.

To be discussed with Ralph.

[Ralph Bragg]

I’m a bit puzzled by that statement that this would cause implementation issues for FAPI Banks. the majority of banks (I’ve seen) implementations just host a static file for discovery rather than serve from their providers. Migrating to correctly advertising endpoints that must have mutual tls certificates on them would only affect TPPs. (Relying parties). Which could incorporate the changes in a non breaking way. Ie “advertise the mtls alias”, tell RPs to use them, remove the hacks.

I’m OK if this isn’t explicitly called out by FAPI, it has been by FAPI Brazil so by the end of it there won’t be any clients that have issues with them.

There is a requirement for Authorization servers to support the mtls rfc. If the Authorization server chooses to support mtls aliases on their well known then the client MUST honour them this is part of the mtls rfc.

Provided that the conformance suite sorts out its intermittent support for mtls aliases and correctly implements mtls alias requirement then this is fine.

The primary reason behind this was that communicating alternative mtls endpoints was one of the issues that banks In the U.K. ecosystem had. If you look at several of the banks discovery documents, they advertise a mutual tls enforcing token endpoint on the discovery document, but then I know that they then tell other clients that don’t use mtls to use a different end point that isn’t on discovery.

Technically addressing this bad behaviour is covered by the clause that requires only oidc discovery to be used to convey endpoint information. However because this won’t affect TPPs and that the “hidden token endpoint” isn’t surfaced by anyone likely to point out that there is a perfectly good spec that mitigates this issue then I was wondering if this group wants to tell banks how to do this properly.

[Takahiko Kawasaki]

Open Banking Brasil Financial-grade API 1.0 Dynamic Client Registration Implementers Draft 1 (written by Ralph) includes the following requirements.

6.1. Authorization server

5. shall advertise mtls_endpoint_aliases as per clause 5 [RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens][RF8705] the token_endpoint, registration_endpoint and userinfo_endpoint;¶

6. if supporting OAuth 2.0 Pushed Authorisation Requests shall advertise through OIDD mtls_endpoint_aliases the pushed_authorization_request_endpoint;

7. if supporting Financial API - Client Initiated Back Channel Authentication shall advertise through OIDD mtls_endpoint_aliases the backchannel_authentication_endpoint;

and

6.2. Client

3. where present, shall use endpoints advertised in mtls_endpoint_aliases as per clause 5 [RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens][RF8705];

It seems that these requirements are wisdom obtained through the experience of UK Open Banking.

However, because FAPI 2.0 allows DPoP as an implementation of “sender-constrained” access tokens and allows private_key_jwt as a client authentication method (both do not require a mutual-TLS connection), endpoints do not necessarily have to require mutual-TLS connections.

It may be beneficial to mention mtls_endpoint_aliases in the FAPI 2.0 Baseline. However, unless we drop DPoP and private_key_jwt, mentioning mtls_endpoint_alias won’t contribute to reducing fragmentation so much.

[Ralph Bragg]

What needs to be clear is that if an Authorization server is relying on mtls for sender constrained access tokens and implements and advertise mtls aliases. Are client obliged to use them for both tls_client_auth and private_key_jwt. It makes sense that if you need a mtls channel as defined by the mtls spec and the spec says you advertise end point channels that have this defined then the client has to use them.

the explicit definition of the tls properties of endpoints is great. What’s not clear is the obligations to support this part of the mtls rfc when you’re only using sender constraining elements of the specification.

[Dave Tonge]

I think we need to discuss whether this can be solved by a conformance test or whether we need anything in the spec

[Dave Tonge]

We agreed to postpone this to the 2nd implementers draft

[Dave Tonge]

I think the mutual TLS spec already covers this?

An OAuth client intending to do mutual TLS (for OAuth client authentication and/or to acquire or use certificate-bound tokens) when making a request directly to the authorization server MUST use the alias URL of the endpoint within the "mtls_endpoint_aliases", when present, in preference to the endpoint URL of the same name at the top level of metadata.

‌

[Ralph Bragg]

I don’t believe it does, if you’re using private_key_jwt, FAPI says you must use certificate bound access as per mutual TLS spec but it doesn't say all of the provisions apply if you’re using private key jwt.

So if the client is registering for private_key_jwt, it can ignore mtls_endpoint_alias and puts the obligation to offer mutual tls on the non alias token endpoint on the provider. Even if the provider really wants to the client to use the alias.

‌

[Joseph Heenan]

I thought about this more and thought it might be good to at least draw client implementor’s attention to the relevant clause, so I’ve proposed text here:

‌

https://bitbucket.org/openid/fapi/pull-requests/316/explicitly-mention-mtls_endpoint_aliases

[Dave Tonge]

PR merged