It seems the context API is a good entry point to discuss AuthZ use-cases in general, i.e. leveraging federated login for authorization scenarios where the user it not signing in (to the RP) but access to a protected ressource is authorized (any classical OAuth 2 use-case, other than OIDC). This could well map to the "Use" and "Continue" use-cases.
To open question from @samuelgoto
How does this integrate with the Multi-IdP API? How do we decide which context to use if they conflict with each other?
These use-cases only makes sense in case an IDP supports a specific scope of authorization, the API would need to be extended in terms of scopes/use-case requested by the RP. Looking at https://github.com/fedidcg/FedCM/issues/348 this would be the "Does the IDP support the requested scope". If the scope is supported by IDP it would for example report back logged in users via the accounts endpoint, if not then not. -> the context must be provided to the IDP in that sense.
Overall the RP must be in control when which use-case is triggered (directly or indirectly via SDKs)
Other questions:
How would the RP be able to communicate the use-case to the user? Is the expectation that this must be done upfront before triggering the API? Typically (similar to the sign-up flow) the IDP would have some explanatory language in place.
It seems the context API is a good entry point to discuss AuthZ use-cases in general, i.e. leveraging federated login for authorization scenarios where the user it not signing in (to the RP) but access to a protected ressource is authorized (any classical OAuth 2 use-case, other than OIDC). This could well map to the "Use" and "Continue" use-cases.
To open question from @samuelgoto
These use-cases only makes sense in case an IDP supports a specific scope of authorization, the API would need to be extended in terms of scopes/use-case requested by the RP. Looking at https://github.com/fedidcg/FedCM/issues/348 this would be the "Does the IDP support the requested scope". If the scope is supported by IDP it would for example report back logged in users via the accounts endpoint, if not then not. -> the context must be provided to the IDP in that sense.
Overall the RP must be in control when which use-case is triggered (directly or indirectly via SDKs)
Other questions: