-
Notifications
You must be signed in to change notification settings - Fork 55
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
FedCM (was WebID) #718
Comments
(small update: just added the link to the answers to the privacy questionnaire that was initially missing) |
Linking to our previous review of webID |
Where is this work intended to go after the CG? |
The explainer seems to imply that a name and picture are always required as part of the login flow. Is this actually the case or have I misunderstood? I'm sure not all IDPs or RPs are going to want/require names and pictures, and some IDPs may provide different ways of distinguishing between accounts (eg. a colour profile, or description?). In general we are really interested to hear any feedback you have from developers and users following your origin trial. |
We don't feel strongly about where this will go, but a reasonable starting point is somewhere like the WebAppSec where more Credential Management APIs are discussed. But, we don't feel strongly and are open to other venues if the group finds more appropriate ones. |
Yes, this is a known issue that we'd like to move away from. But you are right in reading that this is where the spec/explainer is at the moment, and we agree that it an undesirable shortcoming, in that it is not expressive enough yet. We think where the spec is starting at is a reasonable baseline, and we agree that it needs to be more expressive going forward to capture the nuance of different requirements. One idea is to allow the relying party specify what it needs from the IDP (one idea is to re-use the query structure developed by OIDC here). Here is an example of what that API could look like: await navigator.credentials.get({
federated: {
claims: {
name: {essential: true}, // required
email: null, // optional
emailVerified: null, // optional
picture: {essential: true}, // required
},
providers: [{
url: "https://idp.example",
clientId: "123"
}]
}
}); Which could lead to a UX that allows a browser to ask more specific questions to the user. Example: WDYT? |
We are trying to compile what we have learned from a quantitative perspective and will report back as soon as we have that ready. In the meantime, qualitatively, we have compiled some of the most popular feature requests* (from github issues) and ways that developers are seeing how the api COULD evolve here. Note that this is largely a collection of feature requests that we got from developers, rather than a committed direction. Does that help? *(including the one you mentioned above, which we are calling "selective disclosure") |
Thanks @samuelgoto! That's very helpful. We're happy with the problem this is setting out to solve, and the general direction, and in particular the alignment with patterns from related well-used mechanisms like OIDC. It is reassuring to see your acknowledgement of known issues, and note that our positive review of this work is based on the assumption they will be addressed as the work progresses.
Do you have anyone from the WebAppSec WG in the FedID CG? Generally we advise connecting with a WG as early as possible to make sure they're aware of the direction of the work and have an opportunity to input, to make it more likely to be confidently adopted when you are ready to take the work on the REC track. One final note - I saw in the document you linked to that you have made or may be considering a name change to "Web Identity API"? As I'm sure you're aware, "Identity" is a very ambiguous and loaded term! This might cause misunderstandings or concern about the scope of the work down the line, so we would strongly encourage you to consider "Web Identification API" instead (although sticking with FedCM is also fine). |
Hi @samuelgoto! Thanks for the opportunity to review this work. We largely think it's going in the right direction. this is not a full endorsement of the current API or architecture as specified in the CG report. As this is a big piece of work with multiple moving pieces, we'd like to suggest you come back to us to request indivdual reviews of these components once they reach an appropriate stage of maturity / consensus. |
(just coming back from vacations now, so apologies for the delay in responding)
That's great to hear, thanks for the time put into reviewing this and providing thoughtful feedback!
We've been working with @mikewest since early stages of the API design. We are starting to actively work with @hlflanagan (FedID CG chair) and other browser vendors to figure out whether/where/when/which to move this to a WG, and we are generally excited about that possibility indeed.
Yeah, I personally like "Web Identification API" too (largely because it pairs well with "Web Authentication API" as a complement, as opposed to as an alternative), but as you can imagine, naming is hard (we opened suggestions up for voting in this github issue and most people didn't quite like "Web Identification API"). We haven't settled on a formulation yet (sticking with FedCM is challenging because we are not extending the existing FederatedCredential object anymore, but rather creating a new one.), but I hear where you are coming from. "Web Identity API" remains my least-worse choice at the moment, but we are actively working towards finding a better framing/naming.
That's great to hear @torgo and @rhiaro and @hadleybeeman (thanks for the early quick review)!! We really appreciate the thought and time you spent into given us advice and recommendations and I hope you feel like we incorporated most of them! |
Braw mornin' TAG!
I'm requesting a TAG review of FedCM (was WebID).
A Web Platform API that allows users to login to websites with their federated accounts in a privacy preserving manner.
Further details:
You should also know that...
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
The text was updated successfully, but these errors were encountered: