# Fictional signed usage statement demo

This downloadable example contains a real Ed25519 signature over **entirely fictional** usage data. It does not make a payment or contact a service. It is **not a Vaaya statement format, live invoice, payment record, or supported integration**.

The example statement charges 10 search units × 1¢ plus 2 scrape units × 3¢: **16¢ total**, with a separately configured **20¢ owner-approved cap**. No real service units were purchased.

Run the included verifier with Node.js 18 or later:

```sh
node verify-usage-statement.mjs
```

The output should match `verification-results.json`. The script needs the PEM and both JWS files in the same directory. It uses only Node built-ins and performs no network requests.

Included files:

- `verify-usage-statement.mjs`: offline verifier and all 11 policy/signature scenarios.
- `public-key.pem`: public Ed25519 test key; no private key is included.
- `usage-statement.jws`: signed fictional statement.
- `usage-statement.json`: readable decoded copy of that statement.
- `tampered-statement.jws`: changed total with the original signature retained.
- `verification-results.json`: actual captured output from running the script.
- `provenance.json`: generation method, runtime, public-key fingerprint, and scope.
- `manifest.sha256.json`: file lengths and SHA-256 hashes, excluding the manifest itself.
- `README.md`: these reproduction instructions and limitations.

`usage-statement.jws` signs the exact compact-JWS protected-header and payload segments. `usage-statement.json` is a readable decoded copy, not the file trusted by the verifier. `tampered-statement.jws` changes the total from 16¢ to 17¢ but keeps the original signature, so cryptographic verification fails before the payload is parsed or its values are used.

The verifier only accepts EdDSA with an Ed25519 public key and the expected key ID. Its public-key fingerprint is pinned inside the script. It never follows a key URL or uses an embedded key from the statement. The custom `typ` is a demo label, not a registered billing standard or JWT claim set.

After signature verification, a separate policy checks the schema, expected issuer/customer/payee, currency, issue and expiry times, integer-cent arithmetic, approved cap, and previously seen identifiers. It uses a fixed example clock. The lower-cap, expiry, and identity-mismatch scenarios all use the original valid signature and fail policy checks.

In-memory replay fixtures illustrate a decision; they do not provide production protection against simultaneous payments, process restarts, or duplicate delivery. Production requires trusted key provisioning, rotation and revocation, durable atomic deduplication, stable payment idempotency, reconciliation, and evidence that the billed service was delivered. A valid signature alone establishes none of these. The key included with this demo is not independently verified as any business's identity.

The private test key was generated in memory to produce the demo signature and was not written to disk. No customer account, token, credential, or card is included. `provenance.json` describes how the files were made, and `manifest.sha256.json` records their SHA-256 digests. These digests provide artifact consistency, not independent certification of the demonstration.