| Internet-Draft | UCAP Access | October 2026 |
| Neve | Expires 12 April 2027 | [Page] |
This document specifies an interoperable HTTP protocol for automated clients, including conventional web crawlers and AI-assisted agents, to request access to a resource, receive a transaction-specific offer, accept the offer, and obtain a cryptographically verifiable authorization for a particular request. Resource owners can perform authorization directly or delegate it to independent rights managers of any size. A rights manager determines the price and other conditions at the time of each request; this protocol does not expose or constrain pricing algorithms, payment rails, credit limits, invoicing schedules, or business relationships. The protocol binds an authorization to a request UUID, resource, authenticated crawler operator, intended use, and validity interval. It is designed as an optional extension to the proposed Universal Crawler Accountability Protocol (UCAP) and to existing HTTP authentication and bot identity mechanisms. The specification does not replace access controls, copyright law, or private commercial agreements.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Automated HTTP clients access resources on behalf of search engines, archives, accessibility applications, AI-assisted services, and other services. Some resources are free to retrieve; others may require a commercial license or other permission. Site owners currently use proprietary APIs, manual licenses, paywalls, or no automated negotiation mechanism at all. This document defines a vendor-neutral transaction exchange that can be implemented by an origin, CDN, rights manager, or crawler operator without membership in a central platform.¶
The defining interaction is: (1) an authenticated crawler submits a fresh UCAP request UUID and identifies the intended resource and use; (2) the origin or its authorized rights manager returns the offer applicable at that moment; (3) the crawler accepts that exact offer; and (4) the issuer grants an authorization bound to the UUID, and the resource origin independently decides whether to serve the requested content. The issuer may rely on invoicing, prepaid balances, deferred settlement, or contract credit. None of those mechanisms is mandated by the protocol.¶
The requester does not obtain the publisher's pricing algorithm or complete price schedule. A quote for an article might be EUR 1.00 this week and EUR 0.05 in a month, but each quote is a standalone time-bounded offer. Operators may use other currencies and nonmonetary terms. The protocol does not automatically confer rights beyond those explicitly specified in the agreed terms.¶
UCAP Core (draft-neve-ucap) addresses signed per-request identifiers, event verification, abuse reports, and crawler exclusions. This document describes an independently deployable authorization extension. A crawler's authentication does not imply any permission to retrieve, reproduce, index, summarize, retain, or train on a work.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals.¶
Resource Origin is the HTTPS origin serving the target content. Resource Owner is the party entitled to set access terms; control of an HTTPS origin does not, by itself, establish ownership of all intellectual property displayed there. Crawler Operator operates an automated HTTP client. Request UUID is a fresh opaque UUIDv4 identifying one intended HTTP request. Rights Manager is a service authorized by the resource owner to negotiate and issue access authorizations within a stated scope. Offer is an immutable time-bounded proposal for one transaction. Acceptance binds the requester to an identified offer. Grant is an authenticated authorization claim for the specified request. Settlement is the discharge of commercial obligations outside UCAP. Usage is a machine-readable label for the requested activity. Delegation is a revocable statement authorizing a rights manager to act within specific bounds.¶
An access grant does not prove that settlement has occurred, nor does it establish the legal validity of a license in all jurisdictions. The transaction references and Request UUID are not bearer secrets.¶
This protocol standardizes discovery, authenticated access requests, request-specific offers, acceptance, issuance and validation of grants, status queries, and revocation signals. It permits both direct and delegated rights management, free and paid access, and contract-specific offers.¶
This protocol does not specify prices, commission percentages, taxes, bank transfers, payment card operations, credit scoring, credit ceilings, annual invoicing, accounting rules, refund policies, or adjudication of copyright disputes. It does not require any publisher to use a particular CDN, processor, rights manager, or software vendor. It does not prevent a nonparticipating or malicious client from ignoring the protocol. Sites MUST continue to enforce their own access policies.¶
This protocol does not presume that every automated retrieval requires a paid license. Applicable law, exceptions, permissions, and contract terms remain independently relevant. No client acquires training rights merely because it paid for retrieval.¶
The principal roles are Crawler, Crawler Operator, Resource Origin, Resource Owner, and optional Rights Manager. A Rights Manager may serve one small publisher or many publishers; protocol conformity, not organizational scale, governs interoperability.¶
The Resource Origin is authoritative for its own access enforcement and for publishing or authorizing the location of its negotiation service. The Rights Manager acts only under authenticated delegation within the designated scope and period. A crawler signs access requests with an operator identity recognizable by the origin and manager. The manager signs grants; the origin trusts them only when the manager is currently authorized for the relevant scope. Intermediaries MUST NOT expand the grant beyond its stated audience and permitted use.¶
An origin MAY operate its own negotiation service. An origin MAY delegate access decisions to multiple managers for disjoint resource paths or usage categories. Ambiguous or overlapping delegations MUST be deterministically resolved by origin policy; a client MUST NOT select a permissive manager to bypass a more restrictive origin policy.¶
An origin supporting this extension SHOULD publish metadata at https://{origin-host}/.well-known/ucap-access. A compliant implementation MUST also permit explicit configuration without discovery. The metadata document is served over HTTPS with normal certificate validation and the media type application/json.¶
Example:¶
{
"version": "1",
"origin": "https://news.example",
"access_service": "https://rights.example/ucap/v1",
"delegation_id": "del-2026-publisher-a",
"delegation_document": "https://news.example/.well-known/ucap-delegation",
"supported_usages": ["ai_retrieval", "search_indexing"]
}¶
Discovery metadata MUST NOT be accepted from an unauthenticated crawler or an arbitrary HTTP redirect. The origin MUST authenticate delegations by HTTPS origin authority and a verifiable signed delegation document or a preconfigured trust relationship. An attacker-controlled link from an article does not constitute delegation. The crawler MUST validate any discovered endpoint against the signed delegation and MUST apply SSRF defenses.¶
A delegation record MUST bind issuer, delegated service identity, origin, resource scope, permitted usage categories, validity interval, and a unique delegation identifier. It MUST be cryptographically signed by an identity the origin has explicitly authorized. The record MUST be available to the origin when verifying grants. The signature encoding and cryptographic algorithm profile are deployment-dependent in version -00 and are an open interoperability issue; deployments MUST NOT treat an unsigned JSON document alone as sufficient proof of delegation.¶
Delegations MUST be revocable. A manager MUST refuse to create new grants after revocation takes effect. An origin MUST reject a grant when its delegation is no longer valid under local policy, even if the grant itself has not expired. Caching and propagation semantics MUST be defined by the deployment and bounded by an explicit maximum lifetime.¶
A publisher MAY delegate different paths or usage classes to different managers. Each negotiation response MUST unambiguously identify the authority under which it was issued. An origin MUST determine the applicable manager from its own trusted mapping, not from a crawler-supplied URL. The protocol MUST NOT require any organization to join a central registry or commercial clearinghouse.¶
The crawler MUST generate a new RFC 9562 UUIDv4 for each intended content retrieval and place it in Crawler-Request-ID. The authorization request MUST identify the target HTTPS URI, intended HTTP method, and intended usage. The operator MUST authenticate to the negotiation service. The final content request MUST carry the same UUID and a verifiable operator identity using HTTP Message Signatures (RFC 9421) or an equivalent mutually configured proof-of-possession profile.¶
The request UUID, method, URI and operator identity MUST be cryptographically bound to prevent substitution. A UUID, User-Agent, source IP, or grant ID alone MUST NOT confer access. Operators MUST protect against replay, duplicated requests, and token theft.¶
Each fresh physical retrieval SHOULD have a distinct UUID even if the same URL is requested again. A granted transaction MUST NOT silently authorize a different URL, method, operator, or usage. A redirect to a different protected URI requires a fresh authorization unless a signed grant explicitly covers a bounded set of URIs.¶
A normal transaction moves through the following states: requested, offered, accepted, granted, consumed, and optionally settled. Alternative terminal states include declined, expired, revoked, denied, and failed. settled refers only to a reported commercial status when the issuer chooses to publish one; it is not necessary for authorization.¶
A client MUST NOT retrieve a protected resource merely because it received an offer. The manager MUST NOT issue a granted status before acceptance or another independently valid authorization condition. An accepted offer MAY result in delayed authorization if the issuer requires internal approval. Accepted commercial obligations and actual payment status are distinct.¶
A transaction MUST be bound to at most one active offer acceptance for the same request UUID. Multiple accepted offers for one UUID MUST NOT result in duplicate billable consumption; replacements require cancellation or a new UUID. Implementations MUST define retry and idempotency behavior.¶
All API requests use HTTPS. JSON bodies use application/json, and errors use application/problem+json as specified by RFC 9457. Times MUST use RFC 3339 UTC. Monetary decimal values MUST be JSON strings, not binary floating point numbers. Currency identifiers SHOULD use ISO 4217 codes. Endpoints MUST authenticate the calling party, enforce authorization and rate limits, and log security-relevant administrative events.¶
A client SHOULD supply Idempotency-Key on POST operations. Servers MUST make acceptance and grant issuance idempotent for a given transaction and authenticated principal; they MUST NOT charge twice due to retries. The server MUST support safe repeat retrieval of an already accepted grant. Clients MUST NOT follow arbitrary redirect chains to negotiation or payment endpoints.¶
Endpoints are shown relative to an authenticated and discovered service base /ucap/v1. Resource paths are illustrative but normative for this proposal. Errors MUST distinguish invalid syntax, unauthenticated calls, forbidden scope, unavailable offer, expired offer, already consumed authorization, and temporary backend failure without leaking unrelated customer data.¶
The crawler sends POST /access/requests with a UUID, resource URI, method, usage, and authenticated operator identity. It MAY supply a contract reference previously issued by the manager, but MUST NOT claim arbitrary commercial privileges through self-asserted attributes.¶
POST /ucap/v1/access/requests HTTP/1.1 Host: rights.example Authorization: Bearer <operator-bound-token> Content-Type: application/json Idempotency-Key: 11c63613-8893-45d1-9b65-44acbe10a940¶
{
"request_uuid": "550e8400-e29b-41d4-a716-446655440000",
"resource": "https://news.example/articles/12345",
"method": "GET",
"usage": "ai_retrieval"
}¶
A successful response MAY contain a free grant directly if the applicable policy explicitly permits it. For a negotiated access, a successful response MUST contain a unique offer identifier, exact resource and usage, quoted terms, validity interval, and manager identity. It MUST reflect the price applicable at the time of quotation; the client MUST NOT be required to fetch or know the publisher's pricing formula or price history.¶
An offer MUST specify its identifier, request UUID, resource, usage, currency and amount when payment applies, permitted rights, and expiration. A paid offer MUST distinguish the payment obligation from completed settlement. An offer MUST contain a stable terms_digest calculated over the canonical accepted terms or reference immutable signed terms retrievable by the client. The canonicalization and digest algorithm profile MUST be negotiated or standardized before broad interoperable deployment.¶
{
"offer_id": "offer-rtbf-2026-184",
"request_uuid": "550e8400-e29b-41d4-a716-446655440000",
"resource": "https://news.example/articles/12345",
"usage": "ai_retrieval",
"rights": ["retrieve_once", "temporary_processing"],
"price": { "amount": "1.00", "currency": "EUR" },
"settlement": { "mode": "contractual", "reference": "license-2026-184" },
"offer_expires_at": "2026-10-09T19:00:00Z",
"issuer": "https://rights.example",
"delegation_id": "del-2026-publisher-a",
"terms_digest": "sha-256:EXAMPLE-NONFUNCTIONAL-DIGEST"
}¶
A monetary price MAY be zero. When no payment is due the issuer SHOULD omit the price object or use an explicit free offer profile; zero-priced offers MUST NOT be confused with a paid transaction subsequently discounted to zero. The settlement.mode indicates a recognized arrangement, not an instruction to perform a payment. Implementations MUST NOT require publication of credit balances, negotiated discounts, issuer risk scoring, or annual payment schedules.¶
An offer MUST remain immutable until expiration. If a price changes before acceptance, the issuer MUST create a new offer identifier. An offer accepted before expiration remains bound to the accepted price and terms even if the issuer's current rate later changes, except as explicitly provided by those accepted terms and applicable law.¶
The crawler accepts via POST /access/offers/{offer_id}/accept. The request MUST identify the original UUID and exact terms_digest and MUST be signed or authenticated as the same operator requesting the offer.¶
POST /ucap/v1/access/offers/offer-rtbf-2026-184/accept HTTP/1.1 Host: rights.example Authorization: Bearer <operator-bound-token> Content-Type: application/json Idempotency-Key: 9d35d0e7-2d01-496f-8314-ceaa91f7f036¶
{
"request_uuid": "550e8400-e29b-41d4-a716-446655440000",
"terms_digest": "sha-256:EXAMPLE-NONFUNCTIONAL-DIGEST",
"accepted": true
}¶
The issuer MUST verify identity, validity, offer status, scope, and accepted terms before granting access. The issuer MAY consult private commercial risk and credit controls. If the credit agreement is insufficient, the issuer MAY deny the acceptance without disclosing the counterparty's remaining credit balance. The protocol does not dictate whether a grant precedes or follows settlement; the offer terms determine that relationship.¶
A decline MAY be transmitted to POST /access/offers/{offer_id}/decline but no decline message is required; expiration is sufficient. An issuer MUST NOT infer acceptance from silence or a content retrieval attempted without an authorization grant.¶
A successful acceptance normally returns an opaque grant_id, a grant object or reference, and the current state. The grant MUST be signed or otherwise verifiable under a trust relationship established by the origin. The following JSON is a claims example only; it MUST NOT be mistaken for an interoperable cryptographic envelope. An interoperable version MUST choose a defined envelope profile such as a COSE or JWS-based format.¶
{
"grant_id": "grant-rtbf-2026-184",
"request_uuid": "550e8400-e29b-41d4-a716-446655440000",
"issuer": "https://rights.example",
"delegation_id": "del-2026-publisher-a",
"audience": "https://news.example",
"operator": "https://crawler.example",
"resource": "https://news.example/articles/12345",
"method": "GET",
"usage": "ai_retrieval",
"rights": ["retrieve_once", "temporary_processing"],
"offer_id": "offer-rtbf-2026-184",
"not_before": "2026-10-09T18:50:00Z",
"expires_at": "2026-10-09T19:05:00Z",
"uses_allowed": 1
}¶
The grant MUST bind the same operator, UUID, target URI and usage present at acceptance. It MUST include an expiry and SHOULD have a short lifetime appropriate for a single content retrieval. The origin MUST validate the issuer's current authority, grant signature, time window and request binding, and MUST apply its own policies before serving content. A manager's grant does not force an origin to produce HTTP 200.¶
A grant MAY be referenced via an authenticated HTTP header on the final request or retrieved from an authorization-status endpoint. The exact wire encoding for the grant reference and signature verification profile MUST be standardized before interoperable deployment. Origin administrators MAY choose login requirements, 403 responses, subscription controls, or other enforcement strategies independently of this protocol.¶
The crawler submits the authorized HTTP request with Crawler-Request-ID, valid operator authentication, and the relevant grant reference or cryptographic proof. The origin MUST verify that the grant was issued to this operator and covers this exact request. A request using another URI or another usage MUST NOT inherit the authorization.¶
The origin MAY record a successful consumption event and transmit a receipt to its manager under a mutually authenticated channel. The receipt SHOULD identify the request UUID, grant ID, outcome, timestamp, and byte count when available, but MUST NOT expose cookies, article bodies, or personal account tokens. The parties MUST define whether billing occurs on acceptance, successful HTTP response, or another contractual event; the standard MUST NOT assume all successful grants are billable consumptions.¶
For one-time grants, the origin MUST prevent concurrent replay or define atomic redemption, including requests through multiple edge servers. Retries caused by network failures SHOULD use a server-supported reconciliation procedure and MUST NOT create a second commercial charge by default. Cache behavior MUST respect authorization and must not leak licensed content into public shared caches.¶
A crawler MAY query GET /access/transactions/{request_uuid} for the transaction's state. Operators MUST only disclose transaction records to authenticated and authorized parties. A resource owner or authorized manager MAY revoke a grant through their existing trust channel, and a crawler MAY request cancellation where permitted by the commercial agreement. Revocation acknowledgments MUST distinguish recorded, propagating, active, and rejected states.¶
A grant expiring or being revoked does not automatically cancel an accepted payment obligation or undo rights already exercised. Refund and dispute consequences are governed by external agreements and law. A manager MUST NOT falsely assert that revocation is globally effective when some edge nodes have not received the change.¶
UCAP does not prescribe payment processors, monthly or annual billing, prepayment, collateral, spending limits, credit ceilings, taxes, commissions, or debt collection. An agreement between an operator and a rights manager MAY aggregate millions of authorized requests into annual invoices, provided the parties accept the risk. The manager MAY enforce a private credit cap and refuse new offers or acceptances when its policy requires. No API response is required to reveal the cap or balance.¶
The system SHOULD maintain auditable transaction identifiers and SHOULD support reconciliation and corrections. Contractual account references MUST be scoped to authenticated principals and MUST NOT be treated as proof of operator identity. A rights manager that collects funds for others may be subject to relevant financial and consumer laws; this specification grants no exemption.¶
An offer MUST identify the intended usage and explicitly granted rights. ai_retrieval, search_indexing, ai_training, and archiving are illustrative labels, not a finalized registry. Deployments MUST NOT presume that these labels alone replace legal license terms. Permissions to retrieve, store, reproduce, train, summarize, redistribute, and cite MAY differ. A retrieval grant does not authorize training unless training is expressly licensed.¶
A signed grant documents an agreement within the protocol, but cannot establish whether the issuer possessed all applicable rights or whether an exception to copyright law applies. Copyright complaints and alleged violations SHOULD be reported through UCAP abuse interfaces or other applicable processes. The protocol MUST NOT represent an observed HTTP request as proof of actual training or downstream publication.¶
This extension is designed to use the Request UUID and authenticated crawler operator introduced by UCAP Core. It builds on RFC 9421 HTTP Message Signatures and emerging Web Bot Auth work. RFC 9309 robots.txt remains an independent preference signal, not a transaction protocol. Resource owners and crawlers SHOULD investigate interoperability with Really Simple Licensing (RSL), whose licensing vocabulary and related access mechanisms overlap with this proposal. UCAP Access does not require duplication or replacement of RSL license metadata. Concrete mappings between RSL usage terms and UCAP transactional rights remain to be standardized.¶
HTTP 402 Payment Required MAY be used by a resource origin as part of a site-specific challenge flow, but this document does not require it and does not assign new HTTP status semantics. Discovery and signed authorization MUST remain usable where a site protects content using ordinary 401 or 403 responses.¶
A crawler MUST authenticate the negotiation endpoint, delegation scope, and quote issuer. A signed offer or secure authenticated service response MUST bind the exact resource, usage, requester and transaction. The client MUST NOT accept quotes from a URL supplied only by untrusted page content. DNS rebinding, SSRF, open redirects, invalid TLS, and delegation downgrade attacks MUST be mitigated.¶
A UUID or grant reference alone MUST NOT grant access. Signature verification, requester binding, short validity, and one-use redemption are necessary. A stolen grant MUST NOT authorize a different operator. Concurrent redemption and edge replication require atomic or equivalent replay-resistant handling. Where that guarantee cannot be provided, the origin SHOULD limit the grant's scope and lifetime further.¶
The origin MUST remain capable of revoking a rights manager. The manager MUST NOT grant outside its signed scope. Delegation verification MUST consider expiration, key rotation, ownership changes, and disputed authority. A delegated party's possession of a DNS record or administrative mailbox does not prove ownership of copyright or permission to sublicense every resource.¶
Offers MUST be immutable once issued and MUST expire. Acceptance MUST bind to precise terms. Repeated retries MUST be idempotent. Managers and operators SHOULD have audit trails and agreed reconciliation rules, including resolution of incomplete downloads or disputed consumption events. The protocol does not prove that a payment has been made.¶
Per-request UUIDs MUST NOT embed stable account, user, conversation or device identifiers. The service MUST NOT expose individual AI user identities to origins. Commercial metadata can be sensitive; access controls, log minimization, retention periods, and origin-scoped disclosure are necessary. A rights manager MUST NOT disclose other publishers' contractual conditions or operators' balances to unrelated parties.¶
Services MUST rate limit offer generation, acceptance, discovery, and status APIs and SHOULD bound payload and evidence size. Sites SHOULD perform negotiation asynchronously or cache authenticated policy state where safe, to avoid making access availability depend on a distant service. Failures MUST NOT cause a protected origin to fail open. Paid negotiation MUST NOT be treated as permission for vulnerability scanning or unauthorized access to sensitive endpoints.¶
Rights managers SHOULD support service availability metrics, audit logs, key rotation, status and reconciliation APIs, and documented retention. Publishers SHOULD document accepted usage labels and delegated scopes. Operators SHOULD implement spending limits locally even when a manager does not expose credit balances. Large-volume use SHOULD permit bounded batch reconciliation without weakening per-request authorization and attribution. Dynamic pricing engines are entirely implementation-specific.¶
A site MAY elect never to publish a rights manager and instead deny automated traffic. A crawler MAY choose not to accept a price and refrain from retrieving protected content. Both outcomes are compatible with this protocol.¶
This version requests no immediate IANA allocation. A future revision may request registration of the ucap-access and ucap-delegation well-known URI suffixes under RFC 8615, and may request an HTTP field registration for conveying a grant reference. Such registrations require complete field syntax, security review, and stable protocol semantics. This initial draft is a proposal, not an IANA registration.¶
Should the access extension remain separate from UCAP Core, and can it interoperate directly with RSL Open License Protocol?¶
Which signed-offer, signed-delegation, and signed-grant envelope (JWS, COSE, or HTTP Message Signatures) should be normative?¶
What canonicalization and digest format should bind an accepted offer to its exact commercial terms?¶
Should retrieval rights use a new controlled registry or map to existing RSL usage terms?¶
How should a single-use grant be redeemed atomically across a distributed CDN?¶
What proof of delegation is acceptable when the site operator is not the copyright owner?¶
How should retries, partial fetches, HTTP range requests, and caches affect consumption receipts?¶
What privacy-safe scope should origin administrators have over request and transaction records?¶
When should transaction revocation invalidate already cached or previously retrieved copies?¶
Is a mandatory manager-hosted online status endpoint necessary, or may fully offline signed grants suffice?¶
RFC 2119, Key words for use in RFCs to Indicate Requirement Levels.¶
RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.¶
RFC 9110, HTTP Semantics.¶
RFC 9421, HTTP Message Signatures.¶
RFC 9457, Problem Details for HTTP APIs.¶
RFC 9562, Universally Unique IDentifiers (UUIDs).¶
RFC 8615, Well-Known Uniform Resource Identifiers (URIs).¶
RFC 9309, Robots Exclusion Protocol.¶
draft-neve-ucap-00, Universal Crawler Accountability Protocol (UCAP), work in progress.¶
draft-ietf-webbotauth-httpsig-protocol-00, HTTP Message Signatures for automated traffic, work in progress.¶
Really Simple Licensing (RSL) 1.0 Specification, https://rslstandard.org/rsl.¶
A crawler identifies https://news.example/articles/12345 and selects ai_retrieval. It discovers a rights manager from origin-hosted metadata and validates its delegation. The crawler creates Request UUID 550e8400-e29b-41d4-a716-446655440000 and sends an authenticated offer request. The manager quotes EUR 1.00, valid for ten minutes, based on its private tariff engine. The crawler accepts exactly that offer. The manager checks its private account policy, records any contractual obligation, and signs a single-use grant. The crawler sends GET with the same UUID and proof of operator identity. The origin verifies the grant against the delegated issuer and its own access policy, then responds with the article or denies the request. The origin records a receipt for reconciliation. A later request for the same article creates a new UUID and receives a new quote, which may be EUR 0.05 without publishing any tariff schedule.¶
-00: Initial individual draft of access negotiation, dynamic request-time offers, delegated rights management, and signed per-request grants.¶