Aaron Parecki

Right, the time frames / shelf life seem to matter. FWIW, random numbers (as directed identifiers) should work equally well here.

Maybe, but at the end of the day I would assume any crypto will eventually be broken, so it's a game of picking good enough algorithms to avoid correlation in a timeframe that would be a problem.

Hm ok. I'm literally quoting your doc. If the doc is incorrect and/or now dated, just let me know.

I'm going to stop replying on this thread.

Ah that's indeed a reasonable distinction. Still seems like solvable? Like Signal that uses a master identifier and then ephemeral (yet stable) ones?

"The first principle can be solved by the user agent insisting on a progressive disclosure of identification, starting with the minimal disclosure for the most constrained use (e.g. a directed identifier that is recoverable between devices)" 🤔

But there's a big difference in relying on a specific hash function for something that won't matter a day from now (validating an ID token) vs something that can be correlated years later (hashed identifiers in logs)

Sure. I'm sure one could find a hashing function that would age well (I'm making an assumption :) but a lot of stuff breaks if one doesn't :)).

Relying on sha256 as the end of the story seems like a thing that also won't age well. It's only a matter of time until we see sha256 the way we see md5 today.

Was enforcing any part of this discussion?

I actually thought I had already joined, but I haven't yet actually joined a meeting. It's a lot to keep up on with all the other spec work I'm in the middle of 😅

That was fast @aaronpk. Welcome :)

The user is actively choosing to provide an identifier they know. It's not unsanctioned tracking. RE: Firefox, hinting is not the same as enforcing or intercepting.

Does the trick for preventing tracking. Browsers (Firefox?) do that on input boxes type=email in autocomplete.

Does the trick for what? Browsers are not an active party in identity flows.

A directed identified is still a stable identifier for a user. If an RP wants to revert it it is looking into correlating the user with another RP.

Aaron, please join the W3C Federated ID community group so we can discuss these use cases

LMK if you run into a good formulation. FWIW email may be a good analogy and source of inspiration. In browser land, SHA256(user + RP)@idp.example does the trick.

I'm actually really interested in this particular problem right now since Sign In with Apple is probably the biggest example of differing IDs per RP yet the first thing the RPs want to do is resolve that back to an identifiable user.

Oh yeah, that's intentional. It'd be interesting to explore what it could look like otherwise tho.

No, in the sense are these designed such that two different RPs get the same global identifier for the same user?