There's no auth required at this stage of the handshake, so you can test from any number of devices/locations/networks/etc and confirm you get the same value. We could publish it, but it will change every epoch/month. Plus, if you don't trust the service to not issue special key pairs to track you, you probably won't trust us to not do the same when publishing the key material. There are schemes involving third-parties we could employ, but it's trust and turtles all the way down.
A malicious server could maintain separate key pairs for users it wanted to track, but you can't do it for every user because 1) it'd be clear from the WWW-Authenticate header changing, and 2) you'd have to validate tokens against every key, which would quickly get too slow to work.
Makes sense in general, but to make sure I understand it:
> Plus, if you don't trust the service to not issue special key pairs to track you, you probably won't trust us to not do the same publishing the key material.
You could publish it on some sort of blockchain to make sure it can’t be changed and is public for everyone, right?
> A malicious server could maintain separate key pairs for users it wanted to track, but you can't do it for every user because 1) it'd be clear from the WWW-Authenticate header changing, and 2) you'd have to validate tokens against every key, which would quickly get too slow to work.
A malicious server could maintain separate key pairs for users it wanted to track, but you can't do it for every user because 1) it'd be clear from the WWW-Authenticate header changing, and 2) you'd have to validate tokens against every key, which would quickly get too slow to work.