At Shopify, we've followed progress closely, and I'm really excited to
see the i2s!
Agree with the analysis tradeoffs and proposed rollout. This is a
capability we're keenly interested in and would be willing to stay
hands-on with as it evolves.
On Wed, Oct 5, 2022 at 1:54 PM Sam Goto <g...@chromium.org> wrote:
On Wed, Oct 5, 2022 at 1:25 AM Yoav Weiss <yoavwe...@chromium.org>
wrote:
On Tue, Oct 4, 2022 at 4:13 AM Rick Byers
<rby...@chromium.org> wrote:
I've been involved somewhat with this work and so I'm
recusing myself from my API owner role for this intent.
Nevertheless I wanted to chime in and say that I agree
with the risk tradeoff the team is proposing we make here.
Yes there's still a lot to figure out in the federated
identity space, and it's likely that we'll find places
where we need to make some breaking changes to better meet
customer needs and get to interoperability. But I believe
shipping what we have now as a V0 is the most effective
way to figure out the path forward in a timeframe that's
compatible with Chrome's plans for 3P cookie deprecation.
We've been evolving designs in public for >2 years and now
we have at least one partner who is ready to scale up
beyond OT limits, and we'd both learn a lot from doing so.
It would be a mistake to think that we just have a few
open issues to resolve before we could call the design
"mature", and I don't want to risk losing momentum with
customers by suggesting we should just stick to
"experiments" for another 6-12 months. Instead the process
of becoming mature in the context of a dynamic identity
provider ecosystem and evolving privacy landscape will be
best served by a "launch and iterate" approach. Doing this
responsibly requires a commitment on our part to engage
with the standards community in good faith to avoid past
failure modes where V0 (chromium-only) and V1 (standard)
APIs have co-existed in chromium for an extended period of
time while Google services in particular have retained a
dependency on the V0 behavior.
The partnership and ecosystem dynamics here remind me a
lot of what we encountered with PaymentRequest. We still
don't have payment APIs "figured out", but we've been able
to learn and iterate
<https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#>
by working with a handful of partners through the web
payments working group to evolve fully launched APIs,
including making significant breaking changes along the
way (despite my own initial skepticism of the practicality
of that).
Rick
On Mon, Oct 3, 2022 at 6:31 PM Sam Goto
<g...@chromium.org> wrote:
Contact emails
g...@chromium.org
Explainer
https://github.com/fedidcg/FedCM/blob/main/explainer.md
<https://github.com/fedidcg/FedCM/blob/main/explainer.md>
Specification
https://fedidcg.github.io/FedCM
<https://fedidcg.github.io/FedCM>
Summary
The Federated Credential Management API (originally
WebID
<https://github.com/fedidcg/FedCM/issues/41#issuecomment-712304910>)
allows users to use their federated identity to login
to websites in a manner compatible with improvements
to browser privacy. This intent covers a Web Platform
API to prompt the user to choose accounts from one
Identity Provider to sign-up or sign-in to a website.
We expect to send future intents to make enhancements
over these capabilities (e.g. multiple IdPs
<https://github.com/fedidcg/FedCM/issues/319>) and
keep raising the privacy properties of the API (e.g.
the timing attack
<https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>problem).
Blink component
Blink>Identity>FedCM
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM>
TAG review
Early Tag Review
https://github.com/w3ctag/design-reviews/issues/622
<https://github.com/w3ctag/design-reviews/issues/622>
Spec Tag Review
https://github.com/w3ctag/design-reviews/issues/718
<https://github.com/w3ctag/design-reviews/issues/718>
TAG review status
Positive
<https://github.com/w3ctag/design-reviews/issues/718#issuecomment-1187725216>
Risks
Interoperability and Compatibility
Zero compatibility risk (new API)
Gecko: Positive
<https://github.com/mozilla/standards-positions/issues/618#issuecomment-1221964677>
WebKit: Positive
<https://lists.webkit.org/pipermail/webkit-dev/2022-March/032162.html>
On interoperability and forward compatibility: FedCM
is large and complex and, as browser vendors start to
implement it (example
<https://bugzilla.mozilla.org/show_bug.cgi?id=1782066>),
we are seeing positive and constructive engagement.
For example, we are actively working with Mozilla to
find an interoperable way to address the timing attack
problem
<https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>,
support multiple IdPs
<https://github.com/fedidcg/FedCM/issues/319>and
protect endpoints
<https://github.com/fedidcg/FedCM/issues/320>. Because
of that, there is a risk of incompatible changes going
forward (list of currently known potential risks here
<https://github.com/fedidcg/FedCM/labels/compatibility%20risk>),
mostly affecting IdPs (see section below on
activation). We think it is unavoidable that parts of
our current design are suboptimal and are going to
need to be revisited, but the biggest risk we are
trying to avoid is to fail to bring IdPs along with
us, increase their production footprint that we can
learn from, and increase our confidence on technical
feasibility and product-market fit.
Based on our origin trials, we expect a small number
of IdPs (say, less than ~30) to be incentivized to
use the API in production until chrome phases-out
third party cookies in 2024
<https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>.
These IdPs that we are partnering with need time,
confidence, and stability to increase their
deployment. For example, in origin trials, we ran into
CSP issues
<https://bugs.chromium.org/p/chromium/issues/detail?id=1320724>and
cross-origin iframe issues
<https://bugs.chromium.org/p/chromium/issues/detail?id=1322320>that
we could have never anticipated without IdPs
experimentation, even if we had interoperable
implementations in all major browsers. We think that
the risk we take by not having a baseline that IdPs
can work from if the API isn’t shipped outweighs the
forward compatibility risks: not shipping would mean
that we won’t learn about these bugs until it is too
close to the deprecation of third party cookie (e.g.
IdPs will continue to evolve their products using
iframes and third party cookies without an alternative
to build on). We also think that we can address some
concerns on forward compatibility by setting the right
expectations during developer documentation / outreach
to IdPs as we make it battle-tested before we
deprecate third party cookies in 2024
<https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>.
Web developers: We’ve been working with Identity
Providers and Relying Parties over the last ~3 years,
going over a good amount of design alternatives and
prototypes (TPAC 2020
<https://github.com/fedidcg/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20TPAC.pdf>,
2021
<https://github.com/fedidcg/FedCM/blob/main/meetings/2021/FedCM%20%40%20TPAC%202021%20(1).pdf>and
2022
<https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM%20%40%20TPAC.pdf>,
BlinkOn 14
<https://github.com/fedidcg/FedCM/blob/main/meetings/2021/WebID%20-%20BlinkOn%2014.pdf>,
15
<https://github.com/fedidcg/FedCM/blob/main/meetings/2021/BlinkOn%2015%20--%20FedCM.pdf>,
16
<https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM%20BlinkOn%2016.pdf>,
OIDF 2020
<https://github.com/fedidcg/FedCM/blob/main/meetings/2020/Browsers%20and%20Federation%20-%20OpenID.pdf>,
IIW 2020
<https://github.com/fedidcg/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20IIW.pdf>),
trying to strike the right balance between
privacy/security properties and deployment structures
(e.g. backwards compatibility). The current
formulation is the result of identity providers,
relying parties, browser vendors and industry experts
that have co-designed with us through our devtrials
and gathered production experience with their users
through our origin trials (around ~33 small and big
registered IdPs). For example, in the last two
quarters, the Google Sign-in team has run experiments
with ~20 Relying Parties leading to more than ~300K
real users logging-in in production, achieving
comparable sign-in/up conversion rates without
depending on third party cookies. While this is a
small sample size of the ecosystem and the deployment
(notably missing representation of enterprises and
EDU), we are encouraged by the approach and confident
this is a solid and necessary first step.
Other signals: This API is being developed within the
FedID CG <https://github.com/fedidcg>composed of
identity providers, relying parties, browser vendors
and industry experts. The CG has produced an
enumeration of known issues
<https://github.com/fedidcg/use-case-library/wiki/Primitives-by-Use-Case>in
the absence of third party cookies, a list of
mitigation alternatives
<https://github.com/fedidcg/use-case-library/wiki/Third-party-cookie-mitigations>and
is actively working on how to decide
<https://github.com/fedidcg/use-case-library/wiki/User-Flow-Decision-Trees>which
Web Platform API to use for each circumstance. We
don’t expect (or are designing for) FedCM to be used
exclusively to solve all of the known issues, but
rather in coordination with other browser proposals
(e.g. CHIPS). We acknowledge that there is a series of
anticipated breakages that are not handled
(effectively) by any proposal (FedCM included) at the
moment, and we are excited to continue working with
the FedID CG, the Privacy CG
<https://www.w3.org/groups/cg/privacycg>and the
Privacy Sandbox <https://privacysandbox.com/>to extend
FedCM in whichever way is constructive and/or work on
new proposals.
Activation
Our design assumes that it is exponentially harder, in
this order, to make changes to (a) user behavior than,
(b) websites, (c) identity providers and then, lastly,
(d) browsers.
I agree with this ordering.
It'd be good to be transparent with adopting identity
providers about the potential compat risk, so that they'd know
what they are signing up for.
On top of that, there's some risk of the */compat issues
leaking/* from identity providers to websites, if those
websites self-host the IDP SDKs (for performance or other
reasons).
Would it be possible to ask identity providers to take
measures against self-hosting? e.g. I think
`document.currentScript.src` can help them enforce the script
coming from an updatable source.
I really like the `document.currentScript.src` suggestion, and I
think that’s a great way to help us control future breakages!
As you suggested, there is a lot that we can do by working with
the Developer Relations (devrel) and Business Development (BD)
teams to set up the right expectations as this goes out. Here are
a few examples that we think could work:
*
Set up a communication channel (e.g. a mailing list similar to
the one we have for Core Web Vitals here
<https://groups.google.com/a/chromium.org/g/speed-metrics-announce>and
here
<https://mobile.twitter.com/NicPenaM/status/1427712030455259142>)
that IdPs can subscribe to coordinate with us (in addition to
direct 1:1 partnerships)
*
Be transparent about the moving parts (e.g. the timing attack
problem
<https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>,
the multi-IdPs
<https://github.com/fedidcg/FedCM/issues/319>API, etc), and a
rough timeline to resolve them (e.g. we could use the Privacy
Sandbox Timeline
<https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>and
have meaningful stability checkpoints at General Availability
in 2023
<https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>and
Phase-out in 2024
<https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>).
*
Make a recommendation to IdPs to control their SDKs (e.g.
either through document.currentScript.src or SLAs), at least
until some moving parts settle, so that we can iterate quickly
as an industry. It is ultimately a business decision that IdPs
make, so we can only go as far as making a recommendation.
Just a few more data points:
*
We expect it is going to take us more than a quarter but less
than a year to resolve the known moving parts with confidence.
Also, importantly, they may or may not require backwards
incompatible API changes.
*
To give you a sense of numbers, in origin trials, ~33 IdPs
registered over the last ~7 months. There are few IdPs (that
have the incentives to use the API at the moment, while 3P
cookies are still around) and they are large and sophisticated
developers
*
In our experience so far, very few websites choose to
self-host (in origin trials, we found only 1), and the ones
that do, are extremely large and sophisticated developers that
can afford to self-host (i.e. we would know how to reach out
to them individually)
*
Outside of real-world production IdP deployment, it is
possible, though, that we are going to find developers playing
with the API, writing blogs or demos, and that’s more likely
to break (because we wouldn’t be able to reach out to them
individually), but that’s a more acceptable breakage.
So, the design pulls as much as possible the burden of
change to browsers vendors and identity providers, and
goes to a great extent to require little to no changes
to websites and user's norms, while at the same time,
raising the privacy properties of the system.
While that’s not always possible, we believe we found
an activation structure that could work at scale for a
substantial part of the deployment (especially for
consumers) through JS SDKs that are provided by
Identity Providers and get dynamically embedded into
relying parties.
For example, through their JS SDKs, the Google Sign-in
team was able to replace their dependence on third
party cookies with FedCM without requiring changes to
relying parties.
We acknowledge that this activation model is
insufficient for a lot of the deployment (especially
for enterprises), so finding alternative activation
structures is an active area of investigation.
WebView application risks
Does this intent deprecate or change behavior of
existing APIs, such that it has potentially high risk
for Android WebView-based applications?
This API does not deprecate or change behavior of
existing APIs.
Debuggability
Basic devtools integration supported. We plan to
extend this support as the product matures and we
learn from developers what challenges they run into.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux, Chrome
OS, Android, and Android WebView)?
No
The current implementation is available on all
platforms (Windows, Mac, Linux, ChromeOS and Android)
except WebView.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes, fedcm-* tests in this directory
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/>.
Known issue: some of our WPT tests are failing
<https://wpt.fyi/results/credential-management?label=experimental&label=master&aligned&view=subtest>on
wpt.fyi. While the tests exist and pass in Chromium’s
infrastructure, they rely on a Chrome-specific flag
that would not work in other browsers. Making them
work on upstream WPT requires PAC support; however,
WPT’s PAC support does not currently support HTTPS
tests, which FedCM requires because it is only exposed
to secure contexts. We are working on adding that
support, which is in progress here
<https://github.com/web-platform-tests/wpt/pull/35276>.
Origin Trial Instructions
https://developer.chrome.com/blog/fedcm-origin-trial/
<https://developer.chrome.com/blog/fedcm-origin-trial/>
Flag name
fedcm
Requires code in //chrome?
True
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1353814
<https://bugs.chromium.org/p/chromium/issues/detail?id=1353814>
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1321238
<https://bugs.chromium.org/p/chromium/issues/detail?id=1321238>
Measurement
kFederatedCredentialManagement
Estimated milestones
OriginTrial desktop last
107
OriginTrial desktop first
103
OriginTrial Android last
107
OriginTrial Android first
101
DevTrial on Android
98
Anticipated spec changes
We’re also currently resolving some questions
<https://github.com/fedidcg/FedCM/issues/320>related
to Fetch integration.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6438627087220736
<https://chromestatus.com/feature/6438627087220736>
Links to previous Intent discussions
*
Intent to Prototype
<https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ>
*
Ready for Trial
<https://groups.google.com/a/chromium.org/g/blink-dev/c/jlV_1m7uUAg>
*
Intent to Experiment
<https://groups.google.com/a/chromium.org/g/blink-dev/c/kws-gltC5us>
*
Intent to Extend Experiment
<https://groups.google.com/a/chromium.org/g/blink-dev/c/Juc7ix6UI24>
This intent message was generated by Chrome Platform
Status <https://chromestatus.com/>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-yf1BMQ4ZtMYH9cCQsecroEE3ZPOKgY8LU%3DNX3zAfbwYA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-yf1BMQ4ZtMYH9cCQsecroEE3ZPOKgY8LU%3DNX3zAfbwYA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY92OzzAAJkqpe11G9rW_7SNVo_qTYsu5OLd2mKZ%3DS3EOg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY92OzzAAJkqpe11G9rW_7SNVo_qTYsu5OLd2mKZ%3DS3EOg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wJNZAN_dBpfe60b9_iOseVPXypo%3DAvWwpD60W3coiXyg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wJNZAN_dBpfe60b9_iOseVPXypo%3DAvWwpD60W3coiXyg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABd3A800vm_-kX0inH4170iK1gs%3DT0w4da2P4kRe%2BYioTy5iTw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABd3A800vm_-kX0inH4170iK1gs%3DT0w4da2P4kRe%2BYioTy5iTw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
