PaperlayerView exact revision on arXiv

Source-linked AI summary

Deployment of a Blockchain-Based Self-Sovereign Identity

Quinten Stokkink, Johan Pouwelse

arXiv:1806.01926v1cs.DCcs.CRcs.CY

TL;DR

The paper addresses the difficulty of tying public keys to identities in a setting where identity holders should own their identities and passport-level attributes need legal value. It proposes a blockchain-based Self-Sovereign Identity model with legally valid signatures, and reports claim creation and verification within 100 milliseconds across its implementations.

  • Problem

    Digital identity requires binding public keys to identities, while identity holders also need ownership and government-recognized attributes with legal value.

    Source: §I · p. 1, §II · p. 2

  • Method

    The paper presents a Self-Sovereign Identity model with government cooperation and passport-level attributes, supported by blockchain implementations.

    Source: §I · p. 1, §IV · p. 5

  • Results

    All implementations achieve claim creation and claim verification within 100 milliseconds.

    Source: §V · p. 6

  • Takeaways & Limitations

    The authors present the solution as a permissionless decentralized digitized passport intended for adoption beyond its Dutch setting.

    Source: §VII · p. 7

    Group B's wide spread of verification times makes it the implementation most likely to be a target for side-channel attacks linking times to inputs.

    Source: §V · p. 6

Abstract

from arXiv · show

Digital identity is unsolved: after many years of research there is still no trusted communication over the Internet. To provide identity within the context of mutual distrust, this paper presents a blockchain-based digital identity solution. Without depending upon a single trusted third party, the proposed solution achieves passport-level legally valid identity. This solution for making identities Self-Sovereign, builds on a generic provable claim model for which attestations of truth from third parties need to be collected. The claim model is then shown to be both blockchain structure and proof method agnostic. Four different implementations in support of these two claim model properties are shown to offer sub-second performance for claim creation and claim verification. Through the properties of Self-Sovereign Identity, legally valid status and acceptable performance, our solution is considered to be fit for adoption by the general public.

I. INTRODUCTION

The paper frames digital identity as a problem of fragmented data and of binding public keys to identities without relying on a trusted central authority. It proposes a Self-Sovereign Identity model using blockchain and passport-level attributes, while addressing the concern that institutions may not trust users to make truthful claims.

I. INTRODUCTION

  • Fragmented identities leave people with little control over duplicated personal data held by authorities and expose sensitive-data servers as attack targets.Source: §I · p. 1
  • Digital identity remains unresolved because public keys need to be tied to identities, and existing approaches have not achieved adoption.The paper identifies the missing link as a Public Key Infrastructure and notes that PGP's adoption problem persists.Source: §I · p. 1
  • Self-Sovereign Identity lets users build, manage, and use their identities without dependence on a single identity authority, but institutions may still doubt users' claims.Source: §I · p. 1
  • The proposed model uses blockchain in response to the trust problem and aims to avoid assigned infrastructure, third-party control of attributes, and permission requirements for enrollment.The paper describes open enrollment as allowing any user to start using the solution without permission.Source: §I · p. 1
  • The model combines Self-Sovereign Identity with passport-level attributes, developed with the Dutch National Office for Identity Data for a planned pilot for Dutch citizens.The paper says the model could leverage passport-level biometry and describes the pilot as planned for the latter half of 2018.Source: §I · p. 1

II. PROBLEM DESCRIPTION

The problem has two parts: identity holders should own their identities, and those identities need attributes with legal value. The paper argues that personalized blockchains support Self-Sovereign Identity properties, while claims must also be provable.

II. PROBLEM DESCRIPTION

  • The identity problem combines user ownership with passport-level attributes that governments recognize as legally valuable.Source: §II · p. 2

A. Self-Sovereign Identity

  • Personalized blockchains such as TrustChain or The Tangle give users control of their identity chains while retaining transparency and persistence.Source: A. Self-Sovereign Identity · p. 2
  • Permissionless creation of a personal blockchain supports existence, while maintaining and sharing its data gives users access and requires their conscious consent.Source: A. Self-Sovereign Identity · p. 2
  • The paper uses the ten Self-Sovereign Identity properties to derive requirements for claim formats built on personalized blockchains.Source: A. Self-Sovereign Identity · p. 2
  • The paper adds provability as a requirement because claims have no value unless they can be shown to hold true.Source: A. Self-Sovereign Identity · p. 2

B. Legally valid signatures

Government use requires legally valid signatures, which the paper ties to government-approved elliptic-curve keys and recognition of the key holder. Its design pairs personalized blockchains with portable, interoperable, minimized, protective, and provable claims.

B. Legally valid signatures

  • Government-level use requires signatures based on keys of sufficient quality, interpreted here as keys sampled from government-approved elliptic curves.Source: B. Legally valid signatures · p. 2
  • A government institution must recognize the user associated with a safe key before that user's signatures become legally valid.The paper treats government recognition as another claim attested by the government.Source: B. Legally valid signatures · p. 2
  • Legal signatures support auditing because the government must be able to read network state to detect cheating and bind fraud to a legally recognized signer.Source: B. Legally valid signatures · p. 2

III. DESIGN

  • The design combines personalized blockchain structures with claim structures intended to be portable, interoperable, minimized, protective, and provable.Source: §III · p. 3
  • Claims do not carry intrinsic truth, so the design requires proof and attestations from multiple parties to establish trust in a user's claim.Source: §III · p. 3

A. Generic provable claims

The generic claim model uses zero-knowledge proofs to protect privacy and support minimized disclosure, while keeping claims portable across platforms without requiring a blockchain for evaluation. Metadata supports convenient use and upgrading, with names standardizing attributes and timestamps supporting auditing and authentication.

A. Generic provable claims

  • Zero-knowledge proofs let claims disclose information to specific parties without making received information reusable, supporting privacy and protection.Source: A. Generic provable claims · p. 3
  • Zero-knowledge proofs can establish that an attribute falls within a range without disclosing its actual value.The paper gives minimum income as an example and notes that even an attestation such as income being higher than $1 leaks that fact.Source: A. Generic provable claims · p. 3
  • The claims are portable and interoperable, can be evaluated without a blockchain, and need metadata for ease of use and upgrading.Source: A. Generic provable claims · p. 3

1) Name:

  • A shared claim name identifies an attribute, but parties need a naming convention to avoid differing interpretations such as full name versus family name.Source: 1) Name · p. 3

2) Timestamp:

  • Timestamps support fraud auditing by letting verifiers establish that a revocation existed before a later signed timestamp and blockchain tail.Source: 2) Timestamp · p. 3
  • Timestamps can also provide unique proof-of-key-ownership challenges, enabling deferred two-factor authentication through claims.Source: 2) Timestamp · p. 3

3) Validity term:

The section describes how claim validity, modular proof formats, and proof links support the identity system. Proofs can be updated as methods change, while the link lets third parties verify claims.

3) Validity term:

  • After a claim’s validity term expires, its attestations are void in the eyes of the beholder, and the verifier bears the risk of using it.Source: 3) Validity term · p. 3

4) Proof format:

  • A modular proof format supports upgrades as cryptography advances and lets different attributes use different proof methods.For example, age may use a zero-knowledge range proof, while a first name may use a plain trapdoor function.Source: 4) Proof format · p. 3

5) Proof link:

  • Metadata must link an advertised attribute to a proof that third parties can verify as truthfully answered; the linking mechanism may change with the proof method.The passage names publicly verifiable computation and tying the proof into the signature algorithm as possible mechanisms.Source: 5) Proof link · p. 3

B. Chains of claims

The claim chain uses blockchain structure for transparency and persistence in audit logs. It offers passive, intent-based, and active models to match different revocation risks.

B. Chains of claims

  • The three audit-log levels—passive, intent-based, and active—escalate by adding a block, and can coexist in one identity chain, even for the same attribute.They address claims that last indefinitely, claims whose revoked use should be detected and punished, and claims requiring real-time proof of correctness.Source: B. Chains of claims · p. 4

1) Passive:

  • In the passive model, the claim-origin block stores metadata and is added once the first attestation is collected; later attestations can sign its hash instead of repeating the claim.Source: 1) Passive · p. 4
  • The identity owner signs the final block and controls whether it enters their personalized blockchain.Source: 1) Passive · p. 4

2) Intent-based:

Intent-based blocks make withheld revocations detectable through audit logs, while active checks request current proof of correctness. The implementations demonstrate variation in blockchain structures and proof methods.

2) Intent-based:

  • Intent-based blocks support eventual fraud detection: auditors compare the revocation and intent blocks’ shared metadata hash to find timestamp inconsistencies.A verifier may store the blocks or wait for global consensus before transacting.Source: 2) Intent-based · p. 4

3) Active:

  • Active revocation checks require the attesting party to be online; a unique challenge makes its relayed response current and not replayed.The identity owner relays the response and explicitly consents, so the attesting party and verifier do not communicate without the owner’s knowledge.Source: 3) Active · pp. 4–5

IV. IMPLEMENTATIONS

  • The claim model is demonstrated with Proof-of-Work and TrustChain blockchains and different zero-knowledge proof methods.Source: §IV · p. 5
  • The implementations include IPv8 with TrustChain and custom proofs, IdentityChain with interactive single-value and range proofs, Group A with a Bitcoin-like chain, and Group B with QR-code attestations.Source: §IV · p. 5
  • The IPv8 implementation’s key size is described as overkill, its Python code as unsuitable for mobile devices, and its current proofs as limited to exact values.The authors describe a port to Java and plans to support additional proof types.Source: §IV · p. 5

V. EVALUATION

All four implementations complete claim creation and verification within 100 milliseconds, while their timing patterns reveal trade-offs in claim-size flexibility and verification behavior.

V. EVALUATION

  • The comparison measures single-set proofs using 20-byte random inputs, with 100 generated inputs per implementation.A single-set proof is the only proof type supported by all implementations.Source: §V · p. 6
  • IPv8 app claim creation is much slower than the other solutions, likely because per-attribute keys enlarge claims and slow verification.The paper suggests this may be a worthwhile trade-off for securing passport attributes.Source: §V · p. 6
  • IdentityChain is the fastest implementation but is restricted to 20-byte values, illustrating a speed–generality trade-off.The other implementations support arbitrary claim sizes, and the paper identifies proof-mechanism choice as important for both creation and verification speed.Source: §V · p. 6
  • Group B has similar creation and verification times and the widest spread in verification times, making it the most likely side-channel target.Source: §V · p. 6
  • Excluding Group B, claim creation is significantly slower than verification; this pattern does not hold for ClaimChain.The paper relates the pattern to passports being issued less often than they are checked.Source: §V · p. 6
  • All implementations complete claim creation and verification within 100 milliseconds.Figure 4 plots creation and verification times per implementation.Source: §V · pp. 5–6, Figure 4 · p. 6

VI. RELATED WORK

Prior work describes blockchains as identity vessels and develops digital identity through attestation; this paper builds on signatures as attestations of data truth.

VI. RELATED WORK

  • Zyskind et al. describe using blockchains as vessels for identity.Source: §VI · p. 6
  • S. Azouvi et al. present a modern digital-identity approach through attestation.Source: §VI · p. 6
  • This paper builds on digital signatures used as attestations to the truth of data.Source: §VI · p. 6

S. Azouvi et al. paper is attribute value hiding and deployment in a permissionless and Self-Sovereign context.

Related work sets out Self-Sovereign Identity requirements and blockchain-based use cases; this paper is framed as a concrete realization and an abstraction that can encompass specialized claim systems.

S. Azouvi et al. paper is attribute value hiding and deployment in a permissionless and Self-Sovereign context.

VII. CONCLUSION

The paper presents a passport-like, self-sovereign identity solution with sub-second claim creation and verification. It combines user ownership with mechanisms for detecting incorrect claims and revoking attestations.

VII. CONCLUSION

  • The solution was in production in the Netherlands for citizen use in the latter half of 2018, as the second digitized passport solution to go live after Estonia.The paper describes it as a permissionless, decentralized digitized passport and a peer-to-peer identity commons.Source: §VII · p. 7
  • The solution places citizens’ identities in their own hands rather than under a single federated authority.The paper characterizes this as citizens becoming owners of their identities.Source: §VII · p. 7
  • Incorrect proofs can be detected from an incriminating snapshot of the user’s identity captured by verifying parties during a transaction.With legally valid signatures, the individual behind the user’s keys may be punishable by law.Source: §VII · p. 7
  • Revocations of attestations can be detected through blockchain consensus rounds, forming a global audit log for pursuing legal action over identity fraud.For real-time truth checks, messages are routed through the user and not sent between transacting parties without the user’s knowledge and explicit consent.Source: §VII · p. 7
  • Claim creation and verification both take under one second on modern hardware.The paper describes these implementations as making the identity as portable as a passport while retaining digitization benefits.Source: §VII · p. 7
Loading 1806.01926v1…