[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