Core 3.1.2.1. - id_token_hint and prompt=none

[Torsten Lodderstedt]

The OpenID Connect spec states „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.“

I don’t fully understand the rationale of this text and think it hinders interoperability.

1) Why should the RP include an id_token? There are use cases where the RP just wants to determine whether a user is logged in on the device. No id_token_hint available or needed.

2) If the RP is free to choose whether to include an id_token_hint or not, why MAY the OP respond with an invalid_request error code? According to RFC 6749 this means „The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.“ To me this indicates a programming error. That would be ok, if the text would require (MUST) the RP to send the id_token_hint. The way the text is written now, an RP, which works perfectly fine with several OPs would break if the next OP would decide to respond with this error. That’s bad for interop.

3) The text continues by asking the OP to not respond with an error if possible? I got lost.

I suggest to clarify the rationale and simplify the text.

Is it allowed and desired to use prompt=none without an id_token_hint? I think so and any OP should support this behavior.

I think the whole sentence should be removed.

[Brian Campbell]

+1 to clarify the rationale and simplify the text.

[Nat Sakimura]

Touched on the Aug. 20 call. Just removing the sentences ok? Pull request to the current doc makes an errata?

[Torsten Lodderstedt]

https://bitbucket.org/openid/connect/pull-requests/2

[Michael Jones]

Torsten and I talked during IETF and we agreed that the first part of the sentence should remain "When possible, an id_token_hint SHOULD be present when prompt=none is used".

[Michael Jones]

On the 31-Jul-23 call, I discussed possibly deleting the phrase “and an invalid_request error MAY be returned if it is not“. Nat thought that doing so would make the meaning more ambiguous. Therefore, he proposed that we leave the text as-is.

[Michael Jones]

Based on the discussion on the 31-Jul-23 call, unless a counterproposal is made on how to address this issue without changing the meaning of the specification, this issue will be closed in one week.

[Michael Jones]

Closing as "Won't fix" per the previous two comments. If you want to see a different resolution, please propose specific wording changes that don't change the meaning of the specification as part of the upcoming working group review described in my message "[Openid-specs-ab] Candidate OpenID Connect errata correction drafts published".