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

[Joseph Heenan]

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?

[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.

[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.

[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’?

[Takahiko Kawasaki]

prompt_values_supported is much better and consistent with other *_supported metadata.

[Vladimir Dzhuvinov]

+1 for prompt_values_supported

[Nat Sakimura]

Any updates?

[Michael Jones]

https://openid.net/specs/openid-connect-prompt-create-1_0.html#name-discovery-metadata defines the prompt_values_supported metadata parameter. I propose that we close this issue on that basis.

[Joseph Heenan]

I think we all missed that the prompt create spec is missing an IANA section to registered the new metadata - prompt_values_supported is missing from https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml - not sure how to address that?

[Michael Jones]

Oops! The way to fix this is to publish an errata update to the spec adding the missing registration in an IANA Considerations section. @gffletch, I’d be glad to work with you to do this.

[Michael Jones]

We discussed this on the 26-Aug-24 working group call. Mike will create a PR adding the missing IANA Considerations text in collaboration with George.