[w3ctag/design-reviews] FedCM as a trust signal for the Storage Access API (Issue #992)

Guten TAG!

I'm requesting a TAG review of [FedCM as a trust signal for the Storage Access API](https://github.com/privacycg/storage-access/blob/main/explainers/storage-access-for-fedcm.md).

In short, this feature will allow developers of FedCM to utilize the Storage Access API (based on the prior user permission given to share cross-site identifiers), conversely, it allows developers using the Storage Access API to more easily upgrade to FedCM which may offer a better user experience in many cases.

From the explainer, note the [key use cases](https://github.com/privacycg/storage-access/blob/main/explainers/storage-access-for-fedcm.md#example-use-cases) as well as a [discussion of the slightly different privacy and security properties of the two APIs](https://github.com/explainers-by-googlers/storage-access-for-fedcm?tab=readme-ov-file#privacy-considerations) and [how we chose to reconcile them](https://github.com/privacycg/storage-access/blob/main/explainers/storage-access-for-fedcm.md#dealing-with-scope-differences).

  - Explainer¹: https://github.com/privacycg/storage-access/blob/main/explainers/storage-access-for-fedcm.md
  - Specification: https://privacycg.github.io/storage-access/
  - WPT Tests: https://wpt.fyi/results/fedcm/fedcm-storage-access-api-autogrant.tentative.https.sub.html?label=experimental&label=master&aligned
  - User research:
  - Security and Privacy self-review²: Since this is a simple add-on to SAA, it might be most helpful to read the [SAA questionnaire](https://github.com/privacycg/storage-access/blob/main/tag-security-questionnaire.md) as well as the [questionnaire for this feature](https://github.com/privacycg/storage-access/blob/main/explainers/fedcm-saa-privacy-questionnaire.md).
  - GitHub repo: https://github.com/privacycg/storage-access
  - Primary contacts: 
      - Johann Hofmann (@johannhof), Google, Editor
      - Chris Fredrickson (@cfredric), Google, Editor
  - Organization/project driving the specification: Google
  - Multi-stakeholder support³:
    - Chromium comments: Supportive
    - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1065
    - WebKit comments: https://github.com/WebKit/standards-positions/issues/390
  - Status/issue trackers for implementations⁴:
    - https://chromestatus.com/feature/5116478702747648
    - https://bugzilla.mozilla.org/show_bug.cgi?id=1917280
    - https://bugs.webkit.org/show_bug.cgi?id=279267

Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - Relevant time constraints or deadlines:
    - We're looking to ship this API in Chrome within the next few releases
  - The group where the work on this specification is currently being done:
    - PrivacyCG / FedID CG
  - The group where standardization of this work is intended to be done (if different from the current group): WHATWG
  - Major unresolved issues with or opposition to this specification: One thing that we still have to fully figure out is how to make this work well with [Storage Access Headers](https://github.com/privacycg/storage-access-headers), given that the privacy properties of this proposal mandate the use of the FedCM permissions policy which would limit utility of SAH for some developers.
  - This work is being funded by: Google

You should also know that...

The [Lightweight FedCM](https://github.com/fedidcg/LightweightFedCM) work driven by @bvandersloot-mozilla et al integrates with this feature to ensure developers using the API get access to cross-site cookies upon completing the proposed user permission flow. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/992
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/992@github.com>