Holochain membrane proofs

What a membrane enforces, and what it does not

So the claims are chosen to need little revocation: bound to one key, slow to change, or cheap to re-epoch.

Two ways to use it

hApp Auth proves facts; the network’s operator holds the policy. You never register a network with us. One attestation serves either consumer:

The flow you ship

1. Install with allow_deferred_memproofs; the conductor creates the agent key.
2. The UI, with @happauth/holochain, sends the person to hApp Auth with a memproof-request signed by that key and naming the DNA hash.
3. The person signs in with a passkey and sees: “{network name} asks to confirm: GitHub account older than 1 year.” They press Continue; hApp Auth checks the evidence and returns the membrane proof.
4. The UI calls provideMemproofs, then enableApp.

If the claim is not true, the person is told exactly why (“Your GitHub account is 4 months old; this network admits accounts older than 1 year”), no attestation is issued and nothing is recorded against them. With a joining server, the UI talks to the Joining Service as it already does and the service returns its own proof.

The format: hApp Attestation v1

Fixed canonical bytes, signed raw with Ed25519 and verified with verify_signature_raw (never verify_signature, which msgpacks first and ties outside verifiers to the HDK’s serializer).

1delegation     = root_sig( "happ-att/v1/delegation\0" || online_key(32)
2                           || not_before(u64) || not_after(u64) || key_id(8) )
3attestation    = online_sig( "happ-att/v1/claim\0" || dna_hash(32)
4                             || subject_agent_key(32) || claim_type(u16)
5                             || claim_len(u16) || claim_value
6                             || issued_at(u64) || expires_at(u64)
7                             || attestation_id(16) )
8membrane_proof = version(u8) || delegation || attestation

The format is an open specification and hApp Auth is its first issuer, not its only one: a DNA pins a set of issuer roots, and any organisation can run an issuer. The verifier crate, happ_attestation_verify, depends only on hdi. Called from genesis_self_check (fail early) and from validate on the AgentValidationPkg (the rule peers enforce), it checks that the root is in the properties, the delegation and attestation signatures hold, the dna_hash is this DNA, the subject is the joining agent, and the claim is accepted.

DNA properties

1# dna.yaml — the network's admission policy lives in its properties
2properties:
3  happ_attestation_roots:
4    - "<hApp Auth's 32-byte root key>"
5    - "<another issuer's root key>"     # several issuers are normal
6  happ_attestation_accept:
7    - claim_type: github-age
8      min_value: 365                     # days

Roots are long-lived and held offline, because changing properties forks the network. The online issuing key rotates under a root-signed delegation without a new DNA hash. Several roots from several issuers are normal.

The claims, v1

There is no “verified human” claim. Each new type needs a named source of evidence and a reason it needs little revocation.

What a claim costs to fake

github-age is a cost, not a person: aged GitHub accounts are sold, seasoned ones for thousands of dollars, and a sold account keeps its attestations because revocation inside a network is soft. maintainer is only as strong as hAppRadar’s claim proof and its bar for listing a project. Each attestation names one DNA, so one bought account yields one proof per network it asks for, never a proof that replays across networks, and issuance is rate-limited per account.

Combine claims where it matters, and where admission should be a person’s judgement, choose the Joining Service’s operator approval instead.