Sign in Subscribe
ic

Encode: Concordium 101 Identity

Community Blog

— 14 min read
Encode: Concordium 101 Identity

In this Encode "Educate" webinar, Dragos Danciulescu and cryptographer Daniel Tschudi walk through Concordium's on-chain identity layer from both ends: the practical mechanics of how it works, and the cryptographic science that makes it trustworthy.

The session is structured as a two-part deep dive. Dragos covers the system as a user and builder would encounter it: the four participants (users, identity providers, privacy guardians, authorities), the separation of powers that prevents any single party from linking identity to accounts, the four zero-knowledge proof types, and the multi-party disclosure process that only a court order can trigger. Daniel then takes it to the protocol level: why self-sovereign identity matters, how verifiable presentations solve the credential-forwarding problem, and why Concordium chose Sigma protocols and Bulletproofs over more complex proof systems like Groth16.

What makes this session worth the time is the combination. Most identity explainers stop at the "what." This one gets into the "why it holds." Daniel's walkthrough of how a fresh holder ID prevents cross-session linkability, or why range proofs and set membership cover virtually all real-world verification needs without resorting to general-purpose circuits, is the kind of detail that separates architecture from marketing.

1: Session overview and format

  • Second webinar in the Concordium "Educate" / Concord and Code series
    • Focused entirely on the on-chain identity layer
  • Two speakers
    • Dragos Danciulescu: first half, practical overview
    • Daniel Tschudi: second half, cryptographic science
  • Part 1 topics (Dragos Danciulescu)
    • The identity problem on public blockchains
    • Concordium's approach to privacy and accountability
    • Key participants and separation of powers
    • How to get a Concordium ID and create an account
    • Identity disclosure process with two legal scenarios
    • Introduction to Web3 ID
  • Part 2 topics (Daniel Tschudi)
    • Self-sovereign identity
    • Verifiable presentations
    • Zero-knowledge proofs
    • Sigma protocols and Bulletproofs

2: The Problem with Identity on Public Blockchains & Concordium's Approach

  • The identity problem on public blockchains today sits at two extremes
    • Fully anonymous chains (Monero, Zcash): privacy exists, but so does impunity for bad actors. Regulatory dead end.
    • Pseudonymous but trackable chains (Bitcoin, Ethereum): transactions can be traced, but there is no systematic way to discover the real identity behind them. Worst of both worlds for many use cases: you are neither fully private nor accountable.
    • Neither model works for serious business adoption or regulatory compliance.
  • Concordium's design principle: privacy by default, accountability when legally required
    • Every account is linked to a verified real-world identity, but personal information never exists on chain, encrypted or otherwise.
    • No single party can connect an identity to an account.
    • Only a multi-jurisdictional legal process involving court orders can break the link.
    • This is enforced by cryptography (math built into the protocol), not by policy.
    • The identity layer's security has been proven in peer-reviewed research.
  • Concordium ID is a protocol-level identity system
    • It is mandatory, not optional, and not a third-party add-on. You cannot hold an account without a verified identity.
    • Enables confidential transactions and zero-knowledge proofs of identity attributes.
    • Supports both individuals and businesses.

Inner Circle Comment
The presentation frames Concordium as "privacy by default," and Dragos emphasizes repeatedly that personal information never exists on chain, that no single party can link identity to accounts, and that all of this is guaranteed by cryptography. That framing is accurate for what it covers, but the way it is coupled relative to other privacy chains leaves the impression that Concordium already delivers full end-to-end transactional privacy. It does not.

What Concordium offers today is what I would call Level 1 privacy: identity privacy. Your real-world identity is protected by the separation of powers between identity providers, privacy guardians (formerly called revokers), and the chain's cryptography itself.

That is genuinely strong and well-designed. But transaction flows, amounts, balances, along with counterparty relationships still remain visible on chain at this stage.

Level 2 (amount and balance privacy) is confirmed to be on the near-term roadmap. Level 3 (full transactional privacy, where the entire payment flow is shielded end to end) is the longer-term goal as also recently communicated by Concordium and as strongly advocated for by me.

3: Key Participants & Separation of Powers

  • Four key participants in the identity system
    • Users
      • Individuals or businesses
      • The actual identity and account holders
    • Identity Providers (IDPs)
      • Perform off-chain identity verification
      • Issue identity credentials based on that verification
    • Privacy Guardians
      • Hold the cryptographic keys required for the disclosure process
      • Typically legal firms, currently based in Switzerland
      • Each approved by the Concordium Foundation
      • Threshold requirement: two out of three must participate for decryption to proceed
    • The Authority
      • Any entity (e.g. law enforcement) that has obtained a court order
      • Initiates the disclosure process
      • The only party that can ultimately reconstruct the full link between identity and accounts
  • Separation of powers: what each party knows and does not know
    • Identity Provider
      • Knows: real-world identity, documents, records
      • Does not know: wallet address, accounts, any on-chain activity
      • Never learns which account a user creates
    • Privacy Guardian
      • Knows: an individual share of a decryption key (useless alone)
      • Does not know: names, documents, identity records, any personal data
    • Concordium
      • Provides: the protocol, chain, and infrastructure
      • Holds: zero personally identifiable information
    • Authority
      • Only learns what the full legal process unlocks
  • No single party can link an identity to an account
    • There is no direct communication between identity providers and privacy guardians
    • The authority always sits in the middle
    • No agency can request account ownership without an actual court order

Inner Circle Comment
Note how the presentation uses the term "privacy guardians" throughout. Previously Concordium always referred to this specific role or function as "anonymity revokers."

This is a smart rebranding. "Anonymity revoker" frames the function negatively as someone who takes your privacy away. The term "Privacy guardian", on the other hand, frames it positively as someone who protects your privacy.

The shift matters because it changes how the system is perceived and I believe it signals Concordium's growing dedication to increasing levels of privacy (from level 1 to 2 and hopefully ultimately 3).

4: Getting a Concordium ID & From Identity to Accounts

  • How to get a Concordium ID
    • Download the Concordium wallet
      • Available on mobile and web
    • Start identity creation by selecting an identity provider
    • Mainnet process
      • Scan a valid passport or ID card
      • Complete a liveness check (selfie video to prove you are the person behind the document)
      • Alternative for Denmark and Finland: use your eID directly, skipping most steps
    • Testnet process
      • Much simpler: you receive a mock identity
    • Business onboarding
      • Similar flow, but requires additional documentation
      • Registration number, registered address, director details, etc.
    • Once the IDP verifies document validity, the credential is stored in your wallet and the IDP's database
      • Nothing goes on chain
  • Current mainnet identity providers
    • Digital Trust Solutions: general-purpose, high-assurance identity verification for production use cases
    • Notabene: specializes in crypto-specific regulatory requirements (particularly the Travel Rule)
    • Global FinReg: focuses on financial regulatory compliance and institutional standards
    • If none of these meet your requirements, contact Concordium directly to discuss onboarding additional providers
  • From identity to accounts
    • Once you hold an identity credential, you can create one or more accounts on chain
    • Every account creation is a transaction secured with zero-knowledge proofs
      • The chain verifies credential validity without accessing any personal information
    • Up to 26 accounts per identity credential
    • A single wallet can hold multiple identity credentials from different providers
      • So the total account capacity per wallet exceeds 26
    • An encrypted holder identifier links credential to account
      • Decrypting it requires court orders and multiple privacy guardians
  • Where the identity credential lives
    • Stored only locally on the user's device and in the IDP's database
    • The IDP holds the credential but has no knowledge of which account the user created
    • Best practice: avoid revealing attributes unless strictly necessary
      • Example: to verify age, use a range proof ("between 18 and 99") rather than revealing your actual birthdate

Inner Circle Comment
I somehow thought the maximum number of accounts one identity credential could create was 10. It is actually 26 per credential, and a single wallet can hold multiple credentials, so the total capacity is considerably higher than I had assumed.

Interesting to hear how Concordium segments and distinguishes the three identity providers. DTS handles general-purpose, high-assurance verification for production use cases. Notabene specializes in crypto-specific regulatory requirements, particularly the Travel Rule (as we recently discussed after the xxxx). Global FinReg is not elaborated on much in the presentation, but its focus is entity onboarding, supporting particularly LEI number registration and validation.

5: Four Proof Types & the Identity Disclosure Process

  • Four zero-knowledge proof types available on Concordium
    • Core principle: prove what you need to prove while revealing as little data as possible
    • All proofs are generated locally in the wallet
      • The verifier only sees the proof itself and returns yes or no
      • Verifier software is available on Concordium's GitHub
    • Reveal attribute proofs
      • Shares the actual value of a specific attribute
      • Example: "My country of residence is Denmark" or "My name is Dragos"
    • Range proofs
      • Proves a value falls within a given range
      • Example: "I am between 18 and 65" — the merchant knows you are an adult, but your actual birthdate stays hidden
    • Set membership proofs
      • Proves a value belongs to a defined set
      • Example: "I am an EU citizen" without revealing which specific country
    • Set non-membership proofs
      • Proves a value is not in a defined set
      • Example: "I am not from a sanctioned country"
    • Underlying cryptography (covered in detail in Part 2)
      • Sigma protocols + Fiat-Shamir transform: equality, inequality, set membership, set non-membership
      • Bulletproofs: range proofs
  • Identity disclosure process: two scenarios
    • Preconditions for both
      • Valid court orders required
      • No single party can act alone
      • The authority coordinates the entire process from the middle
    • Scenario 1: "Who owns this on-chain address?"
      • Authority retrieves an encrypted identifier from the chain (useless by itself)
      • Privacy guardians collaborate (two out of three threshold) to decrypt it
      • Authority reconstructs the decrypted identifier
      • Identity provider matches the identifier to a real-world identity and returns it
    • Scenario 2: "What accounts does this person have?"
      • Authority sends the person's data to all IDPs
      • IDPs return records with encrypted linking keys
      • Privacy guardians decrypt the linking keys
      • Authority retrieves all accounts linked to that identity
    • Net result: bad actors doing something illegal on chain can be identified, but only through this multi-party legal process

Inner Circle Comment
As already noted in Section 3, the shift from "anonymity revoker" to "privacy guardian" is honestly very clever rebranding rhetoric. "Guardian" positions these entities as protectors of privacy rather than as a threat to privacy.

It's less clear whether the underlying procedure has also changed, or only the language. Concordium's earlier public-facing descriptions often made it sound like a single anonymity revoker, working alongside the identity provider, could unlock a user's identity.

The Encode presentation defines a 2-of-3 threshold very specifically. It's clear that the protocol itself has always been framed as supporting configurable M-of-N thresholds at identity issuance, and the developer tooling also confirms this flexibility. So the threshold flexibility is original to the foundational design.

Whether Concordium has tightened the practical configuration (moving from what may have been a lower threshold as essentially "1-of-1" in earlier deployments to a stricter 2-of-3 setup), or whether the 2-of-3 was always the mainnet reality and simply communicated poorly, is unclear to me.

6: Web3 ID

  • Web3 ID extends Concordium ID
    • Concordium ID is the foundational layer, required for every account on chain
    • Web3 ID builds on top of it for a much wider range of verifiable claims
      • Uses the W3C Verifiable Credential standard
    • Anyone with a Concordium account can become an issuer
    • Issuers manage credential lifecycle via smart contract
      • Expiration and revocation
    • Zero-knowledge proofs work identically to Concordium ID proofs
      • You can mix both Concordium ID and Web3 ID claims in a single proof request
    • Developer tooling available
      • Template smart contracts and an issuer tool
  • Practical example: academic credentials
    • A university could issue diploma credentials on chain
    • A graduate could then prove they attended that university via a ZK proof
      • Without revealing the diploma itself
    • Whether the user needs to be identified by the issuer is entirely up to the issuer
      • Done through smart contracts, separate from the Concordium ID disclosure process
  • Key difference from Concordium ID
    • Web3 ID credentials are not part of the identity disclosure process
    • No restrictions on who can issue them
    • Trust depends on the issuer, not the protocol
  • Q&A note: privacy vs. merchant data requirements
    • Daniel Tschudi (cryptographer, not a lawyer) addressed a question about jurisdictions where merchants need user information while privacy is also required
    • His view: this is a self-sovereign identity system, so it is a legal question between the user and the merchant
      • Whether the merchant can ask for and accept a ZK proof
      • Whether the user is allowed to give that proof
    • The chain itself has no say in that matter

Inner Circle Comment
Interesting to hear the clear description and separation of Web3 ID relative to the base layer Concordium ID. While this distinction is absolutely clear to me, I doubt that many stakeholders actually fully understand the difference, and I have not heard anyone from Concordium articulate it so clearly before.

It is also very comforting to hear Concordium reference both continued commitment to W3C along with awareness and what sounds like diligent monitoring of the evolving EUDI wallet standard.

7: Self-Sovereign Identity & the Privacy Problem with Traditional Verification

  • The privacy problem with traditional identity verification
    • Simple example: buying alcohol in a store
      • You show your full ID card, and the shopkeeper learns everything about you
      • All that is actually relevant is your age
      • Even your exact birthdate is more information than they need
    • eID systems (e.g. Nordic countries) partially solve this for online use
      • But each use pings a government server to sign a message
      • The government learns where and when you use your ID
      • Fine for voting, problematic for other contexts
  • Self-sovereign identity: the design goal
    • A well-established concept, not invented by Concordium
    • Three actors
      • Issuer: issues a credential after performing checks (e.g. identity provider, university)
      • Holder: the user, stores the credential in a wallet, has full control
      • Verifier: a merchant or service that needs to confirm something about the user
    • The user is empowered
      • The issuer never learns how, where, or when you use your credential
      • The verifier only needs the issuer's public key (available on chain) to verify
  • How identity issuance differs from traditional onboarding
    • The process itself is familiar (photo of ID, liveness check, similar to opening an online bank)
    • Key difference: the credential goes to the user's wallet, not to the service provider
      • Only between you and the identity provider at that point
    • Credential is valid for five years
  • The trust question for Web3 ID vs. Concordium ID
    • In the Web3 ID system, anyone can be an issuer
      • The verifier must decide which issuers they trust
    • In the core Concordium ID system, the Foundation has preselected a fixed set of identity providers
      • Makes the trust decision easier for verifiers

8: From Credentials to Verifiable Presentations

  • Why sending the full credential to a verifier is problematic
    • The verifier checks the digital signature on the credential
      • This works, but the verifier now sees all attributes
    • They also hold a copy of the credential
      • They could present it to someone else, who would also accept it as valid
    • This resembles the old-school problem of handing your physical ID card to the shopkeeper
  • Verifiable presentations solve this
    • A well-known concept in the identity space
    • Instead of showing the full credential, the user builds a derived credential
      • Contains only the specific claims you want to make
      • Example: "I am older than 18, so give me the beer"
  • New problem this introduces
    • The derived credential was not signed by the issuer
    • Signature verification no longer works directly
    • Partial reveals (signing each attribute individually) are possible but clunky
    • This is where zero-knowledge proofs come in (covered in next section)

9: Zero Knowledge Proofs — Concepts & Properties

  • Zero-knowledge proofs are not new
    • Known in cryptography for decades
    • The concept: prove you know something without revealing the thing itself
  • The Sudoku analogy (Alice and the Rabbit)
    • Alice claims she knows the solution to a hard Sudoku
    • She could simply send the solution, and Rabbit could verify it
      • But then Rabbit has the solution and can claim it as their own
    • Instead, Alice uses a zero-knowledge proof
      • Rabbit challenges Alice, Alice responds in a way that convinces Rabbit
      • Rabbit learns only that Alice knows the solution, nothing more
    • Same principle applies to blockchain accounts
      • You can prove you own an account (know the secret key) without revealing the key itself
  • Interactive vs. non-interactive proofs
    • Traditional ZKPs are interactive: a back-and-forth discussion between prover and verifier
      • Requires both parties to be online at the same time
    • Modern ZKPs are non-interactive (via Fiat-Shamir transform)
      • The discussion is compressed into a single one-shot message
      • Alice sends one message, Rabbit verifies it, done
  • Three required properties of a ZK proof system
    • Completeness
      • If Alice truly has the knowledge, she should always be able to convince Rabbit
    • Soundness
      • If Alice does not have the knowledge, she should fail to convince Rabbit
      • A partial Sudoku solution should not pass
    • Zero knowledge
      • Rabbit learns only the stated fact ("Alice knows the solution" or "Alice is older than 18")
      • No additional information leaks: no hints, no partial values, nothing
  • Applying ZKPs to verifiable presentations
    • A standard verifiable credential contains
      • Metadata
      • All attributes (name, birthdate, country, etc.)
      • A holder identifier (typically a public key)
      • An issuer signature
    • A verifiable presentation replaces this with
      • Metadata
      • Only the derived attributes (e.g. "I am older than 18")
      • A fresh holder ID (so the verifier cannot tell if you are a repeat visitor)
      • A ZK proof instead of the issuer signature
    • The three properties map directly onto this
      • Soundness: if your credential genuinely says you are over 18, the proof convinces the verifier
      • Soundness (flip side): if you are underage, you cannot generate a valid presentation claiming otherwise
      • Zero knowledge: the verifier learns only the derived claim, nothing else (no birthdate, no name)
    • Result: fine-grained control for the user over what to reveal and when

10: ZK Proof Mechanics — Direct vs. Indirect, Sigma Protocols & Bulletproofs

  • Two modes of ZK proof on Concordium
    • Direct proof (from the credential)
      • You prove: "I know a signature from the issuer on my attributes, and those attributes satisfy the following predicate"
      • Offers ultimate privacy: reveals nothing about you beyond the claim
    • Indirect proof (from on-chain commitments)
      • When you open an account, you add commitments to your attributes on chain
      • Commitments work like sealed envelopes: the value is inside, but nobody can look into it
      • A ZK proof then points at the envelope and makes a statement about the value inside
      • Example: "My identity attributes linked to this account confirm I am an EU resident"
      • Primarily useful when you are already using the account for a transaction (e.g. a payment)
  • Why Concordium chose simplicity over general-purpose proof systems
    • Systems like Groth16 allow proving arbitrary statements
      • But generating those proofs on a mobile device becomes complicated
    • Concordium aimed for simplicity
      • The real-world statement types needed are straightforward: reveal, inequality, range, set membership/non-membership
      • Exotic statements ("the second bit of my last name matches the first bit of my birthdate") are theoretically possible but virtually never needed in practice
    • Simplicity brings concrete advantages
      • Easier to implement
      • Smaller attack surface for bugs
      • Built on protocols proven and tested for over 20 years
  • The two protocol families used
    • Sigma protocols
      • Used for revealing attributes and equality/inequality proofs
      • Example: revealing a family name
      • Known for over 20 years, well trusted
    • Bulletproofs
      • Originally built for range proofs (e.g. proving you are older than 18)
      • Concordium extended the concept using an inner product proof property
      • Also used for set membership proofs (e.g. "I am from Country A or Country B" without specifying which)
      • And set non-membership proofs (e.g. "I am not from any country on this sanctions blacklist")
    • Set non-membership works for any attribute
      • Not limited to nationality
      • Example: "My family name is not one of these"
  • Resources for further exploration
    • Developer docs and identity process documentation
    • Proof explorer: create a testnet ID and experiment with all the ZK proof types hands-on

11: Q&A

  • Q&A
    • Threshold ID creation and derived keys
      • The threshold ID is a random identifier generated on the fly
      • It is ephemeral: used only during the exchange and never after
      • Concordium docs contain a deep-dive article on this
    • Alignment with standards
      • The identity solution follows W3C standards for self-sovereign identity
      • EUDI wallet standard is still in progress
      • Future work will ensure compatibility once EU wallet specifications are finalized across countries
    • Testnet vs. mainnet wallet confusion
      • A user was prompted to upload an ID before even setting up a test account
      • Cause: they had selected mainnet in the top-right of the web wallet
      • Fix: switch to testnet, then select the test identity provider to skip real ID submission
    • DIDs vs. Concordium ID
      • DIDs (Decentralized Identifiers) are used within the system
      • Concordium has its own DID prefix: did:ccd
      • Points at accounts, smart contracts, and public keys
      • Concordium ID is a verifiable credential system built along W3C lines, on top of DIDs
      • DIDs are used to identify verifiers, holders, and issuers
  • Next session preview
    • Same time next week (Tuesday, 4:00 PM UK time)
    • Topic: Verifying Access
      • Exploring Concordium's identity layer in real-world verify-and-access scenarios
      • Featuring practical partner use cases

Read more