prompt=create is still just a hint
Issue #1193
open
4.1. Authorization Request
How the OpenID Provider handles prompt values that it fails to parse is out of scope for this specification. -or- If the OpenID Provider fails to parse the provided value(s) it should ignore the prompt parameter value and proceed as if the prompt parameter was not specified.
I believe this issue remains unanswered by the WG. See https://bitbucket.org/openid/connect/issues/1101/clarify-expected-op-behaviour-upon. My expectation is to error instead of ignore 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, this one). This needs to be solved on a higher level since it is unsuitable for every extension prompt parameter value to be definings its own “unrecognized” handling.
Appendix C. Document History
2019-10-02
Incorporated feedback from the working group. Add text around prompt=create being more than a hint but an expectation of an action to be performed.
Where is this incorporated? Since there's no normative language saying a new registration must be processed or any feedback back to the RP that a new registration was actually performed this extension indeed is still just a UX hint. As a matter of fact the specification doesn't even say anything about the expected behaviour when an OP already tracks an authenticated session. Should the prompt=create behave like prompt=login then?
As-is prompt=create does not fulfil my expectation of what a prompt parameter value should be, it is still only a simple hint. It is not a behaviour prescription, nor does it come with feedback to the RP. Maybe all it would take is to register a registered_at/created_at OIDC unix timestamp claim and ensure that one is returned when prompt=create is used.
Comments (3)
-
-
+1 to keep it as a simple hint, with no errors
-
- changed status to open
- Log in to comment
I agree that we need to handle unknown prompt values at a higher level. Let’s add it to the agenda for next weeks European time-friendly WG.
As for the behavior, because a user could be logged in, it seems like it should be up to the AS as to how to handle that. From an RP perspective they don’t really need to know whether the user was newly created or was already an existing identity. The RP just wants a logged in user.
However, there are cases where two calls-to-action (CTA) within the RP make sense. So allowing an app to create a CTA that the user can select to say they want to create an identity makes sense. It then needs to be up to the AS as to what should happen to return a “logged in user” to the RP. Note that this flow also skips the first “login screen” and keeps the user from having to hunt for the “sign-up” link.
Maybe “create” is the wrong name and it should be “new-user”? The point being the user thinks they need to sign-up for an identity and we want to inform the AS of this user intent and then let the AS provide the optimized UX to get the user logged in. I don’t think we should return an error if the user doesn’t create a new identity but does login (either because they already are or because the AS helped them find an identity they already had and logged them into that).