[Openid-specs-fapi] Issue #415: Discovery Metadata for mtls (openid/fapi)

Ralph Bragg issues-reply at bitbucket.org
Wed May 26 13:08:04 UTC 2021


New issue 415: Discovery Metadata for mtls
https://bitbucket.org/openid/fapi/issues/415/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](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.
```

‌

‌



More information about the Openid-specs-fapi mailing list