- changed status to open
id_token_hint and non-repudiation
Issue #1187
resolved
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
- 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?
- 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
Comments (2)
-
-
- changed status to resolved
Closed on the Jun 3 2021 call.
- Log in to comment
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
.