In the Swiss system, it depends on what they verified. If they required your full ID, that has a document number like a passport and they could track that.
If they did the right thing and only asked for the over 18 bit, then they wouldn't have a trackable identifier.
There's no dynamic analysis done, necessarily. In the Swiss design, fex, SD-JWTs are used for selective disclosure. For those, any information that you can disclose is pre-hashed and included in the signed credential. So `over_18: true` is provided as one of those hashes and I just show this to the verifier.
The verifier gets no other information than the strictly necessary (issuer, expiry, that kind of thing) and the over 18 bit, but can trust that it's from a real credential.
That's not strictly a zero knowledge proof based system, though, but it is prvacy-preserving.
Well, yes, if they use something completely different to what's published and designed.
But no, we're not talking about the case where there's no trust at all in the government, because then you don't get verifiable credentials at all. We're talking about building privacy-preserving credentials that actually have a use.
The revocation checking is implemented in a way where the government doesn't know who you checked and you can even cache the information (if that's good enough for you) so they won't notice at all.
That assumes the companies store the individual tokens, as does the government. Neither of which are part of the design, but could be done if both sides desired it.
The Swiss design actually doesn't store the issued tokens centrally. It only stores a trust root centrally and then a verifier only checks the signature comes from that trust root (slightly simplified).
> Decentralized Identifiers (DID) developed by the W3C represent an identifier standard that provides a subject-controlled method for identifying individuals, organizations, or objects online. In the swiyu Trust Infrastructure, DIDs are utilized as a standard identifier for issuers and verifiers. They are centrally hosted on the swiyu Base Registry.
> In this protocol, the trusted authority issues certifications (“trust statements”) concerning the identity (i.e., who is the real-world identity controlling a DID) and legitimacy (i.e., who is allowed to issue or verify credentials of a specific VC schema) about an entity as SD-JWT VC and publishes these trust statements in the trust registry.
> Token Status Lists are signed, maintained and published by the credential issuers but hosted on the Base Registry.
That's not how that works - they can prove they check by showing logs, rather than VPs. There's even legal limits on what identifiers they can store and for how long. But even ignoring that, they'd be storing only very limited disclosures.
The base registry stores identifiers of issuers and verifiers, not credential holders.
Even the status register does not contain the tokens themselves:
> Within these status lists, each index (i.e., status entry) documents the validity of one VC. The corresponding index is captured in the VC’s metadata to allow for a decentralized status information retrieval that does not require verifiers or the VC holder to contact the issuer.
Of course, each issuer needs to maintain a list of the credentials they have issued in order to be able to ever revoke them. That's unavoidable.
> But even ignoring that, they'd be storing only very limited disclosures.
Just to be clear, here I am not concerned about the verifiers, I am concerned about the authority (Government).
> The base registry stores identifiers of issuers and verifiers, not credential holders.
If the verifiers provide the verification tokens to the Government, can't the Government identify the original issuer even if they don't store them? Don't these tokens contain the DID of the issuer? Please correct me if I'm wrong, maybe I didn't get this part right.
> That's not how that works - they can prove they check by showing logs, rather than VPs
Logs can be manipulated, VPs can't. If I had a company and I was forced to verify users, I'd try to store those VPs for as long as possible, for my own protection.
> There's even legal limits on what identifiers they can store and for how long
I was not aware of this. Is that documented anywhere?
Ah yes, you are right! I was going by ear, rather than by the written version, in fact I can't recall seeing it written. German is a language that I will happily use but don't ask me to write a letter in it, you'll probably need exponential notation to represent the number of errors.
Considering that companies will do everything to avoid doing sensible things that cost money - yes, of course the government has to step in and mandate things like this.
It's no different from safety standards for car manufacturers. Do you think it's ridiculous that the government tells them how to build cars?
And similarly here: If the company is big enough / important enough, then the cost to society if their IT is all fucked up is big enough that the government is justified in ensuring minimum standards. Including for backups.
Denial of facts usually starts with reasonable-sounding inquiry into the details, which makes nuanced discussion of data very hard. Asking if the real number was maybe 5.75 million puts you in company with deniers.
If they did the right thing and only asked for the over 18 bit, then they wouldn't have a trackable identifier.