brief.md JWS signing — verifying brief authenticity
A brief.md can be JSON Web Signature-signed by the operator so consumers can cryptographically verify it has not been tampered with. Required for the Q4 2026 source directory; recommended for any brief consumed by AI agents at scale.
Operators publishing brief.md to AI consumers want to prevent tampering or impersonation; consumers want a verifiable signal of authenticity.
Why signing matters
AI consumers will increasingly read brief.md to understand brand context. Without signing, an attacker who controls the network path between operator and consumer can substitute a tampered brief — change pricing, swap positioning, alter voice rules. JWS signing makes tampering detectable: the consumer verifies the signature against the operator's public key and rejects any mismatch.
How signing works
The operator generates an RSA or Ed25519 keypair. The public key is published at /.well-known/jwks.json under the operator's domain. The operator signs each published brief with the private key, embedding the signature in a `signature` field in frontmatter (or alongside, depending on transport). The consumer fetches the public key, verifies the signature, and only then trusts the brief content.
Per-brand vs per-operator signing
For most multi-brand operators, one operator-level key signs every brand's brief. This simplifies key management and matches the operator-identity boundary. Per-brand signing is supported for operators who need to delegate publishing rights (e.g., a holding company with operator-level brands authored by different teams).
Q4 2026 directory requirement
The PRAPI source directory at /sources will require JWS-signed briefs from V1. Brands publishing to the directory must sign with a key whose public component resolves at /.well-known/jwks.json. This prevents brand-impersonation attacks against the directory.
PRAPI plans to publish a JWKS at https://prapi.dev/.well-known/jwks.json before AppSumo launch. Each portfolio brand's brief.md will be signed with a single operator-level Ed25519 key (kid: "prapi-2026-q2"). The Q4 source directory will require JWS-signed briefs from V1.
FAQ
Do I need to sign my brief.md?
For low-stakes uses (your own AI tools, light personal use): no, signing is optional. For publishing to the PRAPI source directory: required from V1. For any high-stakes use where impersonation would be costly: strongly recommended.
Where do I publish my public key?
At /.well-known/jwks.json on the operator's apex domain. The JWKS format is the IETF standard. Consumers fetch the JWKS, find the key matching the brief's `kid` (key ID) header, and verify against that key.
What signing algorithms are supported?
The spec recommends Ed25519 (compact, modern) or RSA-2048 with SHA-256 (broadly compatible). Avoid HS256 (symmetric — secret-shared, defeats the point) and ECDSA (less library support).
What if my key is compromised?
Rotate the key, publish the new public key in JWKS, mark the old key revoked, and re-sign every published brief with the new key. Consumers will refresh JWKS and reject anything signed with the revoked key. Plan for rotation; the spec assumes keys will rotate.
Run brief.md in PRAPI.
PRAPI is the canonical brief.md implementation. Every brand in your portfolio gets its own brief.md, voice-validated drafts on every pitch, and Git-canonical authoring.
Sign in →