Reference
Specification & standards
auth51 isn’t a protocol you take on faith. What’s new — agent identity as a checksum, intent tokens minted per action, non-amplification across delegation — is written up as an IETF internet-draft. Everything underneath it is established OAuth, so if you know these RFCs you already know most of how auth51 works.
The auth51 protocol — the specification
The internet-draft is the normative spec: it defines the identity checksum, the intent-token profile, the MCP _meta propagation (Hop-A / Hop-B), and the non-amplification rules. The protocol overview is the readable companion to it.
Note
Standards it builds on
These are the base standards auth51 composes. The draft above specifies how.
- RFC 6749OAuth 2.0 Authorization Framework
The client-credentials grant an agent uses to authenticate as its org.
- RFC 8693OAuth 2.0 Token Exchange
How a signed-in console session is federated into an org-scoped authority token.
- RFC 9449Demonstrating Proof of Possession (DPoP)
Binds an intent token to a key held in the agent process, so a copied token is useless.
- RFC 7519JSON Web Token (JWT)
The shape of an intent token on the wire — identity, scope, audience, expiry.
- RFC 7517JSON Web Key (JWK)
How a resource server fetches the authority’s public keys (JWKS) to verify a token.
The paper
A companion paper (arXiv preprint) covers the threat model and the evaluation behind the protocol. Link lands here on publication.
API, config, and scopes
Endpoint-level reference for the authority and the client — request shapes, the environment variables the client reads, and the scope envelope a customer key carries — is being written and will live in this section.