inconsistent treatment of id_token_hint

[Brian Campbell]

Core has two mentions of id_token_hint (not counting self issued and IANA registration), which are pasted below. It seems that one says that an error SHOULD be returned if the end-user identified by the id_token_hint isn't the current user while the other says an error MUST be returned.

The spec should be consistent with itself.

The thread starting here is about the issue and has some opinions on SHOULD vs. MUST. I'd think the latter is preferable.

http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

id_token_hint OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.

http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation

If the sub (subject) Claim is requested with a specific value for the ID Token, the Authorization Server MUST only send a positive response if the End-User identified by that sub value has an active session with the Authorization Server or has been Authenticated as a result of the request. The Authorization Server MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session with the Authorization Server. Such a request can be made either using an id_token_hint parameter or by requesting a specific Claim Value as described in Section 5.5.1, if the claims parameter is supported by the implementation.

[Michael Jones]

As we discussed on today's working group call, these are not actually inconsistent. One's id_token_hint behavior and the other's behavior when requesting a "sub" claim value. Given that id_token_hint is a hint, we felt that SHOULD is the strongest that the statement can be made.

We'll leave this open for discussion at present, but lacking further input, this is on track to be closed as "wontfix".

[Brian Campbell]

Both apply to the hint. The second one says it's either the hint or the sub requested claim. From http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation "Such a request can be made either using an id_token_hint parameter or by requesting a specific Claim Value as described in Section 5.5.1, if the claims parameter is supported by the implementation. "

[Michael Jones]

You're right. Let's discuss this on the next call, or you can raise it on the mailing list before that.

[Michael Jones]

We could delete the id_token_hint language from the sub:value paragraph. This would delete "either using an id_token_hint parameter or".

The prompt=none case is different than the interactive case. In the prompt=none case, an error should be required.

We need to work on specific wording.

[Michael Jones]

I will investigate whether the existing errata edits have already addressed this issue.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/339/errata-made-id_token_hint-error-treatment

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/339/errata-made-id_token_hint-error-treatment