rblanck
commented
2 years ago Official +1 for this concept, I was co-author for this. For an RP that's crucial and helpful that fedCM will take off.
Open achimschloss opened 2 years ago
rblanck
commented
2 years ago Official +1 for this concept, I was co-author for this. For an RP that's crucial and helpful that fedCM will take off.
budemaier
commented
2 years ago Very Interesting! +1
samuelgoto
commented
2 years ago +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
commented
2 years ago See discussion in https://github.com/fedidcg/meetings/blob/main/2022/2022-10-03-notes.md
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 - https://github.com/fedidcg/FedCM/issues/14#issuecomment-1105400215, https://github.com/fedidcg/FedCM/issues/264#issuecomment-1180610831, https://github.com/fedidcg/FedCM/issues/253#issue-1205778159
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:
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.