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.
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)
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.
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 😅
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.
There are definitely some similarities since they are both adding an identity layer on top of OAuth. IndieAuth is a much smaller surface area tho and does less stuff. Some more details here: indieweb.org/How_is_IndieAut…
Dynamic Client Registration, but afaik no major provider supports this because they *want* RPs to have a pre-established relationship.
We built IndieAuth to avoid the need for any client registration and it works great for that use case: aaronparecki.com/2018/07/07/…
here you are trying to be actually helpful and I've just gone and set up a new parody twitter account @wtf_oauth
now back to work, let me actually read this now 😅