Apple already shipped attestation on the web, and we barely noticed

I kind of get both sides here. If we take the "see the best of others intentions" then a web that is populated by identified humans (and their authorised proxies!) is likely to be the "cleanest", most ideal web space we can see (a web full of sock puppets and link farms is not ideal).

The clearest end point for this is some government issued digital ID that just asserts who you are, acts as a login etc.

You can see this as a stepping stone to there. if you squint.

Is it the idealism of the 70s coke to life? No. Is it some sane compromise - I think so.

What if we cannot trust our government ? Sorry it is pretty sure that no internet is going to solve that. That's on the real world.

> The clearest end point for this is some government issued digital ID that just asserts who you are, acts as a login etc.

Already exists in a bunch of countries. Works better in some than in others.

The issue is that you don't want everything tied to that ID. In a less than ideal world, ideally the ID would just attest that some random pseudo-ID is real. Like Webauthn, kinda.

How would a user ever verify that every attlestation/id check isn't recording their web activity?

Hash and sign functions usually don't allow reversal of those operations. Attestation doesn't require more cryptography.

It's kinda silly to start discussing implementation details of something that doesn't exist. Not to mention considering the alternative which is quite a bit more invasive than having an attested private pseodoidentity would be.

I'm less concerned with reversing hashes and more concerned with tracking via the attlestation provider.

What is stopping them from recording the value returned to you that is then passed to the site you tried to visit? Does the data provided to the integrity checker allow for identification? Could the original vendor pass some value to use in the integrity check to prevent replay attacks, and could that value itself encode your personal information?

> What is stopping them from recording the value returned to you that is then passed to the site you tried to visit?

> Could the original vendor pass some value to use in the integrity check to prevent replay attacks, and could that value itself encode your personal information?

Well that value is most likely a cryptographic signature, a "challenge" or a combination of both. Unless there's some separate payload you can't really hide arbitrary data in hashes/signatures that would be used in such a process.

In the end "could" is a very loose word, PII as such is not really part of the process. In this current (Apple's PAT) case, the information is "you have an Apple device", can't currently hide anything else in that.

Thanks for the response. As a second question, would what prevent someone with an "approved" apple device from firing off a bunch of token requests and then distributing those tokens to different entities for those entities to submit to the origin to pass the validation test?