Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FedCM as a trust signal for the Storage Access API #46

Closed
johannhof opened this issue Mar 20, 2024 · 4 comments
Closed

FedCM as a trust signal for the Storage Access API #46

johannhof opened this issue Mar 20, 2024 · 4 comments
Labels
interest: blink Implementer interest from Blink (e.g. Brave, Google/Chrome, Microsoft/Edge) interest: gecko Implementer interest from Gecko (e.g. Mozilla/Firefox, Cliqz) moved to repo This proposal has its own GitHub repository

Comments

@johannhof
Copy link
Member

johannhof commented Mar 20, 2024

See privacycg/storage-access#196, this was intended to live in FedID CG but chairs thought that because of the way it integrates with SAA it may actually be a potential PrivacyCG work item. Comment from privacycg/storage-access#196:

In the FedID CG we have been w3c-fedid/FedCM#467 the merits of autogranting Storage Access calls based on existing FedCM grants. Based on the positive reception of this idea we wrote up an explainer of how we think this should work from a technical perspective: https://github.com/explainers-by-googlers/storage-access-for-fedcm

Relevant for this specification is that instead of simply creating a new storage-access permission on a successful FedCM prompt, we'd update Storage Access to look at existing FedCM accounts connections to establish whether storage access can be granted without an additional prompt. Benefits to this include the ability to scope the grant to the privacy boundaries of FedCM, and avoiding two simultaneous permission grants for the user (agent) to manage.

This issue is tracking discussion and integration on the Privacy CG side.

cc @bvandersloot-mozilla @annevk @martinthomson @cfredric @hflanagan @samuelgoto @yi-gu

@bvandersloot-mozilla
Copy link

I'm supportive of incubating this. It intuitively makes sense to me that an identity link opt in provides better UI/UX and FedCM already breaks the site privacy boundary.

@martinthomson
Copy link

The chairs discussed this and concluded that there was sufficient support to incubate. Consider this OK to start incubating into SAA. We'll defer to the editors on how they want to manage the details, but we can use privacycg/storage-access#196 to track the effort.

@martinthomson martinthomson added interest: gecko Implementer interest from Gecko (e.g. Mozilla/Firefox, Cliqz) interest: blink Implementer interest from Blink (e.g. Brave, Google/Chrome, Microsoft/Edge) moved to repo This proposal has its own GitHub repository labels May 2, 2024
@johannhof
Copy link
Member Author

Thanks Martin! We'll follow up with a PR on SAA. With regards to https://github.com/explainers-by-googlers/storage-access-for-fedcm, would you like me to move the explainer to this org?

@martinthomson
Copy link

Well, that's a different question. We'd appreciate having some explanation, so adding the document -- or its content -- to the existing storage access explainer(s) seems the right thing to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interest: blink Implementer interest from Blink (e.g. Brave, Google/Chrome, Microsoft/Edge) interest: gecko Implementer interest from Gecko (e.g. Mozilla/Firefox, Cliqz) moved to repo This proposal has its own GitHub repository
Projects
None yet
Development

No branches or pull requests

3 participants