Source-linked AI summary
A First Look at Identity Management Schemes on the Blockchain
Paul Dunphy, Fabien A. P. Petitcolas
TL;DR
Internet identity management remains fragmented, motivating DLT-based schemes that promise greater decentralisation, transparency, and user control. The paper surveys the emerging landscape and evaluates uPort, ShoCard, and Sovrin with Cameron’s laws of identity, finding that DLT is not a silver-bullet solution and that user experience remains a major unresolved issue.
Problem
Internet IdM remains fragmented across domain-specific systems, and the paper asks whether DLT-based proposals can extend beyond previous approaches without creating new identity one-offs.
Method
The paper selects technically scrutable DLT-based IdM proposals and evaluates three representative schemes using Cameron’s laws of identity.
Results
The evaluation concludes that DLT is not a silver-bullet solution for IdM, while the reviewed schemes show differing support for identifier sharing and publicity.
Takeaways & Limitations
DLT-based IdM offers promising mechanisms for decentralisation and user control, but its current schemes retain limitations that prevent straightforward fulfilment of their goals.
Takeaways & Limitations
The schemes’ user-experience requirements are poorly understood, with a widespread assumption that users can manage cryptographic keys and understand DLT implications for identity data.
Abstract
from arXiv · showhide
The emergence of distributed ledger technology (DLT) based upon a blockchain data structure, has given rise to new approaches to identity management that aim to upend dominant approaches to providing and consuming digital identities. These new approaches to identity management (IdM) propose to enhance decentralisation, transparency and user control in transactions that involve identity information; but, given the historical challenge to design IdM, can these new DLT-based schemes deliver on their lofty goals? We introduce the emerging landscape of DLT-based IdM, and evaluate three representative proposals: uPort; ShoCard; and Sovrin; using the analytic lens of a seminal framework that characterises the nature of successful IdM schemes.
1 Introduction
Internet identity management remains fragmented across domain-specific systems, while centralised models face data-breach risks. DLT-based IdM is proposed to improve decentralisation, transparency, inclusiveness, cost, and user control, but its inevitability remains an open question.
- Current challenges: Internet IdM remains a patchwork of domain-specific systems that interact little, while centralised models face increasingly regular data breaches.These breaches can lead to reputation damage.
- DLT rationale: DLT enables a shared ledger designed to support consensus, transparency, and transaction integrity without a central authority.The ledger is an append-only shared record maintained by a globally decentralised network.
- Proposed benefits: Proposed DLT-based IdM benefits include decentralised control, tamper resistance, greater inclusiveness, cost savings, and user control over digital identifiers.The proposals aim to reduce reliance on central identity providers and replicated personal information.
- Research question: The paper asks whether DLT-based IdM can deliver these proposed benefits or whether it will create another set of identity one-offs.The question is framed against the historical difficulty of designing interoperable IdM systems.
2 Identity management on the blockchain?
The paper places emerging blockchain identity schemes within established IdM concepts and asks whether they extend beyond earlier naming systems without creating new isolated solutions. It evaluates representative schemes using Cameron’s laws of identity.
- Identity management: IdM manages the lifecycle of identity attributes within a domain, and federated systems let users apply identity information across security domains.Most current schemes are centralised, although identities can be federated beyond one organisation.
- Core IdM function: A fundamental IdM function is securely binding an identifier to attributes such as a name, age, or credit rating.Earlier systems including Namecoin and Blockstack focused on decentralised naming and public-key bindings.
- Research gap: Recent decentralised identity schemes aim to provide a broader suite of IdM functions, but had not yet received systematic evaluation.The paper tests whether they go beyond previous approaches or create new identity one-offs.
- Study scope: The authors selected technically scrutable proposals, excluded naming-only schemes, and identified self-sovereign identity among the resulting categories.Self-sovereign identity is owned and controlled by its owner without external administrative authority or removal.
- Evaluation approach: The evaluation uses Cameron’s laws of identity because they cover security, privacy, and user experience while remaining flexible across heterogeneous early-stage schemes.The framework includes user control, minimal disclosure, justifiable parties, directed identity, pluralism, and human integration.
3 uPort
uPort is an open-source decentralised identity framework built around Ethereum smart contracts, mobile-held keys, and a registry linking identifiers to attributes. Its design increases user control but leaves important privacy, recovery, proofing, and usability concerns.
- 3 uPort: uPort targets decentralised identity for Ethereum DApps as well as traditional applications such as email and banking.It is implemented as an open-source framework.
- Design: Each uPort identity uses controller and proxy smart-contract templates, with a mobile application creating an asymmetric key pair and submitting an Ethereum transaction.The smart contracts regulate data and ether movements on Ethereum.
- Key recovery: Users can retain a persistent uPortID after losing cryptographic keys by appointing trustees who vote to replace the controller’s public key.Recovery depends on reaching a trustee quorum.
- Attribute mapping: The uPort registry maps uPortIDs to identity attributes, allows only each owner to modify its attributes, and stores a hash of the JSON structure rather than large data volumes.Any entity can query the registry, while only the owner controls modifications to that identity’s attributes.
- Privacy: uPort’s registry can expose metadata about attributes or relationships, and overreliance on it may compromise privacy despite encrypted individual attributes.The overall JSON structure remains visible.
- Directed identity: Nondisclosed uPortIDs may be discoverable by curious Ethereum nodes through smart-contract analysis, so their practical privacy remains unresolved.Users can improve discreet disclosure by creating different uPortIDs and avoiding the registry.
- Identity proofing: uPort does not perform identity proofing, and owner-only write access lets users selectively discard negative attributes such as poor credit scores.The framework instead supports gathering attributes from external trust providers.
- Human integration: The mobile application offers consistent QR-code interactions, but lacks education about placing personally identifiable information on an immutable and transparent DLT.The paper identifies user education as increasingly pressing in the context of GDPR.
4.1 Design
Sovrin combines user-controlled identifiers and anonymous credentials with a permissioned ledger, agents, and trustee-based key recovery. Its architecture supports selective and contextual sharing, but depends on stewards, agencies, and unresolved user-experience assumptions.
- 4.1 Design: Sovrin lets users generate multiple unlinkable identifiers, each controlled by a different asymmetric key pair, for contextual privacy.Identifiers follow the Decentralised Identifier specification and include keys and transaction metadata.
- 4.1 Design: Sovrin’s permissioned ledger is written, distributed, and replicated among stewards using the Plenum Byzantine fault-tolerant consensus protocol.The ledger contains transactions associated with specific identifiers.
- 4.1 Design: Permissioned consensus avoids expensive proof-of-work, reducing node energy costs and improving transaction throughput, while trust rests on both people and code.The design uses a globally distributed ledger as a common root of trust.
- 4.1 Design: Users interact through mobile applications and software agents that provide addressable endpoints, backup, and encrypted credential storage.Agencies may operate agents for users, although users can run them on their own servers.
- 4.1 Design: Sovrin’s trustee-based recovery requires a specified quorum to sign a new identity-record transaction that stewards verify.Cryptographic keys are stored on the user’s mobile device.
- 4.1 Design: Anonymous and attribute-based credentials let users select which credentials to share, while agents and mobile devices can transmit them over secure channels.The ledger can identify the correct network endpoint without requiring attributes to be stored there.
- 4.2 Analysis: Sovrin still relies on agencies and ledger stewards, so an agency’s implementation could place substantial information in its hands.Agencies occupy a necessary and justifiable place in the identity relationship.
- 4.2 Analysis: Sovrin supports public and discreet identifiers, including different identifiers and key pairs for different parties to avoid correlation handles.Public organisations can publish their full identity while users can publish only identifiers.
5 ShoCard
ShoCard binds trusted credentials and additional attributes to a user identifier through hashes recorded in Bitcoin, while a central server mediates encrypted certification exchange. Its design gives users control over sharing but retains practical centralisation, adoption barriers, and blockchain-settlement delays.
- Design: ShoCard binds a user identifier, trusted credential, and additional identity attributes through cryptographic hashes stored in Bitcoin transactions.Its primary use cases are face-to-face and online identity verification.
- Design: ShoCard uses Bitcoin to timestamp signed hashes, while a central server intermediates encrypted identity-information exchange between users and relying parties.The scheme proceeds through bootstrapping, certification, and validation.
- Bootstrapping: During bootstrapping, the mobile application generates an asymmetric key pair, encrypts scanned credentials, and embeds their signed hash in a Bitcoin transaction.The resulting transaction number becomes the user’s ShoCardID and points to the ShoCard seal.
- Certification: During certification, providers verify the user’s seal and keys, then record signed hashes of new attributes in Bitcoin transactions linked to the ShoCardID.Encrypted certification envelopes can be stored by the ShoCard server, which does not learn the encryption key.
- Analysis: ShoCard’s central server reduces plaintext-data exposure and leaves sharing under end-user control, but its continued operation affects the longitudinal existence of ShoCardIDs.If the company ceased to exist, users could not use acquired certifications; the scheme is therefore more centralised in practice than its DLT reliance suggests.
- Analysis: ShoCard relies on existing trusted credentials, supports only unidirectional identifiers, and requires bespoke provider integrations, limiting suitability for some accounts and reusable-certification ecosystems.Users may also need to include more personal information than intended in their seal.
- Deployability: Bitcoin settlement can take about one hour on average, creating challenges where certification settlement must be real-time.Bitcoin transactions average ten minutes to mine, with six additional blocks recommended for settlement confidence.
6 Discussion
The evaluation finds that DLT-based identity schemes reshape rather than eliminate centralisation and intermediaries, reflecting identity’s continuing need for trust. The schemes support certified attributes and finer-grained disclosure, but ad-hoc trust, key recovery, and user adoption remain challenges.
- Evaluation: Table 1 records whether each evaluated scheme showed evidence of compliance with each law of identity, with Facebook Connect included for contrast.Unshaded cells indicate evidence suggesting compliance; shaded cells indicate no such evidence was found.
- Decentralisation: DLT-based IdM schemes use decentralisation to different degrees, but mainly reshape central authorities and intermediaries rather than eradicate them.uPort, ShoCard, and Sovrin rely on different centralised or intermediary arrangements.
- Decentralisation: Removing intermediaries is not necessarily realistic in IdM because identity systems retain a profound need for trust.The paper identifies authentication, key recovery, secure namespaces, secure hash-preimage storage, and compromised-identity recovery as possible intermediary functions.
- Decentralisation: The research challenge is balancing centralisation and decentralisation to support interoperable, privacy-respecting IdM without placing too much trust in a single authority.The DAO is cited as an example of risks from pursuing excessive decentralisation; its code flaw enabled theft of $50 million.
- Identity attributes: All evaluated schemes support identity attributes certified by third parties; uPort and Sovrin additionally support self-attestation and attributes assigned by other entities.ShoCard supports third-party certification of identifier attributes.
- Identity attributes: Reusable attributes aim to improve disclosure granularity and reuse, but ShoCard and Sovrin rely on ad-hoc organisational trust through a web of trust.Known challenges include unbounded network size, weak trust quantification beyond first-degree relationships, lost keys, and slow endorsement propagation.
- Adoption: Because identity management is not a primary user goal, changing its technological underpinning without changing end-user interaction may not produce widespread uptake.The paper connects this concern to users’ limited enthusiasm for single-sign-on solutions.
7 Concluding remarks
The evaluation finds that DLT is not a silver-bullet solution for identity management, while highlighting unresolved usability and regulatory challenges. The schemes provide differing support for identifier-sharing models and privacy properties.
- DLT is not a silver-bullet solution for identity management, according to the authors’ application of Cameron’s evaluative framework.The framework offers an early view of the strengths and limitations of applying DLT to IdM.
- User experience remains poorly understood, alongside an assumption that users can manage cryptographic keys and understand DLT-based identity references.The authors identify usability as a particularly pressing unknown.
- GDPR powers for end-users and obligations for data controllers challenge immutable public ledgers that reference personal data.The tension concerns both immutability and transparency in ledgers storing or referencing personal data.
- uPort supports unidirectional identifier sharing but does not prevent entities from broadcasting identifiers out of band.This limitation includes broadcasting identifiers on websites.
- Omnidirectional identifiers are supported, allowing profiles such as Facebook accounts to be public or private and searchable.
Authors
The authors are researchers whose backgrounds span distributed ledger technology, usable authentication, privacy, security, and human-computer interaction.
- Paul Dunphy leads the distributed ledger technology research theme at VASCO Data Security’s Innovation Centre in Cambridge.His background includes research and product work in usable, secure authentication and mobile biometrics.
- Fabien Petitcolas is a research manager at VASCO Data Security and contributes to leading its Innovation Centre.Before joining VASCO, he held research and innovation roles at Microsoft.