FedCM (was WebID)

[samuelgoto]

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.

• Explainer¹
• Specification
• Web Platform Tests
• User Research: TODO(goto): report back here
• Security and Privacy self-review
• GitHub repo
• Primary contacts (and their relationship to the specification): Sam Goto @samuelgoto, editor
• Organization(s)/project(s) driving the specification: Google / Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • WebKit's Position Thread
  • Mozilla's Position Issue
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Chrome Status
  • Intent To Prototype
  • Ready For Trial
  • Intent To Experiment

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:
  • We are planning to start an origin trial in chrome's M101 (April) until M105 (August) and evaluate from there
  • We are working under the Privacy Sandbox Timelines along with other proposals
• The group where the work on this specification is currently being done: The FedID CG
• The group where standardization of this work is intended to be done: Unclear, but best guess is the WebAppSec WG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Google/Chrome

You should also know that...

• We presented our work at TPAC 2020/2021, here is a good introduction that may be easier to consume than the specification/explainer
• 2020 we raised the problem at the WICG and incubated
• 2020-2021 we prototyped a few alternatives / variations
• 2021 we ran an "early" TAG review here around a year ago and didn't hear any major existential / directionally incorrect feedback

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

[samuelgoto]

(small update: just added the link to the answers to the privacy questionnaire that was initially missing)

[hadleybeeman]

Linking to our previous review of webID

[plinss]

Where is this work intended to go after the CG?

[rhiaro]

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.

[samuelgoto]

Where is this work intended to go after the CG?

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.

[samuelgoto]

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?).

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?

[samuelgoto]

In general we are really interested to hear any feedback you have from developers and users following your origin trial.

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")

[rhiaro]

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.

reasonable starting point is somewhere like the WebAppSec where more Credential Management APIs are discussed

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).

[torgo]

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.

[samuelgoto]

(just coming back from vacations now, so apologies for the delay in responding)

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.

That's great to hear, thanks for the time put into reviewing this and providing thoughtful feedback!

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.

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.

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).

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.

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.

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!