Achieving Flexible and Secure Authentication with Strong Privacy in Decentralized Networks
Abstract: Anonymous credentials (ACs) are a crucial cryptographic tool for privacy-preserving authentication in decentralized networks, allowing holders to prove eligibility without revealing their identity. However, a major limitation of standard ACs is the disclosure of the issuer's identity, which can leak sensitive contextual information about the holder. Issuer-hiding ACs address this by making a credential's origin indistinguishable among a set of approved issuers. Despite this advancement, existing solutions suffer from practical limitations that hinder their deployment in decentralized environments: unflexible credential models that restrict issuer and holder autonomy, flawed revocation mechanisms that compromise security, and weak attribute hiding that fails to meet data minimization principles. This paper introduces a new scheme called IRAC to overcome these challenges. We propose a flexible credential model that employs vector commitments with a padding strategy to unify credentials from heterogeneous issuers, enabling privacy-preserving authentication without enforcing a global static attribute set or verifier-defined policies. Furthermore, we design a secure decentralized revocation mechanism where holders prove non-revocation by demonstrating their credential's hash lies within a gap in the issuer's sorted revocation list, effectively decoupling revocation checks from verifier policies while maintaining issuer anonymity. IRAC also strengthens attribute hiding by utilizing zk-SNARKs and vector commitments, allowing holders to prove statements about their attributes without disclosing the attributes themselves or the credential structure. Security analysis and performance evaluations demonstrate its practical feasibility for decentralized networks, where presenting a credential can be finished in 1s.
Summary
- The paper presents IRAC, a novel issuer-hiding anonymous credential system that uses vector commitments and zk-SNARKs to enable flexible, privacy-preserving authentication in decentralized networks.
- It introduces a decentralized revocation mechanism with sorted hash lists and zero-knowledge non-revocation proofs to protect issuer identity and ensure credential freshness.
- Performance evaluations indicate rapid issuance and verification times with scalable revocation, demonstrating IRAC's potential for practical deployment in evolving identity systems.
Flexible and Secure Anonymous Authentication with Strong Privacy in Decentralized Networks
Introduction
The proliferation of decentralized identity (DID) systems necessitates cryptographic primitives that balance robust security, user privacy, issuer and verifier autonomy, and scalability in issuer- and attribute-diverse environments. Standard anonymous credential (AC) protocols offer eligibility proofs but typically link the credential to the issuer’s identity, introducing correlation risks that violate the privacy guarantees envisioned for decentralized architectures. Prior schemes addressing issuer hiding suffer from stringent uniformity constraints, weak revocation architectures, and suboptimal attribute-hiding, impeding real-world decentralized network deployments.
This paper introduces IRAC: a novel Issuer-hiding and Revocable Anonymous Credential system designed to simultaneously achieve flexible attribute schemas, decentralized and privacy-preserving revocation, and strong zero-knowledge (ZK) attribute proofs. Leveraging vector commitments, zk-SNARKs, and decentralized revocation list architectures, IRAC achieves cryptographic decoupling of issuers and verifiers, user-centric policy construction, and secure, non-interactive selective disclosure.
Limitations of Existing Issuer-Hiding Credential Protocols
Traditional issuer-hiding ACs, notably [bobolz2021issuer], base privacy upon obfuscating the challenge issuer’s public key amongst a set. This foundational idea achieves technical issuer-hiding but enforces homogeneous attribute vectors and verifier-specified policies, substantially constraining issuer flexibility. The lack of policy extensibility and the necessity for global attribute schema synchronization preclude issuer autonomy—a critical limitation in decentralized and multi-authority ecosystems.
Additionally, existing revocation mechanisms expose issuer identity by requiring credential-specific revocation structures as public proof inputs. Attempts to devise privacy-preserving revocation systems (such as non-membership proofs over accumulators) either leak issuer information or fail to provide forward security for non-revocation witnesses, enabling replay attacks and undermining credential freshness. Attribute-hiding is often limited, with standard proofs leaking more data than is required for policy satisfaction, contravening regulatory principles such as GDPR’s data minimization.
IRAC: Architecture and Protocol Design
IRAC’s architectural departure from previous ACs is multi-faceted: it (i) implements an extensible attribute universe with per-issuer selection, (ii) uses vector commitments plus padding to attain a universal credential representation, (iii) decentralizes revocation via sorted hash lists and vector commitments, and (iv) integrates efficient zk-SNARKs for selective and minimal disclosure (Figure 1).
Figure 1: Workflow of IRAC illustrating decentralized issuance, vector commitment-based credential construction, issuer-hiding, decentralized revocation, and zero-knowledge selective disclosure.
Flexible Credential Model
By constructing credentials as fixed-length vectors via padding, IRAC allows heterogeneous issuers to select arbitrary attribute subsets without renegotiating global schemas or predicates. Each issuer maps attribute values to unique index-value pairs and pads to a predetermined length, ensuring all credentials, regardless of issuing authority or underlying schema, have isomorphic commitment structures. The vector commitment scheme, implemented efficiently with zk-friendly primitives, enables succinct and binding commitments suitable for ZK inclusion.
Decentralized Issuer-Hiding Revocation
Conventional revocation approaches tie non-revocation proofs to issuer-specific structures, increasing the risk of correlation and requiring continual witness updating. IRAC’s mechanism has issuers publicize sorted lists of credential hashes representing revoked credentials. Holders retrieve relevant lists, pad them, and commit via vector commitment. Non-revocation is proven, in zero-knowledge, by demonstrating that the credential’s hash lies strictly between two adjacent entries in the sorted, padded commitment, implying non-membership. Critically, since all commitments are padded and proved in aggregated sets, no verifier learns which list corresponds to the credential or the issuer’s identity.
Strong Attribute Privacy via ZK Proofs
IRAC employs zk-SNARKs to enforce selective disclosure. Holders prove in ZK that committed attribute sub-vectors satisfy verifier predicates, without exposing non-requested indices, values, or the vector structure. The SNARK statement is parametrized so that it binds only to committed predicates and issuer sets chosen by the user, not statically pre-defined by the verifier, decoupling authentication workflows from verifier policy specification.
Security and Formal Guarantees
IRAC is formally defined by a suite of algorithms implementing setup, attribute set extension, credential issuance, verification, revocation, and presentation/verification.
Unforgeability
Unforgeability reduces to the existential unforgeability of the signature (EUF-CMA) and the binding property of the vector commitment. The ZK proof integrates checks for valid signatures on commitments and valid proof of non-membership with respect to the decentralized revocation structure. Under the stated assumptions for , , and the ZK proof, adversaries forging credentials or bypassing revocation must break one of these primitives, yielding a negligible success probability.
Unlinkability
IRAC’s use of zero-knowledge proofs for all authentication and non-membership claims ensures that multiple presentations, even for the same credential under the same policy, cannot be linked by any adversary (including colluding verifiers) beyond what is implied by the disclosed predicate.
Performance Evaluation
IRAC implementation utilizes modern zk-SNARKs (Plonk via Halo2), efficient vector commitments (Merkle/Poseidon constructions), and group-friendly signature schemes (ECDSA over Grumpkin with cycle-of-curves optimizations). Key performance findings:
- System setup: For typical proving circuit sizes ( constraints, matching robust asset and policy complexity), setup < 3.5 seconds.
- Issuance/verification: Issuer-side and holder-side workflows dominated by commitment and signature operations; issuance (<2 ms), verification (<4 ms).
- Decentralized revocation: Insertion and sorting scale efficiently (7.2 s for entries), and non-revocation proofs scale logarithmically.
- Credential presentation: Presentation generation cost (for -sized revocation lists, issuer set, predicate constraints) is approximately 0.7 seconds, with verification remaining constant at ~2 ms.
Comparison with the CANS’21 baseline demonstrates considerable efficiency improvements, especially in revocation-heavy policies where IRAC’s decentralized, issuer-hiding design yields presentation generation times two orders of magnitude faster.
Implications and Future Directions
IRAC demonstrates that fully decentralized, issuer-hiding, and selectively disclosive credentials with practical revocation are efficient and ready for deployment in federated and self-sovereign identity architectures. By decoupling policy specification and issuer selection from verification, IRAC is well-suited for environments where attribute schemas and issuers are continually evolving (blockchain identity, federated IoT, metaverse authentication).
Practical implications include the construction of decentralized digital identity wallets and privacy-preserving KYC (know-your-customer) platforms—especially within regulatory environments requiring minimum disclosure and verifiable revocation. In future work, further scaling to multi-level, threshold, or cross-domain revocations, and integration with on-chain verifiability primitives, could bring IRAC-derived systems to trustless environments and smart contract-based ecosystems.
Conclusion
IRAC advances the state-of-the-art in privacy-preserving authentication for decentralized networks by realizing attribute-universal, issuer-hiding, revocable ACs with strong privacy and efficiency. Through an architecture grounded in vector commitments, decentralized issuer management, and ZK attribute proofs, IRAC offers a flexible and practical foundation for next-generation identity and access control systems with stringent privacy and revocation needs.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What this paper is about (simple overview)
Think of a “credential” as a digital badge, like a school ID or a club membership card. You use it online to prove you’re allowed to do something (for example, “I’m over 16” or “I’m a student”) without sharing everything about yourself. This paper builds a new way to use these badges so that:
- you don’t have to reveal which organization gave you the badge,
- you only reveal the minimum information needed (nothing extra),
- and your badge can be safely canceled (revoked) if needed—without breaking your privacy.
The authors call their system IRAC, which stands for Issuer-hiding and Revocable Anonymous Credential.
What questions the paper tries to answer
In simple terms, the paper asks:
- How can people prove things about themselves online without telling who gave them the proof?
- How can this work when different organizations use different kinds of information (different “schemas”)?
- How can we cancel (revoke) a badge if it’s lost or misused, but still keep the issuer hidden?
- How can we make sure you only reveal what’s necessary (like “over 16”) without showing extra personal details (like your full birthday)?
How the new method works (everyday explanation)
To make these ideas easy to picture, imagine three parts: a sealed box with labeled slots, a crowd to hide in, and a “between-two-numbers” trick.
- Sealed box with labeled slots (vector commitments)
- Picture a small, sealed box with numbered slots inside (slot 1, slot 2, etc.). Each slot can hold a card like “age: 17” or “school: Lincoln High.”
- Different organizations use different sets of cards. Some might fill 5 slots, others 12. To make all boxes look the same from the outside, everyone pads empty slots with “blank cards.” Now every sealed box is the same size and shape.
- The box is “committed”: you can’t change what’s inside after sealing. But you can prove a specific slot has a certain card without opening the rest of the box. That’s what a vector commitment does.
- A crowd to hide in (issuer-hiding)
- Normally, showing a badge reveals who gave it to you (your school, city office, etc.). That can leak info about you.
- Instead, you choose a group (a “crowd”) of possible issuers to hide among. You prove your badge is valid for someone in that crowd without saying which one. This keeps your issuer anonymous.
- The “between-two-numbers” trick (revocation without revealing your issuer)
- Organizations keep a list of “canceled” badges. Instead of you showing that list (which could reveal the issuer), you prove your badge’s secret number sits between two neighboring numbers in the issuer’s sorted “canceled” list—meaning it’s not actually on the list.
- Think of a line of numbers in order: 10, 20, 30. If your secret number is 25, it’s between 20 and 30, so it’s not in the list. You prove “25 is between 20 and 30” without revealing 25 or which list it is—only that it fits between those two neighbors.
- The issuer’s list is also sealed in a box (committed) so you can prove those two neighbors are real without exposing the whole list or the issuer.
- Proving without revealing (zk-SNARKs)
- A zk-SNARK is like a tiny, magical receipt that says, “I’ve checked the rules and everything is correct,” without showing your personal info.
- In this system, zk-SNARKs let you prove statements like “the age in slot 3 is at least 16” and “the badge is valid and not canceled” without revealing your exact age, the issuer, or the other slots in your sealed box.
- Flexibility for real life
- Different issuers can choose different attributes (like adding “driver’s license class” or “library membership number”) without forcing everyone to use the same fixed form.
- Verifiers (websites or services) only say what they need (“over 16 and student”). You, the holder, pick which issuers to include in your hiding crowd and generate the proof yourself. No rigid, centralized “policy lists” are needed.
What they found and why it matters
Here are the main results, explained simply:
- Flexible credentials: IRAC lets different organizations use different attributes, but still produce a standard-looking sealed box so your proofs remain private and compatible.
- Strong privacy: You prove what’s needed and nothing else. You hide which issuer gave you the badge. You don’t reveal extra data (like a full birthdate when only “over 16” is needed).
- Secure revocation: If a badge is canceled, you can’t keep using it. The “between-two-numbers” proof checks this without exposing your issuer or the full canceled list.
- Practical speed: The system is fast enough for real use. The paper reports that presenting a credential can be done in about 1 second.
Why this matters: It helps build safer, fairer online identity systems where people control their data, share less, and still get trusted access.
What this could change in the future (impact)
- Better privacy online: Websites can check if you’re allowed in without learning who issued your badge or getting extra details about you.
- Less data collection: This follows the “only share what’s needed” rule from privacy laws and good digital hygiene.
- Works across many groups: Schools, clubs, cities, or companies can each define their own attributes and still work together smoothly.
- Decentralized and user-centered: You choose your hiding crowd and create your proof yourself, reducing control by any single central authority.
In short, IRAC is a step toward an internet where you can prove what you need to prove—securely, privately, and flexibly—without giving away your identity or your personal details.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a concise list of gaps and unresolved questions that future work could address to make IRAC more secure, practical, and deployable in decentralized networks.
- Authenticity and freshness of revocation data: The scheme lets holders retrieve issuer public keys and revocation lists, but it does not specify how verifiers can cryptographically ensure they are the latest, authentic lists (e.g., signed digests, epochs, or ledger anchoring). Without freshness guarantees, holders could use stale revocation data.
- Security of non-membership via “gap” proofs: The proposed proof that a credential’s hash lies between two adjacent elements relies on sorted lists and padded zeros, but edge cases are under-specified:
- Handling of empty lists, multiple identical placeholder values, or duplicate hashes.
- Choice of canonical left/right boundaries (e.g., last zero vs. sentinel values).
- Formal security proof that adjacency implies non-membership under dynamic updates and duplicates.
- Governance and trust for issuer selection: Eliminating verifier-defined presentation policies shifts trust to holders but leaves open how verifiers restrict acceptable issuers (e.g., accreditation lists, governance frameworks). How should verifiers express and enforce issuer trust constraints without undermining issuer-hiding?
- Attribute universe governance and scalability: The paper introduces a global, extensible attribute universe but does not define governance (who can add attributes, conflict resolution, semantics versioning, index assignment) or migration paths when attributes are updated/retired. How are collisions, deprecations, and semantic mismatches handled?
- Fixed maxima vs. “extensible” design tension: Setup requires preset maxima (, , ), yet the system claims extensibility. What happens if real-world needs exceed these bounds? Is re-initialization required, and how is backward compatibility maintained?
- Hiding properties of vector commitments: The scheme defines correctness and binding for vector commitments but not hiding. If commitments (e.g., pairing-based polynomial commitments) are not hiding, do public commitments leak attribute structure or issuer metadata? Clarify whether hiding is required and which VC instantiations meet it.
- SNARK trust assumptions and setup model: The construction uses per-relation key generation (), which may imply trusted setups or per-circuit keys. How is a universal or transparent setup achieved in decentralized deployments? What are the implications for upgradability and auditability?
- Anonymity set quality and quantification: Holder-centric issuer set selection gives flexibility but can yield very small anonymity sets. How should holders choose issuer sets to attain quantifiable issuer-hiding guarantees? Provide metrics or guidance to avoid deanonymization by small or distinctive sets.
- Linkability via public statement components: The public statement appears to include the aggregate commitment over issuers () and the verifier’s predicate. If these are stable across sessions, can they be used to link presentations? What randomization or session-binding mechanisms prevent linkage?
- Side channels from revocation list characteristics: Even if values are used inside a zk-proof, list size, update cadence, or issuer-specific list fingerprints might leak issuer identity. How are these mitigated (e.g., padding strategies, rate-limited updates, uniform list representations)?
- Authentic binding between revocation lists and issuer keys: The design has holders commit to revocation lists; it is unclear if issuers sign the committed digest or otherwise authenticate list-to-key binding. Without issuer-authenticated list commitments, a malicious holder could fabricate favorable lists.
- Handling issuer key rotation and multi-key periods: How does the scheme handle issuer public key rotation (and overlapping periods)? How are credentials, revocation lists, and aggregate commitments updated and verified across key epochs while preserving issuer-hiding and correctness?
- Credential expiry and lifecycle policies: The scheme focuses on revocation but not on expiry or time-bound validity, which can reduce revocation overhead. How are expiry policies expressed and proven privately?
- Attribute updates and re-issuance: Real identities change (e.g., address, name changes). How are credential updates handled without breaking unlinkability or forcing full re-issuance? Are there efficient, privacy-preserving update protocols?
- Network-level privacy during data retrieval: Holders must fetch issuer keys and revocation data; doing so can reveal their intended issuer set to network observers or issuers. Are there protocols to privately obtain these artifacts (e.g., anonymous fetch, broadcast channels, caches)?
- Resistance to malicious or compromised issuers: The threat model assumes trusted issuers. What protections exist against malicious issuers (e.g., embedding identifiers, skewed revocation practices, collusion with verifiers)? Are there accountability or auditing mechanisms compatible with issuer-hiding?
- Practical performance at scale: The evaluation claims ~1s presentation time but does not detail proof sizes, verifier time, memory, bandwidth, and how these scale with large , , and . Provide complexity analyses and empirical results for realistic network sizes (thousands of issuers, large revocation sets).
- Robustness of the hash-based revocation identifier: The scheme hashes credentials for revocation. What are the exact hash requirements (collision/second-preimage resistance, domain separation)? Could collisions or structural similarities enable false non-revocation proofs?
- Interoperability with W3C Verifiable Credentials and DIDs: How does IRAC align with existing standards (VC data model, status lists, DID documents)? What integration points or extensions are needed to deploy IRAC in current decentralized identity ecosystems?
- Formal proofs and end-to-end compositional security: While definitions are given, full formal proofs (issuer-hiding, unlinkability under all system components, non-membership soundness) and composability with external systems (PKI, ledgers) are not presented in the provided text. Complete, modular proofs would aid adoption.
Practical Applications
Below is an application-oriented synthesis of the paper’s contributions. Each item identifies concrete use cases, sectors, likely tools/products/workflows, and assumptions or dependencies that shape feasibility. The list is grouped by deployment horizon.
Immediate Applications
These applications can be piloted or deployed now, leveraging existing zk-SNARK and vector-commitment tooling with modest integration effort (the paper reports ~1s presentation time).
- Privacy-preserving age gating for online services
- Sectors: software, media, gaming, e-commerce, policy
- What it does: Verify “age ≥ 18/21” without revealing full birthdate or the credential issuer (e.g., which municipality or school issued the age attribute).
- Tools/products/workflows:
- Verifier SDK exposing a simple predicate DSL (e.g.,
age >= 18) - Holder wallet app generating the IRAC presentation with attribute indices and SNARK proof
- Issuer SDK for government agencies or schools to issue age attributes and maintain sorted revocation lists
- Assumptions/dependencies: Available issuers for age attributes; public revocation list endpoints; acceptance of issuer-hiding proofs; SNARK library integration in web/mobile; mapping to existing onboarding/compliance flows.
- Student or employment status proofs for discounts and access
- Sectors: education, retail, enterprise IT
- What it does: Prove “is active student” or “is employee with role X” while hiding extra attributes and issuer identity; reduce friction in eligibility checks for benefits or role-based access.
- Tools/products/workflows:
- University/HR Issuer SDK to publish credentials and revocation lists
- IRAC-compatible wallet held by students/employees
- Verifier plugin for point-of-sale or web portals to validate predicates (e.g.,
student_status == active) - Assumptions/dependencies: Issuer onboarding (universities/HR systems); policy mappings from predicates to entitled benefits; revocation publishing cadence.
- GDPR-compliant, minimal-disclosure authentication for web apps
- Sectors: software/web, SaaS
- What it does: Replace identity provider (IdP) over-collection with predicate-based proofs (e.g., “has paid subscription,” “is resident of EU”), aligning with data minimization.
- Tools/products/workflows:
- IRAC-Auth middleware bridging predicates to app authorization rules
- Holder-centric issuer set selection to avoid verifier-maintained presentation policies
- Assumptions/dependencies: Authorization policy translation (from predicates to roles/scopes); developer adoption; legal review for replacing or augmenting OIDC/SAML claims.
- Anonymous residency verification for geo-restricted services
- Sectors: streaming, fintech, online gambling, tax/regulation compliance
- What it does: Prove residency or region eligibility without disclosing the specific issuer (bank, utility, municipality) or unnecessary personal data.
- Tools/products/workflows:
- Issuers (utilities/banks) publish residency attributes
- Verifier SDK implements region predicates; wallet creates IRAC presentations
- Assumptions/dependencies: Regulator acceptance of privacy-preserving residency proofs; issuer participation; revocation list availability.
- Event ticketing and membership access with secure, issuer-hiding revocation
- Sectors: entertainment, sports, clubs
- What it does: Validate membership or ticket validity using the “gap proof” over sorted revocation lists, preventing reuse of revoked tickets while hiding the issuer and list contents.
- Tools/products/workflows:
- Ticket Issuer SDK to hash credentials and maintain sorted revocation lists
- Mobile wallet for holders; verifier app scanning and verifying IRAC proofs at the door
- Assumptions/dependencies: Integration with ticketing systems; reliable public revocation endpoints; offline verification strategy (e.g., cached lists) for low-connectivity venues.
- Enterprise SSO with strict attribute minimization and department/privacy protection
- Sectors: enterprise software/IT
- What it does: Authorize internal application access with predicates (e.g.,
role == DBA AND clearance >= 3) while hiding department or issuer identities that would otherwise leak internal org structure. - Tools/products/workflows:
- IRAC-enabled SSO plugin (reverse proxy or identity middleware)
- Enterprise issuer services (HR, IAM) issuing attributes and revocation lists
- Assumptions/dependencies: Alignment with governance and audit requirements; migration plan from role claims to predicates; performance within enterprise environments.
- IoT gateway onboarding with issuer-hiding device attestations
- Sectors: IoT/edge computing
- What it does: Gateways verify device eligibility (firmware version, certification status) using attribute predicates; revocation of compromised device credentials checked via gap proofs without exposing manufacturer identity.
- Tools/products/workflows:
- Manufacturer Issuer SDK for device credentials and revocation lists
- Gateway verifier module performing IRAC checks on join
- Assumptions/dependencies: SNARK performance on gateways (acceptable); manufacturer participation; standardized attribute indices for device properties.
- Policy and compliance templates for data minimization audits
- Sectors: legal/compliance/GRC
- What it does: Provide reusable predicate templates and audit artifacts demonstrating compliance with GDPR/eIDAS data minimization during authentication.
- Tools/products/workflows:
- Predicate libraries (e.g., “minimal KYC” templates)
- Audit logs capturing predicate checks without personal data exposure
- Assumptions/dependencies: Regulator buy-in; mapping IRAC proofs to audit frameworks; internal controls for issuer list retrieval and caching.
Long-Term Applications
These require broader standardization, scaling, sectoral adoption, or improvements in tooling/UX and hardware acceleration. They build on IRAC’s flexible attribute universe, holder-centric issuer sets, and issuer-hiding revocation.
- National digital ID wallets with cross-border, issuer-hiding authentication
- Sectors: government/eID, travel, public services
- What it does: Citizens use IRAC-backed wallets to prove eligibility to services (eIDAS 2.0, cross-border checks) with minimal disclosure and issuer anonymity among approved sets.
- Tools/products/workflows:
- National wallet integrating IRAC predicates
- Attribute universe registry and governance for standardized indices
- Revocation registry networks (redundant, transparent endpoints)
- Assumptions/dependencies: International standards and legal frameworks; large-scale issuer onboarding; strong UX for issuer-set selection; long-lived SNARK/verifier key management.
- Privacy-preserving KYC/AML for finance and open banking
- Sectors: finance, fintech, DeFi
- What it does: Prove “not sanctioned,” “risk tier ≤ 2,” “resident in permitted region,” without revealing full identity or which institution issued the credential.
- Tools/products/workflows:
- Compliance predicate libraries maintained by consortia
- IRAC-enabled onboarding APIs; revocation registry interop across banks
- Assumptions/dependencies: Regulator acceptance of predicate-based KYC; liability allocation; secure distribution of issuer keys and revocation lists; dispute resolution processes.
- Healthcare interoperability with strong data minimization
- Sectors: healthcare, insurance
- What it does: Prove vaccination status, insurance coverage, specialist referral eligibility—without exposing issuer identity or full records; revoke compromised credentials publicly with gap proofs.
- Tools/products/workflows:
- Health issuer SDKs (providers, insurers)
- Patient wallet controlling predicate-based disclosures
- Assumptions/dependencies: HIPAA/GDPR compliance interpretations; sector-wide attribute standardization; reliable revocation infrastructure; consent and audit tooling.
- Smart mobility and transit passes with multi-issuer, privacy-preserving validation
- Sectors: transportation, smart cities
- What it does: Multi-issuer transit passes (municipalities, transit agencies) validated via IRAC; eligibility predicates like “has valid pass for zone X” or “is senior citizen” without revealing issuer.
- Tools/products/workflows:
- Mobility wallet; validators on turnstiles integrating IRAC verification
- Centralized or federated revocation list aggregation with padding/commitments
- Assumptions/dependencies: Hardware support in validators; high-throughput proof verification; inter-agency coordination.
- Supply chain compliance attestations with supplier anonymity
- Sectors: manufacturing, logistics
- What it does: Verify component compliance (e.g., RoHS, conflict-free minerals) via predicates while hiding the supplier identity; revoke non-compliant lots via public hashed lists.
- Tools/products/workflows:
- Supplier issuer SDKs; procurement verifier apps
- Attribute universe for compliance standards; audit-friendly proof logs
- Assumptions/dependencies: Industry consortia agreements; integration with ERP; scalable revocation publishing; traceability and recall workflows.
- Decentralized social networks and community governance: anti-abuse with minimal disclosure
- Sectors: social platforms, Web3
- What it does: Predicate-based “proof-of-humanity,” age, and community membership checks without linking accounts or exposing issuer; revoke abusive credentials (e.g., bots) via issuer-hiding mechanisms.
- Tools/products/workflows:
- Community issuers; platform verifiers; wallet-based posting gates
- Assumptions/dependencies: Robust anti-sybil predicate design; community governance around revocation; UX to avoid over-constraining anonymity.
- Robotic and autonomous systems authentication
- Sectors: robotics, automotive, industrial IoT
- What it does: Device-to-device capability proofs (e.g., “calibration OK,” “software version ≥ X”) with issuer-hiding and lightweight revocation; useful in swarms or V2X interactions.
- Tools/products/workflows:
- IRAC libraries optimized for embedded platforms; hardware acceleration for SNARKs/vector commitments
- Assumptions/dependencies: Performance on constrained devices; real-time verification; sector standards for attributes.
- Energy and smart grid device compliance
- Sectors: energy, utilities
- What it does: Gate device participation (e.g., distributed generation units) via predicates (grid code compliance, firmware integrity), revoke compromised units with public hashed lists while hiding issuer.
- Tools/products/workflows:
- Utility issuers; substation verifiers; device wallets
- Assumptions/dependencies: High reliability requirements; coordination among operators; secure field updates.
- Lifelong learning and micro-credentials ecosystem
- Sectors: education, HR tech
- What it does: Predicate-based proofs of skills/certifications, issuer-hiding among approved institutions; revoke expired or invalid micro-credentials efficiently.
- Tools/products/workflows:
- Learning issuers; hiring platform verifiers; candidate wallets
- Assumptions/dependencies: Skills taxonomies mapped to attribute indices; platform adoption; standard revocation processes.
- Public revocation registry networks and credential transparency
- Sectors: cross-sector infrastructure
- What it does: Federated, audited publication of issuer revocation lists as sorted hash sets; commitment-based aggregation and caching to support holder-side aggregation and issuer-hiding proofs.
- Tools/products/workflows:
- Revocation aggregator services; registry APIs; monitoring/audit dashboards
- Assumptions/dependencies: Governance and funding; anti-censorship and availability guarantees; standardized padding and indexation.
Cross-cutting toolchain opportunities (spanning immediate and long-term)
- IRAC-compatible wallet for holders (mobile and desktop), with:
- Predicate builder UI; issuer-set selection
- SNARK proof generation and vector-commitment openings
- Secure key storage and presentation session management
- Issuer SDK
- Attribute universe integration (index registry management)
- Credential commitment/signing, hash computation
- Sorted revocation list maintenance and publishing endpoints
- Verifier SDK/middleware
- Predicate DSL and policy mapping to app roles/scopes
- Proof verification pipeline, caching of issuer keys and revocation commitments
- Audit-friendly logging without personal data leakage
- Attribute Universe Registry and Governance
- Open catalog of standardized attribute indices and semantics
- Processes to extend the universe without re-initializing the system
- Revocation Registry Services
- High-availability, append-only publication of sorted hashed revocation lists
- Commitment APIs enabling holder-side aggregation and issuer-hiding checks
Key assumptions and dependencies across applications
- Cryptographic stacks: Robust, production-ready zk-SNARK implementations (e.g., Groth16, PLONK) and vector commitment libraries; consideration of trusted/universal setups and verifier key distribution.
- Issuer ecosystem: Willingness of diverse issuers (government, universities, banks, manufacturers) to issue credentials and maintain public, sorted revocation lists.
- Attribute standardization: An attribute universe with stable indices and semantics to ensure interoperability across issuers and verifiers.
- Performance and UX: ~1s presentation time is acceptable in many contexts; mobile and gateway devices may need hardware acceleration or proof optimizations for real-time flows.
- Legal/regulatory: Acceptance of predicate-based, issuer-hiding authentication as compliant with GDPR/eIDAS/HIPAA/KYC/AML; audit processes that rely on minimal logs.
- Operational reliability: Secure retrieval/caching of issuer keys and revocation lists; strategies for offline verification; governance over registry availability and integrity.
- Privacy-by-design: Careful predicate design to avoid re-identification via quasi-identifiers; guardrails against verifier overfitting predicates that reduce anonymity.
Glossary
- Anonymous credentials (ACs): Cryptographic credentials enabling users to prove properties without revealing identity. "Anonymous credentials (ACs) are a crucial cryptographic tool for privacy-preserving authentication in decentralized networks, allowing holders to prove eligibility without revealing their identity."
- Attribute universe: A global, extensible registry of possible attributes that issuers can choose from. "IRAC introduces an extensible attribute universe ."
- Binding: A security property ensuring a commitment (or proof) cannot be opened to two different values for the same position. "The vector commitment scheme must satisfy correctness and binding."
- Data minimisation principle: Legal and privacy guideline requiring disclosure of only the minimal necessary data. "fails to meet the stringent requirements of attribute hiding and the data minimisation principle specified by laws such as GDPR."
- EUF-CMA: Existential Unforgeability under Chosen Message Attacks; a signature security standard preventing forged signatures even with oracle access. "A secure digital signature scheme must be existentially unforgeable under chosen message attacks (EUF-CMA), even when the adversary is allowed to query a signing oracle on messages of its choice."
- Fiat-Shamir heuristic: Technique turning interactive proofs into non-interactive ones via hashing the transcript. "used in Fiat-Shamir heuristic~\cite{10.1007/3-540-47721-7_12}"
- Issuer-hiding ACs: Anonymous credentials where the issuer’s identity is hidden among an approved set. "Issuer-hiding ACs address this by making a credential's origin indistinguishable among a set of approved issuers."
- Issuer-hiding attribute-based credentials: Credentials that hide which issuer issued them while supporting attribute-based proofs. "issuer-hiding attribute-based credentials, as formally introduced by Bobolz et al.~\cite{bobolz2021issuer}."
- Knowledge soundness: Property ensuring that any prover who convinces the verifier must possess a valid witness. "A zk-SNARK scheme satisfies knowledge soundness if for all PPT adversaries , there exists a PPT extractor such that:"
- Non-revocation witness: Evidence proving a credential has not been revoked; vulnerable if it remains valid after revocation. "non-revocation witnesses retain validity even if the credential is revoked afterwards"
- NP relation: A relation for which membership proofs have polynomially verifiable witnesses. "For a non-deterministic polynomial time (NP) relation , we write "
- Predicate: A verification condition over attributes that determines access eligibility. "satisfy an access criterion specified by a predicate "
- Presentation policy: Verifier-defined signed policy specifying acceptable issuers and conditions for a presentation. "The verifier defines a presentation policy in three steps:"
- Probabilistic polynomial time (PPT): Computational model for efficient randomized algorithms in cryptography. "PPT stands for 'probabilistic polynomial time'."
- Quasi-identifiers: Attribute combinations that can re-identify individuals when combined, even if individually non-unique. "they can act as quasi-identifiers."
- Revocation handler: Unique identifier tied to a credential used in revocation checking. "where is a unique revocation handler"
- Revocation list: Public list of revoked credential identifiers maintained by the issuer. "prove that the presented credential is not on the issuer's revocation list"
- Succinctness: Property where proofs are very short relative to witness size. "A zk-SNARK scheme is succinct if the size of the proof is polylogarithmic in the size of the witness ."
- Unforgeability: Security guarantee that adversaries cannot produce valid tokens or presentations without legitimate credentials. "Unforgeability: This property guarantees that no malicious holder (i.e., adversary ) can produce a valid presentation token"
- Unlinkability: Privacy property preventing a verifier from linking multiple presentations to the same credential/holder. "Unlinkability: This property ensures that even a malicious verifier (i.e., adversary ) cannot link two presentations generated from the same holder"
- Vector commitment: Cryptographic primitive to commit to a vector and later prove openings of specific positions. "we employ a vector commitment scheme where issuers pad their assigned attribute values to a fixed-length vector using placeholders."
- Zero-knowledge: Property ensuring proofs reveal no information beyond the truth of the statement. "A zk-SNARK scheme must satisfy the properties of completeness, knowledge soundness, zero-knowledge, and succinctness."
- zk-SNARK: Zero-knowledge Succinct Non-interactive Argument of Knowledge; a proof system with short, non-interactive proofs. "A zk-SNARK enables a prover to convince a verifier that it possesses certain information (i.e., a witness) without revealing any information about it"
Collections
Sign up for free to add this paper to one or more collections.
