Clarify that 1p's are just delegating the right to recognize a user, not anything about that user

[michaelkleber]

The "Third Parties can be allowed access to a first-party identity" section is confusing. In https://twitter.com/Chronotope/status/1164574958061797378 et seq. Aram Zucker-Scharff read it as implying that the 1p tells its 3p's something PII-like about the user.

The intention is just that the 1p says "OK every time user number 12345 is on my site, the following 3p's on the page get to know the number 12345, and all other 3p's can't tell my users apart from each other."

[jyasskin]

I'd read this point as saying that a 1p can choose to send its notion of the user's ID to an embedded 3p iframe, and there's not much the web platform can do about it unless we want to completely remove postMessage().

That meant I was a bit confused by "merely based on script access to a browsing context" since clearly script running in the 1p context can get access to any information known by the 1p, including that user ID, but I figure that, because different 1ps will store their user ID in different variables, this requires the 3p to write and maintain custom code for each 1p, which doesn't scale, so many fewer 3ps will be able to afford to gather user profiles.

Have I misread the section too?

[michaelkleber]

My goal of that section was challenging precisely the part that confused you! Script running on page can get access to any state stored in JS, which is why I think the browser needs a way to handle per-1p identity without storing state in JS.

Today the Http-Only cookie is the mechanism that makes this possible. In a world where a 1p can tell the browser that some of its 3p's should get a per-1p-identity-token HTTP header, we can keep identity under control and out of JS state entirely.

[jyasskin]

Thanks. I might phrase that something like ...

1. A first party can choose to share its notion of the user's identity to a third-party nested browsing context. It's a non-goal to remove this ability, since that would require removing Window.postMessage().
2. Many ad systems ask the first party to run third-party script in the first party's browsing context. If the first party exposes their user ID to their own Javascript, a third party willing to write specialized code for each first party can extract that user ID and send it to a third-party iframe. The web platform must not define a standard location that all first parties store their user IDs, because that would dramatically reduce the cost to third parties of extracting those user IDs.
3. The web platform should provide a way for a first party to convey its notion of the user's identity to selected third party nested browsing contexts without exposing that identity to first-party javascript.

Two notes on the wording above:

A. Talking about "all first parties" is awkward. Is that the right term? Should we use "websites"? Or "top-level browsing contexts"?

B. I wrote "its notion of the user's identity" and "their user ID" a couple times above. We should have a term for this that's clearer than "identity". No matter how strongly you define "identity" in the introduction as changing from first party to first party, readers are still going to mix it up with real-world identities that don't change from site to site. This overlaps with #5.