Skip to content

certified-identity.md

Latest commit

 

History

History
70 lines (45 loc) · 4.75 KB

certified-identity.md

File metadata and controls

70 lines (45 loc) · 4.75 KB
title Certified Identity
description How identity works in the Hypercerts ecosystem — DIDs, signing, portability, and wallet linkage.

Certified Identity

Every hypercert record has an author. Every evaluation carries a signature. Every funding receipt traces back to a DID. Identity is a core primitive of the protocol — it determines who owns records, who can be trusted, and who receives funding.

Identity in the Hypercerts Protocol

The Hypercerts Protocol uses AT Protocol's identity system. Every participant — whether an individual contributor, an evaluator, or an organization — is identified by a DID (Decentralized Identifier).

A DID like did:plc:z72i7hdynmk6r22z27h6tvur is:

  • Permanent — it never changes, even if you switch servers or handles
  • Portable — your records, reputation, and history follow your DID across platforms
  • Cryptographically verifiable — every record you create is signed by your DID's key pair, and anyone can verify the signature

Your DID resolves via the PLC directory to a DID document containing your current PDS, public signing keys, and handle.

How identity connects to the protocol

Layer How identity is used
Data Every record (activity claims, evaluations, measurements) carries the author's DID. The PDS signs records into a Merkle tree, making authorship tamper-evident.
Trust Evaluators build reputation tied to their DID. Applications can weight evaluations based on the evaluator's history and credentials.
Funding Funding receipts link funder DIDs to the work they support. Wallet linkage (work-in-progress) connects DIDs to on-chain addresses for payment flows and tokenization.
Portability Switching PDS providers doesn't change your DID. Your entire history — claims, evaluations, contributions — migrates with you.

Certified: the reference identity provider

Certified is the identity provider built for the Hypercerts ecosystem. It provisions the full identity stack in a single sign-up:

  • A DID — your permanent identifier
  • A PDS — your Personal Data Server, where records are stored
  • Low-friction sign-in — email and code, no passwords or protocol knowledge required

Certified exists because most Hypercerts users are not Bluesky users. Researchers, land stewards, open-source maintainers, and funders need an entry point that doesn't require knowledge of ATProto or decentralized protocols. Certified provides that — a neutral identity provider that isn't tied to any single application.

Handles (your public username)

Handles are not needed to log in to the Hypercerts ecosystem, but every user has one. They serve as human-readable names for publicly addressing others and for interacting with other applications in the AT Protocol ecosystem that haven't implemented email-based login with Certified. Your handle (e.g., alice.certified.app) is human-readable but not permanent — it's a pointer to your DID. Organizations can use custom domain handles (e.g., numpy.org) to prove organizational identity through DNS verification.

For setup details, see Account & Identity Setup.

Compatible with Bluesky and other AT Protocol accounts

{% callout type="note" %} Hypercerts is fully interoperable with the AT Protocol ecosystem. If you already have a Bluesky account or any other ATProto identity, you can log in with your existing handle (e.g., alice.bsky.social) and use all Hypercerts applications — no additional account needed. {% /callout %}

Wallet linkage

To receive on-chain funding, a DID needs to be linked to an on-chain wallet address. This is handled by IdentityLink — a cryptographic attestation system that binds a DID to one or more on-chain addresses via a signed proof stored in your PDS. For the Ethereum ecosystem this looks like:

  1. Authenticates the user via ATProto OAuth
  2. Connects an EVM wallet (EOA, Smart Wallet, or Safe)
  3. Signs an EIP-712 typed message proving ownership
  4. Stores the attestation in the user's PDS

The attestation is self-sovereign (stored in your PDS, not a central database) and verifiable by anyone. See the Roadmap for current IdentityLink status.

Next steps

Next: Why AT Protocol? — how identity and records stay portable across apps.