"first-party" token

[annevk]

I'm wondering to what extent it's considered problematic/good if other protocols build on this by exposing a first-party token. E.g., Cross-Origin-Resource-Policy: first-party.

There's been (ignored) pushback on same-site at times, so it might be good to clearly stipulate expectations here. Given there's a proposal for cookies I guess this is part of the deal, but I thought I'd double check.

[mehr1357]

#19

[annevk]

@krgovind I'm not sure we need to discuss this given that first-party sets is already tightly-coupled with cookies now, as I understand it. (I think when I made this comment it wasn't really proposed as a new security boundary, and more as a help with password managers and such.)

[krgovind]

@annevk Thanks for the context! Nonetheless, I am hoping to use this issue for discussion around whether a first-party or same-party style token is appropriate to think about.

We are certainly thinking about a SameParty attribute for cookies (Prior art: First-Party Sets and SameSite Cookies).

Would it also make sense to define a concept of "party" in the HTML (or other appropriate) spec to reference in other work that should reference a privacy boundary? For instance, the storage partitioning key could use "party" instead of "site" as the key. What other such use-cases exist?

[jwrosewell]

There is a general problem across the W3C concerning the definition of "party". A single agreed W3C definition will enable engineering debates to focus on engineering matters.

Also it was agreed in 2016 that the W3C will not take a position on policy matters. See Technology and Policy Interest Group charter responses. If participants wish the W3C to have a policy position then perhaps it is time to try to charter the Technology and Policy Interest Group again? Until there is an agreed policy individual proposals or groups should not seek to define policy.

[johannhof]

(running some triage on old issues on behalf of @krgovind)

With the current proposal FPS is no longer intended to be tied specifically to cookies (and there's probably some potential to improve the wording in the proposal). @annevk with that context, I can imagine that Cross-Origin-Resource-Policy: same-party could indeed be useful to sites, do you agree?

I'll keep this issue open for now to track getting this clarified and potential use cases listed in the applications section.

[annevk]

Only if one presupposes that FPS is useful. 😊

[johannhof]

Right, thanks! I think it's okay to agree on some use cases of FPS and disagree on others and it's a good idea to figure out if there is utility in the same-party concept for web APIs or protections without the notion that this is tied to e.g. relaxing cookies

[johannhof]

This discussion is outdated with regards to the current FPS proposal so I'll close the issue. Feel free to re-open if needed.