[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for RP controls to support meaningful integration into their user flows #348

Open
achimschloss opened this issue Sep 12, 2022 · 4 comments
Labels

Comments

@achimschloss
Copy link
Contributor

The interaction model between users, RPs, IDPs and the browser significantly changes in a FedCM style flow. Largely given sign-up, sign-in interactions and access authorization to resource servers are mediated by the browser - i.e., UX interactions that previously happened directly with the IDP - are now happening in some case without leaving the RPs site. This has been discussed already in multiple related tickets - #14 (comment), #264 (comment), #253 (comment)

This not only means that IDP interactions with users change, but also how RPs embed and address user to sign-in, sign-up or authorize other types of access requests. Today most sites are not built for this type of API but must be able to properly embed them into their user interactions model.

Simply triggering the API without any feedback (other than sometimes ending with a successful sign-in) and controls (other than it's only shown when a user is signed into an IDP) is not fit for purpose and could end up with suboptimal user-experiences especially also given how they operate in parallel to classical redirect flows (which will not go away any time soon).

This is even more relevant with:

  • Multi-IDP support, where the RP must have some preference/priority w.r.t IDPs (to avoid winner takes it all scenarios)
  • Support for use-cases to authorize general resource server access (where a RP sign-in is not needed/desired)
  • Supporting IDP sign-in during API calls
  • ...

The following flowchart illustrates the key controls / decisions from an RP side that come to mind initially interacting with a FedCM style API. Assuming the browser would not want to expose the user status, RP control could be established by allowing flags to be set while interacting with the API.

Fed-Login RP Logik (1)

@rblanck
Copy link
rblanck commented Sep 16, 2022

Official +1 for this concept, I was co-author for this.
For an RP that's crucial and helpful that fedCM will take off.

@samuelgoto samuelgoto added the agenda+ Regular CG meeting agenda items label Sep 16, 2022
@budemaier
Copy link

Very Interesting!
+1

@samuelgoto
Copy link
Collaborator

+1 from my side too! Need more time to dig into the details, but the key parts of the diagram seems correct to me too!

@hlflanagan
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants