we could be clearer about which id_token s_hash is required in

[Joseph Heenan]

The spec is arguably not clear if s_hash needs to be in the id_token return from authorisation, or the one from the token endpoint, or both.

OIDC core explicitly allows the other hashes to be omitted in the id_token returned from the token endpoint:

https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2

[Nat Sakimura]

The intention is to protect the authorization response, so it should come back from the ID Token in the Authorization Response. ID Token is the detached signature here.

[Joseph Heenan]

There's an additional issue that applies to OB. As OB allows response_type of code, there is no id_token from the authorise endpoint, so in that case s_hash probably should be in the id_token returned from the token endpoint. This doesn't affect FAPI as far as I can see, but may still mean we should be careful of the wording we use in FAPI.

[Nat Sakimura]

Be clear about with id_token s_hash is required in

This essentially mirrors the language about at_hash and c_hash in:

https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2

fixes #130

→ <<cset 422ef24807e2>>