[Openid-specs-ab] Issue #1187: id_token_hint and non-repudiation (openid/connect)

[panva]

New issue 1187: id_token_hint and non-repudiation
https://bitbucket.org/openid/connect/issues/1187/id_token_hint-and-non-repudiation

Filip Skokan:

>From [https://openid.net/specs/openid-connect-core-1\_0.html#AuthRequest](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](https://openid.net/specs/openid-connect-rpinitiated-1_0.html).

> 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

‌