In the presentation protocol, Users can selectively disclose any property of the attributes wrapped inside one or more of the U-Prove 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 U-Prove Token but also across U-Prove 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.

U-Prove Tokens can be issued in such a manner that not even collusions of Verifiers and Issuers can trace the presentation of an U-Prove Token to its issuing event, or determine whether or not two presented U-Prove 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 U-Prove 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 U-Prove 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 U-Prove 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 U-Prove 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 U-Prove Token on the basis of one or more previously issued U-Prove 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 U-Prove 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 U-Prove Token (or copies thereof) by encoding a User-confidential attribute into the U-Prove Token.

Different Users can be prevented from pooling their U-Prove Tokens. Hereto Issuers encode a User identifier into each issued U-Prove Token, and Verifiers require multiple U-Prove 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 U-Prove Token holder can demonstrate this without disclosing the encoded identifier, but colluding U-Prove Token holders cannot pass the inspection.

To prevent Users from discarding U-Prove Tokens that contain unfavorable attributes, Issuers can wrap these attributes into U-Prove Tokens that must always be revealed. For example, a mark for drunk driving can be tied into a driver’s license U-Prove 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 U-Prove Tokens that are untraceable only when used no more times than allowed. In the case of a fraud all the attributes wrapped in the U-Prove Token can be efficiently computed from the presentation protocol transcripts. Thus, by encoding in each limited-use U-Prove 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.

U-Prove 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 U-Prove Token. This works on the basis of the principle of exclusion: Users of U-Prove 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 U-Prove 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 U-Prove Tokens to which Users choose to attach encrypted identifiers.

When presenting an U-Prove 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 U-Prove 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 U-Prove Tokens at issuing time, and actively cooperate at presentation time. Additionally, lock-out does not imply traceability.

All of a User’s U-Prove Tokens can be blacklisted on the basis of any single one of the User’s U-Prove Tokens, without anyone needing to know the User to whom the U-Prove Token has been issued. This allows the blacklisting of Users who abuse Verifier services under one U-Prove Token and attempt to continue using services on the basis of other U-Prove Tokens. The technique works even when all U-Prove 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 U-Prove Tokens at issuing time, and actively cooperate at presentation time. Additionally, lock-out does not imply traceability.

The U-Prove 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 U-Prove 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 U-Prove 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 U-Prove Tokens they issue.