You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up recently in a discussion with the TAG and @plinss, of an extension to FedCM that is both (a) early and (b) could use early directional guidance from the TAG.
Side note, also discussed in the discussion with the TAG: I'm glad that Chrome's Process points to Early Tag Reviews at the Devtrials stage, which I think is (a) exactly when we'd want to get early tag guidance and (b) where this specific API is at.
One of the problems on the web is that users are currently constrained by a small set of social login providers to login to Websites. Websites, in turn, are constrained by finite space in login flows, so they typically have to pick 2-5 large social login providers (e.g. facebook, google, twitter, linkedin, github, etc) that can represent a large fraction of their users, but, by construction, not all of them.
This is a proposal to increase user choice by allowing RPs to request any IdPs that the user has chosen to register.
Explainer¹ (minimally containing user needs and example code): explainer forked out of this thread
User research: not yet available
Security and Privacy self-review²: not yet available
GitHub repo: same as explainer
Primary contacts (and their relationship to the specification):
The group where the incubation/design work on this is being done (or is intended to be done in the future): FedID CG/WG
The group where standardization of this work is intended to be done ("unknown" if not known): FedID WG
Existing major pieces of multi-implementer review or discussion of this design: url
Major unresolved issues with or opposition to this design: See open questions here.
This work is being funded by:
You should also know that...
[please tell us anything you think is relevant to this review]
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular:
if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer public documents though, since we work in the open.
² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.
The text was updated successfully, but these errors were encountered:
Peter: One thing I would like to see: FedCM not tied to speciic IDPs. I'd love to run my own personal IDP and use that to log in everywhere... Scared of a FedCM world where only a few top IDPs are used...
Hadley: I'm with you but if I'm a RP don't I choose who I'm going to trust?
Peter: yes - not sure how to reconcile... FedCM allows you to "bring your own IDP".. but RP cant just trust any old IDP...
Matthew: +1 to both Peter and Hadley... Just to say that we both briefly touch on this in discussion with Sam ... we did touch on that in this meeting... minutes from last f2f
@torgo, @hadleybeeman, @plinss I just wanted to note that this early TAG review that we filed hopefully can add some clarity to some of the intuition that we are forming that matches what you discussed today. No particularly rush from my side to review this, but just wanted to send a review that should support your discussion, in case that's helpful.
こんにちは TAG-さん!
I'm requesting a TAG review of FedCM's IdP Registration API.
One of the problems on the web is that users are currently constrained by a small set of social login providers to login to Websites. Websites, in turn, are constrained by finite space in login flows, so they typically have to pick 2-5 large social login providers (e.g. facebook, google, twitter, linkedin, github, etc) that can represent a large fraction of their users, but, by construction, not all of them.
This is a proposal to increase user choice by allowing RPs to request any IdPs that the user has chosen to register.
Further details:
You should also know that...
[please tell us anything you think is relevant to this review]
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular:
¹ For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.
The text was updated successfully, but these errors were encountered: