# Independent implementation and adversarial review guide

The useful external milestone is a team reproducing the contract with its own
code and reporting what breaks. This guide defines evidence to collect; it is
not a claim that an independent team or security review has already done so.
The supplied JavaScript and Python implementations share project authorship.

## Reproduce an implementation

Start from [SPEC.md](SPEC.md), [PRESENCE.md](PRESENCE.md), the public vectors and
the [adapter protocol](PRESENCE-ADAPTER.md). Record the source repository and
exact commit, authors, language, dependency locks, build instructions, supported
profile and implemented components. Distinguish an original verifier from a
wrapper calling the reference verifier. Neither automatically constitutes a
stateful authority or an independently operated deployment.

Run the full corpus in an isolated environment containing only public fixtures.
Retain the runner and corpus digests, implementation metadata, complete report,
and the commands needed to rebuild and rerun it. Verify the metadata against the
source actually executed: the runner reports it as unverified. Have another
operator repeat the run from the published source. Report disagreements and
unsupported behavior openly; do not remove failing cases to obtain a pass.

An optional [detached report attestation](PRESENCE-ATTESTATION.md) identifies the
holder of an independently pinned key who attested to exact report bytes,
corpus/runner digests, source revision, profile and metadata. Authenticate the
key separately and compare all expected bindings using the verification CLI.
Do not derive its trust pin from the candidate attestation. Retain the original
report bytes; even a final newline is part of its digest. Unsigned reports remain
supported and can still be reproduced locally.

A valid signature establishes attribution to that key, not truthful metadata,
trustworthy execution, implementation independence, independent operation,
security review or authority to perform an action. Verify the source actually
executed and reproduce outcomes regardless of signature status. Verification can
succeed for a signed mismatch or incomplete report; inspect `complete` and
`corpusMatch` separately. Historical evidence can be reverified; signatures do
not prove freshness or current key trust. None of this replaces the live,
stateful authority/executor checks.

Then add independently designed cases. The shared corpus is finite and public;
a table of hardcoded answers can match it. Agreement of two verifiers can also
preserve a shared misunderstanding. Include valid and invalid evidence produced
by your own serialization and signing code, not only mutations generated by the
reference implementation. Use synthetic keys and data throughout.

## Review the trust boundaries

| Boundary | Adversarial questions | Existing starting evidence |
| --- | --- | --- |
| Signed grammar | Are exact bytes, roles, domains, field sets and versions enforced? Can ambiguity or malformed encodings change meaning? | HAP-1 and WA-1 specifications; golden vectors |
| Registration | Who may initiate enrollment? Can a delegate replace the retained credential or choose its own trust pin? | Presence registration tests; `none` attestation limits |
| Action binding | Can one assertion transfer to another ticket, request, challenge, payload digest, nonce, RP, origin or deadline? | Presence vectors and wrapper hostile fixtures |
| Authenticator response | Are raw client bytes hashed? Are duplicate members, invalid encodings, signature/algorithm confusion, UP/UV and backup flags rejected correctly? | Cross-language assertion/registration cases |
| Counter and replay | Do counterless and increasing counters work while reset/regression and concurrent replay refuse? Does restart preserve consumption? | Presence race and SQLite restart tests |
| Revocation and budgets | Does revocation during a ceremony stop new permits? Can competing requests overspend or exceed uses? What is the disconnected-executor limit? | Core and presence stateful regressions |
| Durable commit and time | Can lost writes, delayed acknowledgments, rollback, stale backups or expiry release reusable authority? | Store, recovery, delayed-commit and witness tests |
| Executor isolation | Can an agent obtain provider credentials, an ungated tool, or a second execution route? Does an effect happen at most once? | External-executor/container tests; target deployment review |
| Inspection boundary | Can a historical receipt, read-only report or forged compatibility report be used as a live permit? | Inspection contract; mandatory stateful gate |
| User and private data | Is the action understandable before approval? What data remains on device, reaches peers or syncs with an authenticator provider? | Browser lab and documented metadata limits |

The compatibility runner covers stateless verification only. Durable state,
crash recovery, revocation delivery, rollback resistance and effect boundaries
must be tested against the actual authority/executor implementation and storage
stack. Do not infer those properties from a green verifier report.

## Test real authenticators separately

Record device, OS, browser and authenticator versions; platform versus roaming
authenticator; transport; backup/sync behavior; and the RP/origin configuration.
Test enrollment, successful UV, denied/cancelled UV, missing UP, timeout, repeated
ceremonies, counter behavior, credential loss, revoked authority, tab reload and
concurrent sessions. Observe storage eviction, offline behavior and actual
approval latency on target devices. A ceremony that misses the HAP deadline
must refuse; do not silently extend a signed deadline to make a demonstration
pass. Record unsupported combinations as unsupported.

Virtual authenticators and software fixtures are useful automated checks. They
do not establish the behavior of physical hardware or human interaction.
WebAuthn UV can provide stronger local-interaction evidence than a device key
alone; it does not establish legal identity, guaranteed biological liveness,
freely given consent, or understanding of every downstream consequence.

## Record findings and adoption claims

For each finding, retain a synthetic reproducer, affected component and exact
revision, attacker capabilities, expected versus observed behavior, impact,
fix revision and retest result. Coordinate sensitive findings privately with the
affected operator/maintainer before sharing public details. Never include real
private keys, credential exports, account tokens or personal operation logs.

An external review record should distinguish:

| Claim | Evidence needed |
| --- | --- |
| Corpus compatibility | Complete matching report, exact corpus/runner digests and reproducible implementation source |
| Report attribution | Exact report bytes and valid detached signature under an independently authenticated key and retained evidence pin; does not establish the other claims |
| Third-party implementation | Identified outside authors and repository, original implementation scope, independent reproduction |
| Independent security review | Named reviewer, scope and methodology, findings and unresolved limits, reviewed and fixed commits |
| Independent operation | Separate operator, its own keys/storage and deployment, tested revocation/recovery/executor boundaries |
| Physical authenticator validation | Device/version matrix and observed ceremony outcomes, distinct from virtual tests |

Leave a claim unestablished until its evidence exists. A verifier, adapter,
reference deployment, audit and real-world adoption are different deliverables.
Implementers need no central registry or Money Musk permission to use the open
profile. Preserve existing HAP-1/1 and WA-1 signed meanings; incompatible changes
require an explicit new profile and published compatibility evidence.