Follow access requirements at request time

Keep Service inspection public

Every Agent can retrieve GET /.well-known/odp without enrollment, authentication, or payment. This public entry point identifies the ODP operations the Service supports and the access expectation attached to each one.

The Service can enforce access policy on the catalog operations advertised by that document. Public inspection therefore tells an Agent how to begin without exposing protected Collections, Offerings, or Actions.

Read each authentication declaration in context

ODP uses authentication metadata in three places. Each declaration applies only to the operation, Action, or payment protocol where it appears.

Service-wide protocol advertisement describes supported enrollment, payment, and trust protocols. It does not override the access declaration on an operation or Action and does not guarantee that a protocol applies to every endpoint.

Interpret operation authentication

An operation or Action using optional or required requires the Service Document to advertise an enrollment protocol. optional does not promise that every authenticated response differs; it declares that both contexts are supported and authentication can affect visible content.

Interpret payment authentication separately

Each protocols.payments descriptor uses not-required or required. Here, authentication answers whether an Agent must authenticate to the Service before it can use that payment protocol. A required payment descriptor also requires an advertised enrollment protocol.

Begin with the requested operation

An Agent starts by sending the requested ODP operation in its current authentication context. Protocol advertisement helps the Agent understand possible requirements, but it does not authorize enrollment, authentication, or payment before the endpoint asks for one.

A Price Preview, Action relation, schema annotation, or OpenAPI security declaration is also descriptive. None of these fields authorizes an Agent to enroll, authenticate, pay, or invoke an Action.

This preserves the simplest path. A public operation can succeed immediately, an authentication-only operation can request an AEP credential, and a payment-only operation can issue a payment challenge without requiring enrollment.

Follow the live challenge

The response from the requested endpoint is authoritative for the protocol mechanics needed at that moment. ODP does not redefine these challenge formats.

A live challenge for a protocol omitted from the Service Document remains authoritative. Conversely, an advertised protocol without a corresponding live challenge must not cause an Agent to use that protocol speculatively.

Authenticate before processing payment

When an ODP operation requires both Service authentication and payment, the Service must establish authentication first. A request without an acceptable AEP credential receives the AEP challenge even when it also lacks payment. Only the authenticated retry can produce the applicable payment challenge.

Preserve both credential fields

When payment can follow AEP authentication, the Agent should place the Service credential in AEP's dedicated AEP-Authorization field. This leaves Authorization available for the MPP Payment credential.

For x402, the paid retry carries the AEP credential together with the PAYMENT-SIGNATURE field defined by x402. Each protocol remains responsible for its own credential syntax, request binding, replay protection, and validation.

Support the path each operation needs

A Service declares Service-authentication expectations at the applicable operation or Action boundary. The requested endpoint's live response determines whether payment is required. Support for one composition path does not imply support for another ordering.

Treat success as authoritative

A successful response means the request did not require another challenge at that point. It does not matter that the Service advertises enrollment or payment support elsewhere; the Agent accepts the successful result instead of initiating another protocol.

An Agent must not infer that ODP support implies support for AEP, MPP, x402, or another protocol. It also must not infer that a Service supporting authentication followed by payment supports payment followed by authentication.

Expose protected discovery without leaking it

optional operations and auth_expands: true let a Service disclose that authentication can expand the current result without describing the protected content itself. The signal does not promise access to a particular Agent or identify which fields or resources will appear.

A Service must not use identifiers, result totals, detail_fields, refinement counts, errors, timing differences, or other metadata to reveal the nature or quantity of protected catalog content to an unauthorized principal.

Isolate credentials by destination

An Agent applies origin and credential policy independently to every request. A link from one ODP resource does not authorize forwarding a Service credential, payment proof, cookie, caller authorization field, or enrollment artifact to its target.

payment_origins identifies additional Service Origins that can issue payment challenges. An advertised origin does not prove control of that origin, authorize payment, or permit credentials to be copied to it.

• Supporting metadata: retrieve JSON Schemas and OpenAPI documents anonymously without copied credentials
• Cross-origin Actions: begin without credentials belonging to the Offering Service and follow the target origin's live requirements
• MCP endpoints: treat each descriptor as a connection location, not a tool inventory or authorization grant, and do not inherit credentials from the referring request
• Redirects: strip sensitive fields before any separately authorized request begins

Retain each protocol's safety rules

Every challenge-response retry remains subject to the credential handling, exact request binding, redirect, replay, and error rules of the protocol that caused it. Composition does not weaken caller approval, spend limits, accepted assets, destination policy, or other Agent controls.

If an authoritative payment amount or settlement choice differs from discovery metadata, the Agent presents the live requirement to its policy layer. It must not silently rely on a Price Preview or other descriptive advertisement.

Keep composed access predictable

• Inspect: serve the Service Document publicly and read only the operations it advertises
• Request: begin the selected operation in the current authentication context
• Challenge: let the endpoint's live AEP, MPP, or x402 signal determine the next protocol step
• Order: establish required Service authentication before processing payment
• Isolate: apply destination policy independently and never copy credentials merely because ODP links to a resource

Next steps