- marked as minor
clarify expected OP behaviour upon unsupported prompt parameter value
Followup to http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20190805/007475.html
What is the expected OP behaviour upon encountering an unsupported/invalid prompt
parameter value? Error out or proceed and ignore the value?
What do existing implementations do today? I guess probably error (render page, invalid_request
or something proprietary) but I did not do the due diligence to check.
My expectation is to error on unsupported values since not every prompt
parameter value brings with it the “acknowledgement” in the form of a return parameter or claim inside the ID Token (e.g. none, consent)
Comments (7)
-
reporter -
I looked back at what we did back in '13 with our original treatment of prompt and we will error with
invalid_request
on an unsupported or invalid or unknown prompt value. -
If we want
prompt
to be extensible with new values in practice, we probably need to say that values that are not understood MUST be ignored - just like we do with OAuth request parameters and with JWT claims.However, as George Fletcher pointed out on the 5-Dec-19 call, there is an issue that there’s no way for the RP to tell whether the OP honored the prompt request or ignored it.
-
- changed status to open
-
-
assigned issue to
-
assigned issue to
-
Will be fixed by https://bitbucket.org/openid/connect/pull-requests/594 . Note that the PR addresses this issue both for
display
andprompt
values. -
- changed status to resolved
- Log in to comment