In the presentation protocol, Users can selectively disclose any property of the attributes wrapped inside one or more of the ID Tokens that have been issued to them, while unconditionally hiding any other information about the attributes. Properties can be proven not only for attributes within a single ID Token but also across ID Tokens (of the same and even of multiple Users). When used in combination with the next feature, Users are guaranteed fine-grained privacy control not only vis-à-vis Verifiers but also vis-à-vis Issuers.

ID Tokens can be issued in such a manner that not even collusions of Verifiers and Issuers can trace the presentation of an ID Token to its issuing event, or determine whether or not two presented ID Tokens were issued to the same User. When used in combination with the selective disclosure feature, Verifiers and Issuers can infer no more than what can be inferred from the attribute properties that Users expressly disclose to Verifiers.

A User can present an ID Token in such a manner that (1) the Verifier is left with no non-repudiable transaction evidence at all (much like showing a paper-based certificate without letting the other party make a photocopy), or (2) the Verifier is left with non-repudiable transaction evidence of only a User-designated part of the User-disclosed attribute property (much like allowing a verifier to make a photocopy of a paper-based certificate after crossing out some of the information).

A Verifier can verify an ID Token in such a manner that the Verifier is left with non-repudiable transaction evidence of only a portion of the User-disclosed attribute property. This allows the Verifier to forward User-authenticated audit trail data to a central party (e.g., to enable status validation, fraud detection, and data flow analysis) while preserving the Verifier’s privacy interests vis-à-vis the central party. In case of a dispute, the Verifier can retroactively disclose the hidden portion of the User-disclosed attribute property, or any part of it.

An Issuer can issue an ID Token containing attributes that it never sees and that it is unable to learn. More generally, the User or any other party can contribute attributes to ID Tokens in such a manner that the Issuer will only learn a property of the contributed attributes.

In a similar fashion, an Issuer can issue a new ID Token on the basis of one or more previously issued ID Tokens presented to it, without needing to know the attributes contained within them. In the process, the Issuer can increment or otherwise update any of the attributes, without knowing them.

It is not possible to present an ID Token without knowing (and applying) all the attributes encoded within it, even though the selective disclosure property enables Users to hide attributes. Thus, an Issuer can discourage a User from fraudulently transferring an ID Token (or copies thereof) by encoding a User-confidential attribute into the ID Token.

Different Users can be prevented from pooling their ID Tokens. Hereto Issuers encode a User identifier into each issued ID Token, and Verifiers require multiple ID Tokens presented in combination to be accompanied by a proof that they all contain the same encoded identifier. Owing to the selective disclosure property, an honest ID Token holder can demonstrate this without disclosing the encoded identifier, but colluding ID Token holders cannot pass the inspection.

To prevent Users from discarding ID Tokens that contain unfavorable attributes, Issuers can wrap these attributes into ID Tokens that must always be revealed. For example, a mark for drunk driving can be tied into a driver’s license ID Token. Owing to the selective disclosure property, Users can hide negative attributes if they do not need to be disclosed.

Issuers can issue limited-use ID Tokens that are untraceable only when used no more times than allowed. In the case of a fraud all the attributes wrapped in the ID Token can be efficiently computed from the presentation protocol transcripts. Thus, by encoding in each limited-use ID Token a User identifier attribute, which need never be revealed, Issuers can trace fraudulent Users. At the same time, even a collusion of Verifiers and Issuers cannot frame an honest User.

ID Tokens can be issued in such a manner that the Issuer in collaboration with its entire community of Users can trace which User presented a particular ID Token. This works on the basis of the principle of exclusion: Users of ID Tokens can prove that they are not the originator of a transaction with a Verifier (on the basis of the presentation protocol transcript) if and only if they indeed did not originate the transaction.

In the presentation protocol, a User can attach a verifiable encryption (under the public key of a designated escrow agency) of an identifier encoded into the ID Token that the User presents. This will enable the escrow agency to retroactively trace the User who conducted that presentation protocol by decrypting the encrypted identifier. We stress that this is not systemic key escrow. The tracing power of escrow agencies is limited to exactly those ID Tokens to which Users choose to attach encrypted identifiers.

When presenting an ID Token, the User can efficiently demonstrate that an encoded User identifier is not listed on a blacklist, without disclosing any information about the identifier. This enables Issuers to “un-enroll” Users to whom they have issued ID Tokens that have not yet expired, without violating the privacy of Users who pass the blacklist verification process. This lock-out technique is not based on key escrow: User lock-out is possible only for Users who consent to the encoding of certain attributes into their ID Tokens at issuing time, and actively cooperate at presentation time. Additionally, lock-out does not imply traceability.

All of a User’s ID Tokens can be blacklisted on the basis of any single one of the User’s ID Tokens, without anyone needing to know the User to whom the ID Token has been issued. This allows the blacklisting of Users who abuse Verifier services under one ID Token and attempt to continue using services on the basis of other ID Tokens. The technique works even when all ID Tokens are unconditionally unlinkable and untraceable, and does not violate the privacy of Users who pass the blacklist verification process. This lock-out technique is not based on key escrow: User lock-out is possible only for Users who consent to the encoding of certain attributes into their ID Tokens at issuing time, and actively cooperate at presentation time. Additionally, lock-out does not imply traceability.

The ID Token protocols are such that Users cannot bypass the security logic of their trusted module without a physical device attack aimed at extracting a module’s private key. Any kind of security logic can be programmed into these trusted modules to provide (1) a layer of hardware protection on top of any of the cryptographic security protections, and (2) hardware protection against any unauthorized behavior by Users that cryptographic security techniques cannot address. This allows for two-factor security as well as three-factor security (whereby the User must unlock the trusted module using a biometric).

Users can interpose any computer of their own choice in between their trusted modules and Verifiers, in such a manner that their trusted module cannot bypass any of the above privacy guarantees, even in collusion attacks involving Issuers and Verifiers. The User’s interposed device can inspect and sanction any message flow into and out of the User’s trusted module.

Virtually all ID Token handling can be off-loaded securely from the User’s trusted module to the User’s interposed device. This allows for literally millions of ID Tokens to be issued in such a manner that they all leverage the private key of the same constrained trusted module, such as an 8-bit smartcard; the security logic protections programmed in the trusted module will apply with full force, while the trusted module cannot compromise the privacy and security interests of its User.

Different Issuers can all leverage the same trusted module to independently derive the security benefits of that module, without knowing the private key of the trusted module. Issuers do not need to trust anyone else (including the trusted module supplier or anyone who manages to physically break into the trusted module) with regard to any of the above cryptographic security protections for the ID Tokens they issue.