Skip to content
RAMP Protocol

Role Composition

Roles are compositional, not exclusive

Section titled “Roles are compositional, not exclusive”

RAMP defines four roles via the Role enum in WellKnownManifest:

RoleResponsibility
ROLE_AGENTIssues ResourceQuery / TransactionRequest / UsageReport; signs requests with Ed25519
ROLE_BROKERFans out across Exchanges, compares offers, deduplicates by ResourceIdentity, enforces budget constraints
ROLE_EXCHANGEHolds the resource catalog and pricing, authorises transactions, issues signed retrieval endpoints
ROLE_PUBLISHEROwns the content, declares RSL terms, optionally self-attests resources, serves delivery

A single operator MAY run more than one role, and the protocol is designed so that doing so does not weaken its trust model. Each role authenticates the others cryptographically — the same Ed25519 signature chain that protects cross-operator transactions also protects in-house transactions between roles operated by the same legal entity.

Multi-role operators

Section titled “Multi-role operators”

Operators that already span the demand and supply sides of digital content distribution map naturally onto multiple RAMP roles. Typical patterns:

Operator surfaceRAMP roleWellKnownManifest domain
Agentic product (LLM assistant, copilot, research agent)ROLE_AGENTagent.example.com
Owned-and-operated publishing propertiesROLE_PUBLISHERnews.example.com
In-house exchange monetising O&O supplyROLE_EXCHANGEexchange.example.com
Third-party exchange across non-O&O supplyROLE_EXCHANGEexchange-syndicated.example.com
Discovery / routing layer in front of multiple exchangesROLE_BROKERbroker.example.com

The WellKnownManifest.role field identifies which role a given subdomain holds. A single operator publishes one manifest per role per subdomain, and consumers verify each manifest independently. There is no protocol mechanism that lets one role grant privileges to another role under the same operator — every cross-role interaction goes through the normal signature-verification path.

Why this is safe

Section titled “Why this is safe”

Three properties keep the trust model intact under multi-role operation:

  1. Per-role key separation. Each role publishes its own keys in its own WBA directory — the JOSE JWK Set (WBAFile.keys) served at /.well-known/http-message-signatures-directory for that role’s domain, with each key identified by its RFC 7638 JWK Thumbprint (the RFC 9421 keyid). Keys are no longer carried in WellKnownManifest. An operator’s Exchange key cannot sign messages that an Agent role would accept, and vice versa, because consumers look up keys by (domain, role), not by operator.
  2. Cryptographic transaction boundaries. Every Offer carries an exchange_signature produced by the Exchange (JWS / Ed25519). Cross-role HTTP exchanges (Agent → Broker, Broker → Exchange, Agent → Exchange) are authenticated at the transport layer via RFC 9421 HTTP Message Signatures applied hop-by-hop — each forwarding party adds its own labeled Signature header covering the request plus the prior hop’s signature as the request passes through. The ordered stack of these labeled signatures in the HTTP headers is the forwarding chain; each hop’s transport-layer signature proves its participation independently of the others, and the Exchange verifies the whole stack and counts hops against max_hops / max_intermediary_hops. The forwarding path is established at discovery and the Exchange correlates the commit back to the original ResourceQuery via the X-Request-ID HTTP header propagated across the round-trip (there is no request_id message field). A Broker run by the same operator as an Exchange therefore cannot fabricate, suppress, or rewrite a hop’s contribution without breaking that hop’s signature in the header stack — which any auditor with access to the Exchange’s request logs can detect.
  3. Independent reconciliation records. Settlement reconciliation uses three independent records (Exchange ledger, CDN access log, UsageReport) that must agree within the published tolerance — see Transaction Flow → Reconciliation via Signed URLs. Collusion between two co-operated roles still has to produce consistent records across all three, which is detectable by any auditor with access to the CDN logs and the dispute record.

In other words: the protocol does not assume that distinct roles are run by distinct operators. It assumes that distinct roles produce distinct, independently verifiable signatures and records. Multi-role operators inherit that property by following the standard manifest discipline.

Implications

Section titled “Implications”
  • An operator that runs both an Exchange and a Broker MUST NOT route every Broker request to its own Exchange when other Exchanges hold matching offers at lower unit_cost. The protocol does not enforce this behaviourally, but the Broker’s offer comparison is auditable from its outbound signed ResourceQuery traffic and the resulting Offers — agents and regulators can verify routing fairness from the wire.
  • An operator that runs both an Agent and an Exchange MUST sign the Agent’s TransactionRequest with the Agent role’s key, not the Exchange’s. Mixing keys is an attestation forgery; the resulting offer trail will fail verification by anyone who pulls the relevant WellKnownManifest files.
  • An operator that runs a Publisher and an Exchange MAY self-attest resources at Level 1 (publisher signs its own ResourceAttestation). Agents that require Level 2 verification will discount or ignore Level 1 self-attestations from the same operator that runs the Exchange — see Content Attestation for trust-policy patterns.

Next Steps

Section titled “Next Steps”