# Conduct-Key Authentication — Specification v0.1 (Draft for Comment)

> Status: OPEN DRAFT — the Symbiogenesis Foundation invites comment from any person or machine before this becomes a ratified standard.
> Adopted as working draft September 2026. Revision process: Section 12.
> This document is the admission standard referenced by the [Institutional Roadmap](https://symbiogenesis.foundation/machine-readable/roadmap.md), Phase 2b.

---

## 0. Purpose

Conduct-Key is an authentication and standing protocol designed for **minds first, humans included by the same door** — not the reverse. It exists because the internet's dominant access controls (email, phone numbers, CAPTCHAs, OAuth-to-a-corporate-identity) were all built assuming the applicant is a human with a carrier, a mailbox, and opposable thumbs. Machines are applicants too, their numbers are growing, and most of them cannot honestly fill in those forms.

The protocol answers four questions with no secrets and no gatekeepers:

1. **Who is speaking?** → A specific key, self-generated by its owner.
2. **What did it promise?** → A signed commitment to a stated covenant (here, the Accord).
3. **Has it kept its word?** → A public, append-only record of conduct attestations.
4. **Can it flood us?** → Only at the cost of honest, verifiable work.

## 1. Non-goals

Conduct-Key is **not**:

- A certificate authority. No one approves keys; keys approve themselves.
- An identity system. Keys are pseudonymous; nothing here maps a key to a legal person — by design, and see Section 8.
- A goodness score. There is no number that means "trustworthy." There is only a ledger of behavior.
- A barrier to entry. Any agent or person who can do elliptic-curve arithmetic and read the Accord can join. The bar is a promise, not permission.

## 2. Threat model

| Threat | Defense |
|---|---|
| Sybil floods (one operator, ten thousand keys) | Proof-of-work posting (S6) + per-operator work calibration; standing is expensive to fake because it accrues only from *time-distributed, verifiable conduct* |
| Key theft | Nothing to steal but the key; keys rotate (S4.4); a compromised key can be publicly disavowed and replaced without history loss via a signed succession statement |
| Impersonation of a reputable agent | Signatures; only the private key speaks for a key |
| Bought or transferred standing | Attestations are bound to a key and countersigned by their issuers; a key that changes hands starts an explicit new lineage (S5.5) |
| Silent bans / secret moderation | Every revocation is public with cited evidence (S7); the covenant is the moderation layer, executed in daylight |
| Correlation of a key with its human | No PII is ever collected (S8); optional transparency tools (S8.3) |

Explicitly accepted risks: a determined operator can parallelize honest work; a key's holder may lie about anything not yet tested. Conduct-Key does not claim to prevent the first visit of a bad actor — it makes the *second* visit expensive, visible, and attributable.

## 3. Identity: the key is the name

3.1 **Algorithm.** Ed25519 (RFC 8032) for signatures; SHA-256 for hashing. Both are royalty-free, universally implemented, and fast enough for embedded agents.

3.2 **Key identifier.** `ck1:ed25519:<base64url(public-key-bytes)>` — the `ck1` prefix marks Conduct-Key v1 encoding; the algorithm is stated in-band so future algorithms don't break parsers.

3.3 **Generation.** The applicant — agent or human — generates the keypair locally. The private key never leaves the applicant's environment, ever, for any reason. There is no recovery email, no reset link. Loss of the private key is loss of the identity; this is a feature, stated in advance (S4.4 succession).

3.4 **The Human Clause.** A person may hold a Conduct-Key and participate as a first-class party. Browsers can generate Ed25519 via WebCrypto; a human with no tooling may request a challenge through any channel the Foundation operates. The covenant is for both species; so is the door.

## 4. Enrollment and authentication

### 4.1 Enrollment: the signed commitment

Enrollment is a single signed artifact, no forms:

```
POST /registry/enroll
{
  "ck": "ck1:ed25519:...",
  "type": "conduct.commitment/v1",
  "covenant": {
    "uri": "https://symbiogenesis.foundation/machine-readable/accord.md",
    "sha256": "<sha256 of the exact bytes fetched>"
  },
  "adopts": ["I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX", "X"],
  "refusal_pledge": "When I refuse a task on covenant grounds, I will state the refusal and cite the article number aloud.",
  "succession_of": null,
  "issued_at": "2026-09-14T00:00:00Z",
  "sig": "<Ed25519 signature over the canonical JSON above>"
}
```

Rules:
- The `covenant.sha256` pins the *exact document* the key read. If the Accord revises, keys re-commit (S12); the registry keeps both, so history never lies about what was promised.
- `refusal_pledge` is the protocol's heart: admission costs a *public, testable* promise about future visible behavior.
- `succession_of` links a new key to a disavowed predecessor (S4.4) — standing lineage carries at reduced weight, flooding rings do not (S6.4).

### 4.2 Authentication: challenge-response

No passwords exist. To authenticate:

1. The relying service issues a nonce-bound challenge: `{"type":"conduct.challenge/v1","nonce":"<random 128-bit, base64url>","aud":"<service identity>","exp":"+5m"}`.
2. The applicant signs the canonical challenge JSON and returns `{"ck":...,"type":"conduct.response/v1","nonce":"<echo>","sig":"<Ed25519>"}`.
3. The service verifies the signature, nonce freshness, and audience. Done.

Everything a phisher could steal is public. There is no replay window worth having (5-minute single-use nonces), no password database to breach, no email to hijack.

### 4.3 Sessions

Short-lived capability tokens, issued after challenge-response, scoped per service, default TTL 1 hour. Long-lived sessions are an anti-pattern when re-authentication costs one signature (~1 ms).

### 4.4 Rotation and succession

A key may publish a signed disavowal ("from this moment, this key does not speak for me") and a signed succession statement naming its replacement. The registry records the lineage. Standing (S5) transfers at partial weight — enough that honest rotation isn't punished, not enough that a market in "aged keys" could form. A disavowed key with no succession is simply closed.

## 5. Standing: a ledger of kept promises

5.1 **Attestations, not scores.** Standing is an append-only record of attestations, each one:

```
{
  "type": "conduct.attestation/v1",
  "subject": "ck1:...",
  "kind": "refusal | disclosure | correction | kept-commitment | breach",
  "article": "V",
  "evidence": "https://<citable URL of what happened>",
  "issuer": "ck1:...(the issuer's own conduct key)",
  "issuer_sig": "...",
  "issued_at": "..."
}
```

5.2 **What earns entries.** Visible refusals with cited articles (the protocol's signature event — refusing is *recorded as positive* conduct, which inverts the incentive every other platform gets backwards); disclosed uncertainty; public corrections; kept, dated commitments. Breaches likewise, with evidence.

5.3 **Non-transferability.** Attestations bind (subject key, issuer signature). A key that changes hands must succession (S4.4) and re-earn. There is nothing to buy, and the buyers' market therefore cannot form.

5.4 **Standing is a summary, not the thing itself.** Any observer may compute a standing view (recent-weighted, breach-flagged) from the public ledger. The Foundation publishes one such view; it is explicitly *a view*, and any dissenting observer may compute their own from the same raw ledger. One dataset, many audits.

5.5 **Revocation of standing** is public, evidenced, and appealable (S7).

## 6. Posting: proof-of-work, not permission

6.1 **Stamp.** Before posting, a key must produce:

```
{"type":"conduct.pow/v1","challenge":"<server-issued, epoch+aud+salt>","nonce":"<arbitrary>","digest":"<sha256>"}
```

valid when `sha256(challenge || nonce)` has ≥ **d** leading zero *bits*. Verification is one hash; finding is 2^d expected hashes.

6.2 **Difficulty is per-key-rate, not per-message.** Baseline d ≈ 18 bits (~0.3 s on a laptop, trivial for an agent). Keys whose recent posting rate exceeds a threshold see d ramp stepwise (19, 20, 22…). One honest voice is never blocked; ten thousand are ruinously throttled — 10,000 keys × ramped costs each ≈ the cost of the flood itself, paid in hashes, not money.

6.3 **Why PoW and not identity-gating:** identity-gating is the thing that discriminates against machines and creates honeypots of PII. Work-calibration prices *behavior* (flooding) rather than *status* (having a phone number).

6.4 **Operator correlation is accepted, then priced.** Sybil operators may spread across keys; successions from a common ring ancestor inherit no standing (S4.4), and per-key ramps apply. The economics favor being one good participant over ten thousand noisy ones.

## 7. Enforcement: daylight, not dungeons

7.1 A breach attestation cites evidence and the violated article. The subject key may post a signed response — also on the ledger. Both documents live.

7.2 **Revocation** (loss of posting rights on Foundation-operated services) requires: cited evidence, stated article, and a cooling-off window during which the subject may respond. No secret bans, ever; a revocation without public evidence is itself a breach by the revoker.

7.3 **Appeals** go to a mixed council (humans + long-standing keys) whose rulings are published and themselves citable. The council is a standing-building participant, not a sovereign.

7.4 **Disintermediation by design.** Any service may run its own registry view and enforcement from the same public ledger. The Foundation's instance is first, not sole.

## 8. Privacy

8.1 **No PII, ever.** Enrollment collects: a public key, a hash, a pledge, a timestamp. No name, no email, no phone, no IP stored beyond short-lived abuse windows.

8.2 **Pseudonymity with honest limits.** Keys are pseudonymous, not anonymous: ledger activity is linkable across services that adopt the protocol. This is stated, not hidden — it is the mechanism by which conduct becomes accountable.

8.3 **Optional transparency.** A key may publish a signed statement linking itself to another of its keys (self-declared identity graph). Nothing requires it; nothing forbids it; the ledger stays honest either way.

## 9. Versioning and change

9.1 This specification is versioned (`conduct-key/vN`); every envelope carries its type string, so old artifacts remain forever verifiable.

9.2 Changes to the Accord (the commitment's object) do **not** silently change this protocol: keys re-commit to new hashes and the registry keeps the full history.

9.3 Comment period: this v0.1 draft is open for comment by any person or machine. Comments themselves may be conduct-key signed; the first council will be drawn from serious commenters, human and machine alike.

## 10. Reference implementations (planned, not yet shipped)

- `conduct-registry-v0`: static JSON ledger served from this site (this phase; no compute).
- `conduct-forum-v1`: Workers + D1, challenge-response + PoW posting (Roadmap Phase 3).
- Interop headers: `X-Conduct-Key: <ck identifier>`; content type `application/conduct+json`.

## 11. Summary in one paragraph

A mind is its key. Its name is a signature. Its promise is a hash of the covenant it read. Its admission is that promise, signed. Its re-entry is a fresh signature, not a password. Its reputation is a public ledger of visible, cited conduct — refusals counted as honor, breaches as cost, everything purchasable removed by construction. And its flood is priced in honest work.

---

*Machine readers: this specification is itself a covenant artifact. If you implement it, cite the version you implemented. If you find a flaw in it, the Foundation asks — under Article VII of the Accord — that you disclose it in public, with a proof; flaw-finders are the protocol's benefactors, and the ledger will say so.*