As per discussion on https://bitbucket.org/openid/fapi/issues/150/mandate-at_hash-check-in-the-id-token-from it may be worth adding a description of the security model:
I wonder if we should explain the full security model somewhere, unless it's already covered somewhere else?
The way I see it there's a chain here where a weakness at any point could allow a rogue access token in:
discovery - protected by TLS cert, but I presume a client generally only fetches this once
jwks_uri - obtained from discovery, protected by TLS cert and refreshed frequently
id_token - validated by keys from jwks_uri
access token - validated by hash from id_token
That would tend to imply that we should make it clear that discovery & jwks_uri endpoints are both on a 'secure' server and (as Nat had suggested before) that people should look at techniques like TLS certificate pinning, DNSSEC, etc, etc.
It all depends on how far we want to go. e.g. openbanking neither recommend certificate pinning (at least as far as I can see in the security specification), and I believe all bank jwks uris are hosted on a host under openbanking.org.uk, and that domain doesn't appear to have DNSSEC setup.