#986: Early Design Review: Lightweight FedCM
Discussions
2024-09-16
Peter: any with more context?
Jeffrey: if this could replace fedcm that would be great.. but not evidence either way that it's going to... so swe should support experimenting with it...
This was discussed in our recent plenary too: https://github.com/w3ctag/meetings/blob/gh-pages/2024/telcons/09-02-minutes.md#plenary
Tess: it sounds like the complexity missing is in the "we're not going to need it" category.. if in practice nobody is using it then why do it?
Jeffrey: Sam feels that some IDPs have (legal) requirements... e.g. changing your name would propagate to all places immediately... remains to be see...
Hadley: which legal requirements?
Peter: right to be forgotten laws?
Hadley: most legal restrictions are reactive to the work we do, rather than creating boundaries within which we have to operate...
Tess: seems unnecessary to anticipate a regulatory...
Jeffrey: regulators have already said some things... E.g. opt out links... I can ask Sam for more details... I don't know if it changes much about our review of this API...
Hadley: can we more specific about outstanding questions? Outstanding questions in the working/community group?
Peter: In general I feel a bit lost on FedCM, given all the little reviews on it... This to me seems to be "throw all that out and start over" - and leads me even more confused...
Hadley: I also felt that way with next issue - 992.
Peter: that issue talks about fedcm as a trust signal for shared storage... I don't want to see that... Pushes us back to 3p cookie world.
Hadley: seconded (for issue 992)
Peter: other thing that occured: I think one of the biggest problem is lack of consistent support of single sign-off. Leads to user confusion about where you're logged in... Feels like leaving it as option means people won'd do it. I wonder if FedCM should require the background comms to make that work. I'm wondering if making it slightly more complicated to require comms between the IDPs should be a hard requirement from day 1?
Jeffrey: that's a concrete question - lightweight one doesn't allow for single sign-off..
Peter: I think that would be bad.
Hadley: comment looks good.
Peter: do we want to go farther and recommend that single sign-off shouldn't be optional.
Tess: i think not having it is an argument for it not being a total replacement for the heavy-weight one...
Peter: should we close?
Tess: yes I think we should - as it's an early review request...
Peter: I'm fine with closing it.
Dan: +1
<blockquote>We're happy to see this sort of experimentation with the FedCM problem space. It looks like there are outstanding questions in the Community Group about whether the Lightweight API will be enough to completely replace the existing proposal. We wondered whether this approach can enable single sign-out, and if it can't, that's a strong argument against it completely replacing the existing API. We look forward to the outcome of the testing you have planned.
</blockquote>amy to leave the feedback and close
OpenedAug 28, 2024
こんにちは TAG-さん!
I'm requesting a TAG review of Lightweight FedCM.
The goal of this project is to provide a purpose-built API for enabling secure and user-mediated access to cross-site top-level unpartitioned cookies. This is accomplished with integration with the Credential Management API to enable easy integration with alternative authentication mechanisms. A site that wants a user to log in calls the
navigator.credentials.get()
function with arguments defined in this spec the browser ensures there is appropriate user mediation and identity provider opt-in and hands off a token. With those assurances, the browser may also decide there is no additional privacy loss associated with access to unpartitioned state, and choose to automatically grant access to Storage Access requests.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): Federated Identity CG
The group where standardization of this work is intended to be done ("unknown" if not known): Federated Identity WG
Existing major pieces of multi-implementer review or discussion of this design:
Major unresolved issues with or opposition to this design:
window.open
by its design or if it should just accept any general navigational tracking mitigations that may come in the future.This work is being funded by: Mozilla and Google