Delegation-oriented FedCM

[samuelgoto]

こんにちは 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.

[martinthomson]

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.