[Openid-specs-fapi] Issue #699: FAPI 2 vs. Security BCP Gap Analysis (openid/fapi)

[Daniel Fett]

New issue 699: FAPI 2 vs. Security BCP Gap Analysis
https://bitbucket.org/openid/fapi/issues/699/fapi-2-vs-security-bcp-gap-analysis

Daniel Fett:

I checked the latest version of FAPI 2 against the latest version \(-29\) of the Security BCP and noticed that there are some \(minor?\) discrepancies between the two. It may be fine to not change anything as they either affect corner-cases or are only recommendations in the BCP, but we should discuss how we want to proceed for each of them:

## Access Token Privilege Restriction

> **Security BCP, Section 2.3:** The privileges associated with an access token SHOULD be restricted to the minimum required for the particular application or use case. \(...\) In particular, access tokens SHOULD be audience-restricted to a specific resource server, or, if that is not feasible, to a small set of resource servers. \(...\) Additionally, access tokens SHOULD be restricted to certain resources and actions on resource servers or resources.

This is not currently implemented by FAPI 2.

## Client IDs

> **Security BCP, Section 2.6:** Under the conditions described in [Section 4.15.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#client_impersonating_countermeasures), authorization servers SHOULD NOT allow clients to influence their `client_id` or any claim that could cause confusion with a genuine resource owner.

This is not currently covered by FAPI 2.

## TLS Requirements

> **Security BCP, Section 2.6:** It is RECOMMENDED to use end-to-end TLS according to \[[BCP195](https://www.rfc-editor.org/info/bcp195)\] between the client and the resource server.

The use of TLS is covered by FAPI 2, but there is no explicit recommendation on it being used end-to-end.

> **Security BCP, Section 2.6:** Authorization responses MUST NOT be transmitted over unencrypted network connections. To this end, authorization servers MUST NOT allow redirect URIs that use the `http` scheme except for native clients that use Loopback Interface Redirection as described in \[[RFC8252](https://www.rfc-editor.org/info/rfc8252)\], Section 7.3.

This is not currently an explicit requirement in FAPI 2, but it is covered by the following statement in FAPI 2:

> To protect against network attacks, clients, authorization servers, and resource servers \(1.\) shall only offer TLS protected endpoints and shall establish connections to other servers using TLS.

## In-Browser Communication

> **Security BCP, Section 2.6:** If the authorization response is sent with in-browser communication techniques like postMessage [WHATWG.postmessage\_api](https://html.spec.whatwg.org/multipage/web-messaging.html#web-messaging) instead of HTTP redirects, both the initiator and receiver of the in-browser message MUST be strictly verified as described in [Section 4.17](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#rec_ibc).

The use of these techniques is not explicitly covered by FAPI 2.

## Cross-Origin Resource Sharing

> **Security BCP, Section 2.6:** To support browser-based clients, endpoints directly accessed by such clients including the Token Endpoint, Authorization Server Metadata Endpoint, `jwks_uri` Endpoint, and the Dynamic Client Registration Endpoint MAY support the use of Cross-Origin Resource Sharing \(CORS, [WHATWG.CORS](https://fetch.spec.whatwg.org/#http-cors-protocol)\). However, CORS MUST NOT be supported at the Authorization Endpoint, as the client does not access this endpoint directly; instead, the client redirects the user agent to it.

This is not currently covered by FAPI 2.