id_token_hint and non-repudiation

[Filip Skokan]

From https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest definition of id_token_hint, similar to its use at the logout_endpoint from the RP-Initiated Logout draft.

ID Token previously issued by the Authorization Server being passed as a hint

ID Token previously issued by the OP

1. What is the expected behaviour when the client’s id_token_signed_response_alg is set to “none” and a a previously issued ID Token is used as an id_token_hint?
2. What is the expected behaviour when the client’s id_token_signed_response_alg is set to be an HMAC based JWA and a a previously issued ID Token is used as an id_token_hint?

Neither in none or e.g. HS256 case can the OP ensure the id_token_hint value was actually issued by it since in both cases either anyone (“none”-case) or the client (confidential or credentialed) (HMAC-case) can forge the value.

Options are

• ignore the parameter
• error
• continue as if everything’s normal

‌

[Michael Jones]

As discussed in the 24-May-21 working group call, you're correct that unless the ID Token is asymmetrically signed, it can't be used as proof of a previous login. When unsigned or symmetrically signed, it can only be used as a hint as to what identity the user would like to be logged in as. If used with prompt=none, this might result in errors such as interaction_required.

[Nat Sakimura]

Closed on the Jun 3 2021 call.