clarify expected OP behaviour upon unsupported prompt parameter value

[Filip Skokan]

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)

[Brian Campbell]

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.

[Michael Jones]

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.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/594 . Note that the PR addresses this issue both for display and prompt values.

[Michael Jones]

https://bitbucket.org/openid/connect/pull-requests/594 merged