Intent To Prototype: Delegation-oriented FedCM
Sam Goto
Contact emails
Explainer
https://github.com/w3c-fedid/FedCM/issues/677
Specification
Not yet available.
Summary
Early on, we outlined a few important problems we wanted to address in federation: first and foremost The Classification Problem (the fact that browsers couldn’t tell the difference between federation and tracking), and then The RP Tracking Problem (the release of global identifiers, such as emails) and The IdP Tracking problem (the bundling of presentation with issuance).
It wasn’t clear where we should start, so we looked at three different variations that had different trade-offs. We called them the Mediation-oriented model, the Permission-oriented model and the Delegation-oriented model.
We learned quickly that it was key to start from the first two variations, because they were the most backwards compatible. So, the Mediation-oriented model and the Permission-oriented model materialized - after many iterations - as FedCM’s mediated account chooser and the Storage Access API (by itself, or even in conjunction with FedCM). A series of heuristics were also put in place, which covers a lot of ground too, again optimizing for backwards compatibility with the Web.
The Mediation-oriented API, notably, was a great starting point because it (a) solved The Classification Problem, (b) allowed solving the The RP Tracking Problem (with directed identifiers) and, importantly, (c) didn’t require any user experience or behavioral change (as opposed to the Permission-oriented variation), allowing it to be deployed at large scales.
So, while the first two variations optimized for backwards compatibility (and, between them, a trade-off between performance, extensibility and ergonomics), they had an inherent privacy design weakness: The IdP Tracking problem.
That brings us to the Delegation-oriented model, which has great privacy properties in keeping IdPs blind, but requires us to redeploy a much larger part of the ecosystem: tens of thousands of relying parties.
We are not sure yet whether the delegation-oriented model is actually within reach at this point, but a few stars aligned recently. For one, the introduction of the issuer-holder-verifier architecture, together with the deployment of new token types like SD-JWT+KB, made the unbundling of issuance from presentation a lot more accessible. Zero knowledge proofs have also advanced much since we started, giving us some hope that we could solve both the RP Tracking Problem and the IdP Tracking Problem at the same time.
Asides from the new externalities introduced, the development of the Mediation-oriented variation allowed us to stand on top of a much higher foundation compared to where we started from. The last 2-3 years of production experience of FedCM across thousands of websites and millions of users required us to design a series of features and extensions (e.g. handling logged-out users, switching accounts, extensibility, handling multiple idps at a time, a registration mechanism, the pull and push model, and a series of control knobs) that we can build the delegation-oriented variation from.
This is still early and ambiguous, so it is very possible it won’t go anywhere. Nonetheless, it is probably the closest that we have ever been, and close enough that it feels worth taking a shot. The explainer linked above has some notes of the overall idea that we’d like to start from.
Blink component
Motivation
https://github.com/w3c-fedid/FedCM/issues/677
Initial public proposal
https://github.com/w3c-fedid/FedCM/issues/677
TAG review
None
TAG review status
Pending
Risks
Interoperability and Compatibility
None
Gecko: No signal yet. It shows up, however, as one of the desired areas of exploration in the original standards position. “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: No signal. We also heard informally at TPAC over the years from Safari engineers that they were hoping we’d explore this variation further too.
Web developers: No signals. We started gathering some early and informal guidance from the designers of protocols like OIDC and SAML here, but need to do a much deeper dive into the specifics. We think a few IdPs may choose to use this (non mutually exclusive) variation on their own (it is likely easier to operate and raises the privacy bar), but that’s yet to be seen.
Other signals:
WebView application risks
FedCM isn’t supported in WebViews. We don’t expect this specific variation to change that.
Debuggability
None
Is this feature fully tested by web-platform-tests?
No
Flag name on about://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
True
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5151763420938240
This intent message was generated by Chrome Platform Status.
Rick Byers
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wc%2BSPtWpUy9xrrsZ_Z8x9pJaZZSXeDE4YqygPQOCRVyA%40mail.gmail.com.