[CAP] Charter Agreement Protocol · the signer package
OAuth says who called. Even a signed contract only says what was promised on paper. CAP is the missing evidence layer for bilateral agreements — including agent commerce: the parties sign byte-exact descriptors, acceptances, and receipts, so “which terms governed this action?” is answered by cryptography, not chat logs. CAP verifies. It never authorizes. And the private keys never enter this library — this page generates both parties’ keys in your browser.
Both parties’ keys stay in this page’s custody —
A signed PDF proves someone agreed to some text. It does not prove which exact revision governed a given action, that both parties accepted those bytes, or that the acting key still belonged to its party.
“Version 2 of the terms” is a dispute waiting to happen when two systems hold two different version 2s.
Every revision is canonical JSON with a digest; acceptances bind those exact bytes. Rewriting one character breaks the chain.
One party attesting to its own agreement is marketing, not evidence.
Acceptance is two signatures over the same digest, each bound to the party’s key history via its descriptor.
“Verification” tools that whisper “valid — go ahead” are quietly making your business decision.
CAP returns structural verification facts. Your application decides authority, billing, legal validity, and whether an action may run. You read the evidence; you decide.
Everything is live: this page bundles the real signer and verifier packages. Two parties’ keys are generated in your browser; descriptors, acceptances, and a receipt get signed and post-verified against a canonical charter revision.
cap+party)Form, accept, and act first — then check the evidence bindings.
nothing selected yet
Three protocols, one chain of evidence: what the agent is, what was agreed, what this call may do.
One handle, two callbacks — atomic key snapshot and sign. The private key never enters: not the library, not this page’s bundles.
R1–R3: the signer refuses to sign claims it cannot honestly make — wrong chain, mismatched digest — after resolving the key snapshot, before the signing callback runs.
Every signature is verified against the snapshot’s public key before the artifact leaves — a custodian misconfiguration fails loudly.
Ed25519 today, ML-DSA descriptors from protocol revision 3 — the post-quantum lane is in the registry, not a promise.
| Function | Artifact | Post-sign verify |
|---|---|---|
signDescriptor | party descriptor (cap+party) — key history, transitions, fork evidence | verifyDescriptor |
signAcceptance | acceptance (cap+acceptance) — bilateral assent to exact bytes | verifyAcceptance |
signTermination | termination notice (cap+termination) — closure at a pure UTC instant | verifyTermination |
signReceipt | receipt (cap+receipt) — an action bound to revision coordinates | verifyReceipt |
Two callbacks, both may be async — remote custodians (HSM, KMS) are first-class.
interface KeyHandle {
keyIdentity(handle): { kid, publicKey } | Promise<…> // ONE atomic snapshot
sign(message, handle): Uint8Array | Promise<Uint8Array> // the holder's job
}
// The verifier checks claims, context, and the holder's descriptor key
// through prepareSigning, then assembles and verifies with finishSigning.
npm installs approved versions. During release review, download the staged archive for inspection.
npm i @charter-agreement-protocol/signer@^1.0.0 # one runtime dep: the verifier package