is s_hash necessary?

[Brian Campbell]

I see what s_hash is doing but I have some concern about a new required claim in the ID Token that off-the-shelf products and open source that do regular OIDC won't support. Seems like that could hinder adoption and interchangeability.

In FAPI part 2, the authentication request must be integrity protected so there's less opportunity to mess with the state. And the hybrid flows require the nonce parameter in the request which is returned in the signed ID Token. Couldn't the same protections that s_hash gives be achieved by telling the client/RP to integrity protect the state value it sends and to associate the state with the nonce and check that association when validating the response?

Maybe I'm off base here but that seems like it would provide the same protections without adding a new required protocol element on top of OIDC.

[Nat Sakimura]

Interesting idea, and on the first read, it looks like the case for OIDC. However, please note that OAuth JAR does not have nonce. Using OIDC solves a lot of problems but there seem to be people who do not want it :-(

[Brian Campbell]

FAPI part 2 requires OIDC and says "shall require the response_type values code id_token or code id_token token." Both those 'hybrid' response types return the ID token in the front channel and thus the nonce authorization request parameter is required as is the nonce claim in the ID token. Note that s_hash is a claim in the ID token so none of this is relevant without OIDC.

[Nat Sakimura]

Just recording the result of the July 14 F2F.

The discussion lead to the direction to keep it as: * it is fine to be aspirational; * s_hash method is less error prone. * it is not hard to implement it. It is just another claim. There are implementations that support it already. e.g., Authlete

[Nat Sakimura]

It does not require spec change.