behaviour of unknown prompt values not clear / RP has no way to know if server supports prompt=create

Issue #1189 open
Joseph Heenan created an issue

The account creation draft defines a new prompt=create value.

It’s unclear how this will be handled by existing servers (which know nothing about prompt=create), i.e. https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest does not define how servers should handle unknown prompt values.

Should there be some text in the prompt=create specification along the lines “RPs must only send prompt=create to servers they know support it” and/or should OpenID Provider Metadata be defined to indicate that prompt=create is supported?

Comments (8)

  1. gffletch

    My assumption was that the value would be ignored if not understood as that tends to be the expectation in other cases. However, I have seen IDPs return errors in cases where I thought they should just be ignored:)

    I’m leaning against requiring the client to not send the value in the cases the AS doesn’t support it as that requires a bunch of additional work for the client developer. If the AS the developer is using throws an error in this context then that should be found before deployment. Taking this approach does create issues if the app is dynamically supporting any OIDC IDP (not a very common case).

    We can define some OpenID Provider Metadata for the prompt parameter so that clients can determine that if they wish.

  2. Vladimir Dzhuvinov

    I just plugged a test with prompt=create into the Nimbus OIDC SDK and got this 🙂

    https://example.com/cb?error=invalid_request&error_description=Invalid+request%3A+Invalid+%22prompt%22+parameter%3A+Unknown+prompt+type%3A+create
    

    I suspect that back in 2012 when the code was written the assumption was that there would only be the four prompt values defined in Core and no other, so prompt was coded as an enum.

    I wouldn’t be surprised if many deployed OP servers respond similarly on a prompt=create.

    I’m generally against complicating OP metadata, but it looks like adding a field to signal prompt=create support to RPs might be a good idea. So thanks Joseph for raising this issue.

  3. gffletch

    So in defining metadata for support for the ‘create’ value for prompt, are the opinions on defining something like ‘prompt_values_supported’ and then have the AS define which prompt values they support? like is done for claim_types_supported or grant_types_supported?

    Or is it better to make something specific ‘create_for_prompt_supported’?

  4. Log in to comment