pith. sign in

arxiv: 1906.11057 · v1 · pith:PFFSSIYJnew · submitted 2019-06-26 · 💻 cs.CR

Smart Contract Federated Identity Management without Third Party Authentication Services

Peter Mell , Jim Dray , James Shook This is my paper

Pith reviewed 2026-05-25 15:40 UTC · model grok-4.3

classification 💻 cs.CR
keywords federated identitysmart contractsblockchainauthenticationprivacyself-sovereign identityhierarchical identityrelying party
0
0 comments X

The pith

A pre-deployed blockchain smart contract enables federated identity where authentication occurs solely between user and relying party with no third-party contact.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper sets out to show that federated identity management can be achieved by placing identity rules into a smart contract on a blockchain ahead of time. Once deployed, the contract allows a user to prove attributes directly to any relying party without ever contacting a credential service provider, the contract itself, or any other party. This removes per-transaction fees, avoids exposing login activity to intermediaries, and eliminates the need to run public key infrastructure or consult revocation lists. The contract is structured hierarchically so that large organizations can still validate subordinate attribute providers while users keep control over their own credentials. If the approach holds, organizations could offer identity services at scale without the privacy and cost overheads of current federated systems.

Core claim

A smart contract deployed on a blockchain can enforce the necessary identity rules and attribute validation for a hierarchical set of providers. Authentication then proceeds through direct user-to-relying-party messages alone; the credential service provider is never contacted, the smart contract is never queried at runtime, no public key infrastructure is required, and no revocation lists are checked. The hierarchical design preserves the ability of large entities to manage constituent identities while still allowing users a measure of self-sovereignty.

What carries the argument

A pre-deployed hierarchically managed smart contract on a blockchain that encodes identity rules and attribute validation without requiring runtime interaction.

If this is right

  • Users incur no per-authentication fees from credential providers.
  • Login activity remains private to the user and relying party only.
  • Large entities can still validate attributes through a chain of subordinate providers.
  • No ongoing maintenance of public key infrastructure or revocation lists is required.
  • Users retain direct control over which attributes they present.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The design could be tested by deploying the contract on a public blockchain and measuring whether real-world relying parties can complete logins without ever reaching external services.
  • If attribute validation inside the contract proves reliable, the same pattern might apply to other decentralized systems that need verified claims without online authorities.
  • A practical limitation would surface if the chosen blockchain cannot guarantee that the contract code remains immutable after deployment.

Load-bearing premise

That a smart contract placed on a blockchain in advance can correctly enforce all identity rules and attribute validations without any runtime contact or additional trusted parties.

What would settle it

An authentication flow using the proposed system that either requires contacting a credential service provider or the smart contract at runtime, fails to validate attributes from a hierarchical provider, or grants access to an unauthorized user.

Figures

Figures reproduced from arXiv: 1906.11057 by James Shook, Jim Dray, Peter Mell.

Figure 1
Figure 1. Figure 1: IDMS Contract Design Relative to a Single User [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Example User to RP Authentication Function [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: User to RP Attribute Transfer Function Our second core function enables U to send attributes to RP (e.g., personal information necessary to complete some interaction). U obtains a decrypted copy of an attribute descriptor and data (from a local store, from an encrypted version stored in the user’s IDMS record, or from a server whose location is specified in the user’s IDMS record). U sends the descriptor a… view at source ↗
read the original abstract

Federated identity management enables users to access multiple systems using a single login credential. However, to achieve this a complex privacy compromising authentication has to occur between the user, relying party (RP) (e.g., a business), and a credential service provider (CSP) that performs the authentication. In this work, we use a smart contract on a blockchain to enable an architecture where authentication no longer involves the CSP. Authentication is performed solely through user to RP communications (eliminating fees and enhancing privacy). No third party needs to be contacted, not even the smart contract. No public key infrastructure (PKI) needs to be maintained. And no revocation lists need to be checked. In contrast to competing smart contract approaches, ours is hierarchically managed (like a PKI) enabling better validation of attribute providers and making it more useful for large entities to provide identity services for their constituents (e.g., a government) while still enabling users to maintain a level of self-sovereignty.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper proposes a blockchain smart-contract architecture for federated identity management in which a pre-deployed contract handles initial hierarchical setup of identity providers and attributes; subsequent authentications occur solely via direct user-to-RP communication using an offline verification protocol, eliminating runtime contact with the CSP, the contract itself, PKI maintenance, and revocation-list checks while preserving user self-sovereignty.

Significance. If the offline verification and hierarchical enforcement mechanisms can be shown to be secure, the design would remove per-authentication fees and third-party privacy leakage in federated login, while enabling large-scale providers (e.g., governments) to operate attribute hierarchies without the operational overhead of traditional PKI or revocation infrastructure.

major comments (3)
  1. [§4] §4 (Protocol Description): the claim that authentication requires 'no third party contact, not even the smart contract' is load-bearing yet rests on an offline verification step whose cryptographic construction, attribute-binding mechanism, and resistance to replay or forgery are not specified or analyzed.
  2. [§3.3] §3.3 and §5: the assertion that 'no revocation lists need to be checked' and that the hierarchy enforces attribute validation without runtime contact lacks a concrete revocation or validity mechanism (e.g., time-bound credentials, on-chain expiry, or zero-knowledge proofs) that would actually support the claim.
  3. [§5] §2 and §5: no threat model, adversary definition, or security argument is supplied to justify that the pre-deployed contract plus offline protocol simultaneously achieves the stated privacy, self-sovereignty, and hierarchical-validation properties.
minor comments (2)
  1. [Figure 2] The architecture diagram in Figure 2 uses inconsistent notation for the roles of IdP, RP, and user wallet; a legend or clearer labeling would improve readability.
  2. [§2] Related-work discussion omits several recent blockchain identity papers (e.g., on verifiable credentials and DID methods) that address similar offline-verification goals.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the thorough review and constructive comments. The feedback highlights areas where the manuscript would benefit from additional detail and formalization. We address each major comment below and will incorporate revisions to strengthen the presentation of the protocol, mechanisms, and security properties.

read point-by-point responses

  1. Referee: [§4] the claim that authentication requires 'no third party contact, not even the smart contract' is load-bearing yet rests on an offline verification step whose cryptographic construction, attribute-binding mechanism, and resistance to replay or forgery are not specified or analyzed.

    Authors: We agree that Section 4 would be strengthened by a more explicit description of the offline verification protocol. The current text focuses on the high-level architecture and the elimination of runtime CSP contact but does not fully elaborate the underlying cryptographic steps. In the revised manuscript we will expand §4 to specify the cryptographic construction (attribute-bound signatures), the binding mechanism, and a brief analysis of replay and forgery resistance, thereby making the 'no third-party contact' claim self-contained. revision: yes

  2. Referee: [§3.3] the assertion that 'no revocation lists need to be checked' and that the hierarchy enforces attribute validation without runtime contact lacks a concrete revocation or validity mechanism (e.g., time-bound credentials, on-chain expiry, or zero-knowledge proofs) that would actually support the claim.

    Authors: The design intends validity to be enforced once at issuance through the pre-deployed hierarchical contract rather than via runtime revocation lists. However, we acknowledge that an explicit mechanism is required to substantiate the claim. We will revise §§3.3 and 5 to describe how validity is maintained (e.g., time-bound attributes set at setup time or on-chain expiry checks performed only during initial registration), ensuring the absence of runtime list checks is justified. revision: yes

  3. Referee: [§5] no threat model, adversary definition, or security argument is supplied to justify that the pre-deployed contract plus offline protocol simultaneously achieves the stated privacy, self-sovereignty, and hierarchical-validation properties.

    Authors: We concur that an explicit threat model and security argument are necessary to support the claimed properties. The manuscript currently presents the architecture at a conceptual level without a dedicated adversary model. In the revision we will add a subsection (likely in §5) that defines the threat model, adversary capabilities, and provides informal security arguments showing how the combination of the pre-deployed contract and offline protocol achieves privacy, self-sovereignty, and hierarchical validation. revision: yes

Circularity Check

0 steps flagged

Architectural proposal with no derivation chain or fitted inputs

full rationale

The manuscript is a design proposal for a smart-contract-based federated identity architecture. It contains no equations, no parameter fitting, no predictions derived from data, and no self-citation chains that bear the central claim. The strongest claims (authentication via user-RP communication only, no runtime CSP contact) are presented as consequences of the pre-deployed contract design choice rather than reductions of one quantity to another. No load-bearing step reduces to a self-definition or renamed input. This is the normal case for an engineering architecture paper.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The proposal rests on standard assumptions about blockchain immutability and smart-contract execution but introduces a new architectural entity without independent evidence of its security properties.

axioms (1)
  • domain assumption Blockchain provides an immutable, publicly verifiable ledger that can host smart contracts whose code executes as specified.
    Invoked implicitly to support the claim that the smart contract can set identity rules without runtime involvement.
invented entities (1)
  • Hierarchically managed smart-contract identity system no independent evidence
    purpose: To enable attribute provider validation and user self-sovereignty without third-party authentication services during login.
    New architecture proposed in the abstract; no independent evidence or falsifiable prediction supplied.

pith-pipeline@v0.9.0 · 5694 in / 1238 out tokens · 22358 ms · 2026-05-25T15:40:07.639389+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

6 extracted references · 6 canonical work pages

  1. [1]

    SCPKI: a smart contract-based PKI and identity system

    [0RI] 0RIGIN. 0RIGIN Protocol Demo. url: https://demo.originprotocol.com (visited on 02/05/2019). [AlB17] Mustafa Al-Bassam. “SCPKI: a smart contract-based PKI and identity system”. In: Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts. ACM. 2017, pp. 35–40. [ERC] ERC-725 Alliance. ERC-725 Ethereum Identity Standard. ERC-725 Al...

    work page 2019

  2. [2]

    foundation (visited on 04/20/2018)

    url: http://identity. foundation (visited on 04/20/2018). [Gar95] Simson Garfinkel. PGP: pretty good privacy. Ö’Reilly Media, Inc.",

    work page 2018

  3. [3]

    [Sov] Sovrin Foundation

    url: https://whitepaper.%20uport.%20me/uPort%5C_%20whitepaper%5C_ DRAFT20170221.pdf. [Sov] Sovrin Foundation. Sovrin: A Protocol and Token for Self -Sovereign Identity and Decentralized Trust. url: https://sovrin.org/wp-content/uploads/2018/ 03/Sovrin- Protocol-and-Token-White-Paper.pdf (visited on 02/05/2019). [TA18] David Temoshok and Christine Abruzzi....

    work page 2018

  4. [4]

    [uPo18] uPort

    doi: 10.6028/NIST.IR.8149. [uPo18] uPort. uPort Developers . uPort

    work page doi:10.6028/nist.ir.8149

  5. [5]

    [Vog] Fabian Vogelsteller

    url: http://developer.uport.me/ overview.html (visited on 04/20/2018). [Vog] Fabian Vogelsteller. ERC: Claim Holder #

    work page 2018

  6. [6]

    url: https://github

    GitHub. url: https://github. com/ethereum/EIPs/issues/735 (visited on 02/05/2019). [Vog17] FabianVogelsteller.EIP725:ProxyIdentity.EthereumFoundation.Oct.2,2017. url: https://eips.ethereum.org/EIPS/eip-725 (visited on 02/06/2019). [Yag+18] Dylan Yaga et al. NISTIR 8202 Blockchain Technology Overview . Tech. rep. National Institue of Standards and Technology,

    work page 2019