Mandate at_hash check in the ID Token from the token endpoint

[Nat Sakimura]

In OIDC, at_hash is optional.

Our intention is to protect all the messages so we need to mandate it to be included and the check to be performed.

[Joseph Heenan]

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.

[Nat Sakimura]

Good point. Perhaps can we create a separate issue for what you are pointing out? This particular one is to cover the reported potential attack.

[Joseph Heenan]

okay, I've raised https://bitbucket.org/openid/fapi/issues/163/more-description-of-the-security-model to cover that.

[Nat Sakimura]

Will treat it as a part of #163