[Openid-specs-ab] Issue #1034: Core 3.1.2.1. - id_token_hint and prompt=none (openid/connect)

Torsten Lodderstedt issues-reply at bitbucket.org
Sat Jul 28 12:38:02 UTC 2018


New issue 1034: Core 3.1.2.1. - id_token_hint and prompt=none
https://bitbucket.org/openid/connect/issues/1034/core-3121-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 could be removed.




More information about the Openid-specs-ab mailing list