High-Privacy Verifiable Claims

Tristan Hoy
Aug 23, 2017 · 6 min read

This article proposes a variation of Verifiable Claims that permits a greater range of privacy configurations.

This variation aims to acheive the following goals:

  1. Make disclosure of claims attributes (including attribute metadata) opt-in
  2. Allow claims to be verified and bundled as dependencies while still preserving #1
  3. Allow the revocation status of claims to be checked anonymously while still preserving #1
  4. Make claims non-correlating by default

This article is in a DRAFT state and may be updated at any time.

Feedback welcome.

Scope / Core Concepts

This identity schema is concerned only with the schematic elements common to all identity systems (illustration by Tim Bouma — read “Recipient” as “Holder”):

Source

This schema defines an ecosystem where claims are all that exist.

And this is the world we actually live in: passports, driver’s licenses, birth certificates, SSL certificates are all claims — and a person’s “identity” is the set of claims they choose to reveal in a specific interaction.

In the scope of this schema, there are no means by which an issuer, holder or verifier is identified other than with claims.

Authentication

Presentation of a claim is not sufficient to verify identity: the presenter must also prove that that they are the same party that the claim was issued to.

This can be achieved in a private, non-correlating way by following the example of SSL:

  • Claims holder generates a single-use signing keypair and provides the public key in their claims request (strictly one claim per key)
  • Claims issuer generates a claim with the public key in place of a subject identifier
  • Claims holder can verify ownership of their claims by signing challenges issued by the claims verifier

This authentication method does not require any kind of registry or other centralized service that could be subject to a denial of service attack or hacked to retrieve metadata.

The “subject” of a claim is one of the biggest risks to privacy via correlation — and by replacing it with a unique public key this can be eliminated (however this doesn’t prevent the contents of two claims from being correlatable).

Revocation

The ability to revoke fake, hacked, spam and lost identities/claims is critical to the success of an identity ecosystem (with success being defined as the extent to which identities in a given ecosystem are trusted by participants).

Logically, the issuer needs a mechanism by which it can inform the network that a given claim has been revoked. A verifier could issue a request to the issuer at the time of verification (e.g. OCSP) — however this is not desirable from a privacy perspective, as it reveals the verifier/holder relationship to the issuer.

Unless complex cryptography is used (“Private Set Memebership”), the verifier needs to obtain their own copy of an issuer’s revocation list in order to protect the privacy of their queries.

As each claim is uniquely identified by its public key, the entry for a claim in a revocation list should be a hash of the public key, with no other details used to generate the hash (so that knowledge of the claim contents is not required to check revocation).

This makes the revocation list sufficiently privacy-preserving that it may be distributed by any means.

Bloom filters or other space-efficient data structures supporting probablistic or deterministic set membership queries (such as cryptographic accumulators) may be used to reduce the compute or network cost of performing revocation checks.

However the revocation list is structured or distributed, revocations must be authenticated (e.g. signed) by the issuer, either individually or as a list.

Dependent Claims

Claims dependencies are an important optimisation — they provide an efficient mechanism by which a claims issuer can signal the conditions under which they would automatically revoke their claim.

By specifying a claim dependency, the claims issuer is asserting that “claim X is issued on the basis of prerequisite claim Y being valid, and in the event that prerequisite claim Y is revoked or expired, claim X must be considered invalid”.

As such, there is never any need for a claims verifier to know the contents of a prerequisite claim, only the revocation status and validity/expiry. This does not prevent the verifier from requiring that the claims holder provides the full contents of a given prerequisite claim — but this is specifically opt-in.

If a claim is to be issued on the basis of owning another claim or set of claims, then the issuers, public keys and validity periods of those claims — and any claims they in turn depend on — must be included as dependencies. A claim must provide the full dependency graph, and that dependency graph must be fully authenticated by the original issuers (so that issuers of dependent claims are not trusted to correctly transfer dependencies).

Claims dependencies, however, introduce scope for correlation: where multiple sibling claims are dependent on a single claim, it is recommended that the original claim is reissued with a new public key (before or after the fact) to prevent correlation via common dependencies.

Logical Schema

The following logical schema attempts to implement all of the above concepts.

The phrase “subject” has been removed and replaced with “public key” to ensure the intent of the schema is clear.

  • Issuer: Claim about the issuer’s capabilities/permissions (may be self-certifying)
  • Public Key: globally unique, single-claim public key used to authenticate the claim holder
  • Dependencies: nested array of (Dependency)
  • Valid From: the date/time from which the claim is considered to be valid
  • Valid To: the date/time upon which the claim is considered to be expired
  • Attributes: nested array of (Attribute)
  • Signature: digital signature of (public key, dependencies, valid from, valid to, attribute hashes) using the private key of the issuer’s claim

A Dependency is simply a “view” of a Claim with only the hash of each attribute (not even the name of the attribute is revealed).

  • Name: The name of the attribute
  • Value: The value assigned to the attribute
  • Nonce: A random cryptographic nonce to prevent brute forcing of name/value
  • Hash: A hash of (name, value, nonce)
  • Hash: A hash of (name, value, nonce)
  • Public Key Hash: hash of (claim public key)
  • Timestamp: the time that the revocation was effected
  • Revocations: array of (Revocation)
  • Signature: digital signature of (revocations) using the private key of the issuer’s claim

As the revocations reveal nothing about the claims they represent (not even the public keys), the Revocation List is considered public.

Privacy

Here’s how this identity system stacks up against the eight definitions of claims-based identity privacy:

  1. Data privacy: The contents of a claim MUST NOT be visible except to those strictly requiring this information [Depends on 4, 5 and 7]
  2. Ownership privacy: The exact number and nature of all claims owned by a claims holder MUST NOT be visible to any party except the claims holder [CHECK]
  3. Interaction privacy: The interactions and relationships between claims holders and claims verifiers MUST NOT be visible by default to any third party (this includes revocation checks) [CHECK]
  4. Revocation privacy: Revocation notices MUST NOT reveal the contents or subject of the claims they revoke [CHECK]
  5. Revocation data privacy: Revocation notices MUST NOT require knowledge of the contents of a claim in order to check its revocation status [CHECK]
  6. Correlation privacy: Two claims issued to a single claims holder MUST be indistinguishable from two claims issued to two different claims holders (unless the content of the claims is specifically related) [CHECK]
  7. Claims dependency privacy: A claim issued on the basis of owning another prerequisite claim MUST be verifiable without revealing the contents of the prerequisite claim (full verification is opt-in) [CHECK]
  8. Claims dependency correlation privacy: Two claims that share a common dependency MUST be indistinguishable from two claims that share no common dependency (unless the content of the claims is specifically related) [CHECK*]

*Requires the use of claims duplication (see above), unless there is a clever cryptographic solution to this problem.

As this schema does not inherently violate any of the eight definitions of privacy, use of this schema supports (but does not guarantee) the privacy of an identity system.

Conclusion

By stripping identity back to the bare essentials — claims — it is possible to realise a schema for expressing core identity concepts that’s private by default but otherwise unopinionated, offering maximum interoperability and flexibility to implementers.

This schema is also unopinonated about trust — as claims can be issued and chained in any way, this scheme supports certificate authority, web of trust, reputation and hybrid systems*.

  • Inclusion of a trust system in this list is not to be taken as an endorsement.

TOKENIZE.IO

A deeper look into the intersection of identity, cryptography, privacy, trust and the internet

)

Tristan Hoy

Written by

TOKENIZE.IO

A deeper look into the intersection of identity, cryptography, privacy, trust and the internet

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade