Missing use cases

[gffletch]

In reading through the spec, I found the following use cases unclear or missing...

1. IDP requires special registration elements based on the client_id of the RP. (This is very common in a First Party SSO scenario where multiple domains are in use and there is a common idp domain).

• For this to work the IDP needs to be able to control the user and form requests shown to the user so that the special requirements can be obtained

2. The IDP knows the identity of the user but the user must explicitly present credentials as the cookie is no longer sufficient (expired, the session context has deteriorated, etc)

• In this case the IDP does NOT need a sign-up event but instead just needs an explicit authentication
• this is similar to the use case Dick mentioned regarding the IDP needing the user to take additional steps before they can be set to a "signed in" state

3. The RP wants to request that the IDP perform an authentication with specific requirements (e.g. the user much authenticate with a hardware based phishing resistant method, or must authenticate if they haven't presented credentials in the last X minutes).

[npm1]

Could this be addressed by adding more customization within the FedCM UI and/or adding support for full page redirect to the IDP so the IDP can control the requirements that way? This is something we're thinking about but do not have a clear design on yet. The third one is pretty interesting as it adds another level of authentication to the problem. Thanks for the examples!

[achimschloss]

On 3 - please cf. to max_age, prompt=login, acr_values as an example within OIDC

[achimschloss]

There seems to be related work happening in relation to the need for the IDP to directly communicate with the user as @gffletch rightfully points out (also relevant if users are not authenticated with the IDP at all).

In the context of the payment handler/method standardisation there is a similar requirement for a payment handler to be able to interact with the user, which is addressed by service workers which are able to open a dialogue where they can do whatever is needed to proceed with the payment request. Payment Request Handler