Certification

There is no certification authority.

OAP does not have a certification body. There is no fee. There is no application process. Conformance is a mechanical property: an implementation runs the open-source test suite, signs the resulting Receipt, and (for L4 and L5) collects peer-witness signatures from other already-conformant implementations. Every step is reproducible by every verifier, against the same code that produced the original Receipt.

L1 to L3

Self-attested

Issuer: Implementation itself

Proof: Signed Conformance Receipt produced by the open-source test suite

Run the suite. Sign the Receipt with your DID key. Publish the Receipt at a stable URL. Reference it from your Manifest. Anyone can re-verify by running the same suite against your deployment and checking the signature against your published DID Document. Optional but recommended: anchor the Receipt in the OAP Registry.

Peer-witnessed

Issuer: Implementation + at least 1 independent L4+ peer

Proof: Implementation signature plus at least one peer-witness signature, anchored in the OAP Registry (RFC 0026)

After self-attestation, send your Receipt to any other implementation that itself currently holds a valid L4 or L5 Receipt. The peer witness re-runs the suite against your live deployment and counter-signs the Receipt. Submit the resulting multi-signed Receipt to the OAP Registry as a Pull Request. The Registry CI gate verifies every signature mechanically.

Peer-Certified

Issuer: Implementation + at least 3 independent L4+ peers + third-party security audit

Proof: Implementation signature plus three independent peer-witness signatures, plus a machine-readable third-party security audit attestation (SOC 2 Type II, ISO 27001, or equivalent), anchored in the OAP Registry

L5 is the highest level OAP defines. It requires (a) every L4 requirement, (b) three independent peer-witness signatures whose witnesses themselves currently hold valid L4 or L5 Receipts and do not share a controlling organization, and (c) a third-party security audit. There is no central body that issues L5; it is a mechanical claim that any verifier can check against the Registry transparency log.

How to certify your implementation

Run the suite. node test-suite/runner.js against your deployment until the level you want passes.
Generate an Ed25519 key if you do not already have one: openssl genpkey -algorithm ED25519 -out signing-key.pem. Publish the public key in your /.well-known/did.json.
Sign the Receipt. node test-suite/attest.js --target https://you --did did:web:you --name "You" --version 1.0.0 --signing-key signing-key.pem --out conformance-receipt.json. For Non-Commercial Profiles add --profile non-commercial --revenue-source byok.
Publish the Receipt at a stable URL on your domain. Add conformance.receipt_uri to your Manifest pointing at it.
(L4 and L5 only.) Identify peer witnesses among current L4+ implementations listed in the OAP Registry. Send each your Receipt and ask them to run attest.js --peer-witness --in your-receipt.json --did their:did --signing-key their.pem --witness-receipt-uri https://them/.... Concatenate the returned witnesses into your Receipt.
Submit to the Registry. Open a Pull Request against openagentprotocol-OAP/oap-registry adding implementations/<slug>.json per the schema. The CI gate will validate every check from RFC 0026 section 6. If everything passes, a Maintainer merges the PR. The merge commit is your anchor.
Renew every 90 days. Re-run the suite, re-attest, re-collect witnesses, update the Registry entry. The Registry rejects expired Receipts.

Threat model

Forged Receipt. Receipts are signed with the implementation's DID key. Verifiers resolve the public key from the DID Document and check the Ed25519 signature mechanically. The OAP Registry CI gate enforces this on every Pull Request: the signature-verify job fetches the listed Receipt, recomputes the canonical bytes, fetches the listing's did:web Document, and rejects the listing unless at least one signature verifies against a published verificationMethod.
Placeholder signatures. RFC 0019 section 7.3 forbids any signature value matching PLACEHOLDER_NOT_FOR_PRODUCTION, unsigned-reference, or placeholder:* prefixes. The reference verifier rejects them. The Registry CI gate rejects them. attest.js will not emit them: it requires --signing-key.
Expired Receipt replay. Every Receipt declares not_after. Verifiers reject Receipts past expiry. Maximum validity is 90 days. The Registry tracks expiry and surfaces stale listings.
Sybil-attacker peer-witness farm. Peer witnesses must themselves hold valid L4+ Receipts. The Registry CI peer-witnesses job iterates every witness in the candidate Receipt, looks the witness DID up in the live Registry, and falls back to fetching the witness' own Receipt to confirm it currently claims L4 or L5 within an unexpired validity window. The OAP Registry also applies a 30-day domain-age sybil filter (whois) before merging any new listing.
Non-independent L5 witnesses. L5 listings additionally require at least three peer witnesses with three distinct DIDs AND three distinct controller domains (the controller domain is derived from did:web hostnames). The Registry CI peer-witnesses job rejects any L5 candidate whose witnesses share a controller. The same independence check runs as the peer-witness-independence behavior probe in the conformance suite.
Missing L5 external audit. L5 listings must reference a current external_audit attestation in their Receipt. The Registry CI l5-external-audit job rejects any L5 candidate whose Receipt is missing the external_audit block, has an audit framework outside SOC2-Type-II, ISO-27001, ISO-42001, or equivalent, lacks an auditor_did, or whose attestation has expired.
Captured Maintainer roster. The Registry is append-only. Historic Receipts cannot be retroactively forged. Mirroring is encouraged; the canonical state is reconstructible from any mirror. A community fork remains viable in the event of a hostile takeover.
Compromised signing key. Submit a revocation entry under revocations/<slug>-<receipt-sha256>.json in the Registry. The CI revocations job verifies the Ed25519 signature against either (a) your DID Document for self-revocation, or (b) three or more independent live L4+ peer-witness signatures for forced (Quorum) revocation. Once merged, any active listing whose conformance_receipt_sha256 matches the revoked Receipt is rejected by the gate until a new Receipt is published at a new URL.

References: RFC 0019, RFC 0025, RFC 0026, Conformance Levels, OAP Registry.