#1039: Delegation-oriented FedCM

Visit on Github.

Opened Jan 16, 2025

こんにちは TAG-さん!

I'm requesting an early TAG design review of the Delegation-oriented FedCM.

An extension to FedCM to allow Social login on the Web without phone-homing the Identity Provider.

  • Explainer¹: here
  • User research: TBD
  • Security and Privacy self-review²: TBD
  • GitHub repo: here
  • Primary contacts:
    • @samuelgoto
  • Organization/project driving the design: Google
  • Multi-stakeholder feedback³:
    • Chromium comments: intent to prototype
    • Mozilla comments: We believe this addresses part of the original feedback we got for FedCM from Mozilla here: "We ultimately want to be able to offer options where IdPs are not in a position to track users through their use of identity information. The current design always involves notifying the IdP of all login attempts. This has a number of advantages from a security perspective. The IdP is able to audit logins and present users with information about their activities. Also, the IdP is in a better position to block access to identity information for bad RPs. Ultimately, we would like to be able to offer users at least the option of a more private choice here, but we recognize the practical security benefits of the current design."
    • WebKit comments: TBD

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): FedID CG
  • 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:
  • Major unresolved issues with or opposition to this design:
  • This work is being funded by:

You should also know that...

This is very early and we are looking for directional guidance.

Discussions

Log in to see TAG-private discussions.

Discussed Jan 27, 2025 (See Github)

Martin and Marcos should review. Jeffrey doesn't see anything to complain about.

Should ask Privacy about the zero-knowledge proofs.

Discussed Feb 3, 2025 (See Github)

Martin: Doesn't engage with what we want to have happen here. There's a clear direction in the Identity community to move to the 3-party model. Good direction. Details matter. Mechanism in the main explainers allows Issuer-Verifier linkability: If they collude, they can join their information. Selective Disclosure, and you refuse to share a piece of information, the Verifier can just ask the Issuer to fill in the blanks. Whether that's acceptable depends on the use case, but it's hard for users to understand it. Need to work out the details. This gets back to the FedID FO.

Jeffrey: Any other proposals for this?

Martin: There are other formats, which the proposal doesn't dig into. Other formats allow better privacy properties. Those aren't well-enough developed to be able to ship. The crypto exists, but the concrete systems haven't been built.

Jeffrey: We could talk about what properties we think are appropriate on the web.

Martin: Many use cases with different requirements.

Jeffrey: We want an explainer that lists the use cases, and the properties that are available, so we can discuss them.

Martin: Age verification: common, governments like it. All of those systems have dire properties. You can build a system with zero knowledge and unlinkable, but it's prone to abuse. If I have a token I can share to a website, I can give you that token. Building that out requires extra machinery. Other cases: I have a driver's license, and want to attest to my name. Different use case. In those use cases, we have to engage fully with who issues the credential, who's able to use the credential. "What problem do you want to solve and why?" before mechanisms. Mechanisms may also be problematic. System they describe might have Verifier-Verifier linkability if you're not careful.

Discussed Feb 10, 2025 (See Github)

Hoping for comments from Marcos.

Comment by @martinthomson Feb 11, 2025 (See Github)

Hi Sam,

Thanks for bringing this to us, we just have some initial thoughts here. We'll likely take some more time thinking about the problem, because it's big and complicated.

We've taken a look at this and it is not clear to us that it addresses the use cases we believe to be relevant in this space. There are a lot of potential use cases, some where the proposed design sketch might be suitable, but others where there is potential for miscommunication or harm. The explainer doesn't really highlight specific use cases in terms of end user value.

As we understand it, the goal of this proposal is to enable general purpose identity-related assertions. This may or may not include some sort of selective disclosure system. It appears to make no choices about technology. The examples use a salted-hash selective disclosure scheme (SD-JWT+KB specifically), but the text mentions a range of possible mechanisms, with varying properties. It is possible that different use cases demand different technology choices, which makes a generic approach difficult to reason about.

As noted above, the explainer does not clearly describe the end user value, which is where we encourage you to focus your efforts. Ideally, this work would start from an analysis of the problems that users might face, focusing on those problems for which a solution in this area might help. That probably needs to address how existing identity-related solutions (or major proposals, including other FedCM, but also the new digital credentials work) fall short.

Given the sensitive nature of the subject, we'd also encourage you to spend some time looking at some of the ways in which mechanisms might be abused and what might be done to mitigate any risks. That can draw on the properties of schemes that are already documented in the existing literature; it doesn't need to be new research.

Either way, we encourage you to continue exploration in this area. There seem to be a set of important use cases in this general area where better interfaces would give people greater autonomy. The application of the 3-party model for identity could improve user experience in some of those cases, but we'd like a clearer articulation of those use cases before commenting further.

Discussed Feb 17, 2025 (See Github)

Updated issue to indicate that we are awaiting a response.