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.
L4
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.
L5
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.jsagainst 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_urito 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>.jsonper 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 also re-validates every signature on every Pull Request.
- 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 (verified live by the Verifier). The OAP Registry applies a 30-day domain-age sybil filter (whois) before merging any new listing. L5 additionally requires that no two witnesses share a controlling organization.
- 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. Implementations publish a revocation entry in the OAP Registry signed by their DID Document's recovery key, or by three peer witnesses (forced revocation). Receipts signed after the suspected compromise time are flagged.
References: RFC 0019, RFC 0025, RFC 0026, Conformance Levels, OAP Registry.