Negotiated, Signed Access Agreements Between Organizations' Agents: Problem Statement and Architecture (Selo)

1.1. The Proposed IETF Core

Much of this architecture profiles existing work or belongs outside the IETF. The parts that appear to need new, interoperable definitions, and that the author proposes for discussion, are:¶

1. a signed, typed access-agreement object, including its versioning and the agreement record;¶
2. the negotiation messages and state machine between two entities' agents; and¶
3. a profile of OAuth access tokens bound to an agreement and to the caller's key, enforced at the provider's gateway.¶

Section 6.5 suggests venues for the remaining pieces.¶

1.2. Scope

Selo aims to reduce the need for manually built connectors and per-platform tool servers. Every operation is still performed by an entity's existing platform API. Selo does not move money; payments are executed by existing payment systems. Searching for counterparties is a marketplace function and is out of scope.¶

Issuer accreditation, verification procedures (for example know-your-business checks and their renewal), the trust list, assurance-tier definitions, approval workflows and user interfaces, and compliance-framework identifiers are expected to be governed by one or more external trust frameworks. This document defines only the hooks the protocol needs from them: an assurance level in the entity certificate, verifiable claims in an entity credential, and references to approvals and role credentials in agreements.¶

This version covers organizations only. Individuals as parties raise distinct privacy questions (Section 9) and are left for future work.¶

3.1. Illustrative Use Cases

Ledger access for an accounting firm:

A company invites its accounting firm. The firm's agent requests hourly read access to general-ledger transactions with unlimited retention; the company's agent counter-offers daily access, 365-day retention and no use for model training; a finance officer approves because the data is Confidential; the runtimes test the exchange; and the firm then pulls entries daily. When the company's ERP is upgraded, the company re-tests and re-signs its own mapping without renegotiating.¶

Ordering from a supplier:

A customer's agent finds a supplier by domain. The supplier's policy discloses ordering and invoicing endpoints to verified existing customers. The agents agree payment terms within each side's mandate, and orders then flow as individual calls. A later change of the supplier's bank details follows a protected process (Section 5.11).¶

5.1. Components

        Entity A                              Entity B
 +---------------------+               +---------------------+
 | Agent (may use a    |<-- control -->| Agent (may use a    |
 | model)              |    plane      | model)              |
 |   | typed proposals |               |   | typed proposals |
 |   v                 |               |   v                 |
 | Policy checker      |               | Policy checker      |
 | (isolated, no model;|               | (isolated, no model;|
 | key + mandate)      |               | key + mandate)      |
 |   | signs           |               |   | signs           |
 |   v                 |               |   v                 |
 | Runtime + gateway   |<--- data  --->| Runtime + gateway   |
 | (pinned mapping,    |     plane     | (pinned mapping,    |
 | owner credentials)  |               | owner credentials)  |
 |   v                 |               |   v                 |
 | Platform API        |               | Platform API        |
 +---------------------+               +---------------------+

 Supporting services: issuers and trust list; public issuance log
 (certificates, keys, revocations; never relationships); registries
 (capability profiles, typed terms, algorithm suites)

Negotiation happens when an agreement is formed or changed, not per call; individual transactions flow through the data plane under the agreement. The agent is owned by the entity that uses the platform, not by the platform's vendor. A vendor or integration service may run components as an operator for its customers, who remain the owners.¶

5.2. Identity and Keys

An issuer verifies an entity and signs its entity certificate, a restricted certificate-authority certificate [RFC5280] with a path-length constraint of zero and name constraints limiting it to the entity's own namespace and its verified domains. The entity certificate carries the legal identifier, an assurance level and those domains. The entity key is held in protected hardware or a cloud key service and is used rarely, to certify the entity's other keys and to sign mandates and role credentials. Facts beyond the certificate (officers, verification dates, screening status, attestations) can be carried in a selective-disclosure credential such as an SD-JWT VC [RFC9901] [I-D.ietf-oauth-sd-jwt-vc] and revealed one claim at a time.¶

Keys are separated by role, each certified by the entity certificate:¶

Agent key:

Short-lived (for example days, renewed automatically). Signs control-plane messages. Held by the agent's non-model code; the model never invokes it directly.¶

Checker signing key:

Reachable only by the policy checker. Signs agreements on the entity's behalf.¶

Runtime or gateway key:

Signs runtime messages such as test confirmations and suspensions, and is the key to which data-plane tokens are bound.¶

An entity commits in advance to its next entity key by publishing a digest of it, and rotation is accepted only to the committed key, so a thief of the current key cannot take over the identity. Every certificate issued, key change and revocation is submitted to a public append-only log modeled on Certificate Transparency [RFC9162] or to a SCITT transparency service [RFC9943]; monitors alert an entity to issuance under its legal identifier. The log never records relationships or agreements. Revocation status is published promptly, for example in status lists [I-D.ietf-oauth-status-list].¶

The trust framework (Section 1.2) defines assurance levels. One level is expected to require verification by two independent issuers, so that no single issuer can create it (R3).¶

5.3. Discovery and Mutual Verification

An entity publishes a discovery document at /.well-known/selo [RFC8615] on a domain listed in its entity certificate, optionally with a DNS record (for example SVCB [RFC9460]) or a DAWN mechanism [DAWN-CHARTER]. The document contains only the entity identifier, agent addresses, certificate chains, supported versions and algorithm suites, and is signed by a key certified by the entity certificate. A relying party checks that the domain it fetched from is one of the certified domains. An entity can also send a counterparty a signed invitation naming it by legal identifier.¶

Before revealing anything beyond the discovery document, each agent checks the other's certificate chain to an issuer on its trust list, revocation status, log inclusion, any operator authorization, and the assurance level its owner requires. Only then is a catalog exchanged, tailored to the requester.¶

5.4. Need-to-Know Disclosure

A requester becomes approved for a category by invitation, by a typed access request approved by a person holding a covering role credential, or automatically under a deterministic rule in the provider's signed mandate (for example "verified existing customers may use Customer categories"). Per category, the provider sets whether an invitation alone suffices. Categories a requester is not approved for are omitted from its catalog, and a request naming one receives a response indistinguishable from one naming a nonexistent category, because the existence of sensitive endpoints is itself sensitive. Approval interfaces are expected to help approvers notice lookalike identities; how they do so is left to implementations and trust frameworks.¶

5.5. Mandates and the Policy Checker

The owner gives each agent a signed mandate containing access limits per sensitivity label, commercial limits, the most generous terms the agent may offer, and requirements to obtain from counterparties. The agent's model negotiates and composes typed proposals. Each proposal crosses an isolation boundary to the policy checker, which contains no model and evaluates each typed field against the mandate by fixed rules. Values the mandate does not cover default to refusal or escalation, never approval.¶

  Agent (model) --typed proposal--> | isolation | --> Policy checker
                                                        |
        +------------------------+----------------------+
        |                        |                      |
   within mandate          outside, escalatable     not permitted
        |                        |                      |
   sign, with a            approver with covering   refuse
   within-mandate          role credential;
   reference               counterparty gets
                           "pending"; no answer by
                           deadline = declined

Every decision is recorded in a signed decision log. The counterparty learns only that a commitment was within mandate (or approved by a named, entitled person), through a within-mandate reference that identifies the mandate version and decision and binds to the mandate without revealing it; the mandate is disclosed only in an audit or dispute (R9). A provider also needs to avoid committing, across all its agreements, more platform capacity (such as request rates) than its platform account supports; how it does so is an implementation matter.¶

5.6. Negotiation

Messages are transport independent and follow the steps of contract formation:¶

• session and disclosure: hello, catalog-request, catalog, access-request;¶
• negotiation: offer, counter-offer, accept, reject, withdraw;¶
• status and completion: pending, sign, error;¶
• existing agreements: renegotiate, terminate; and¶
• execution support: test-confirm, suspend, resume, notice.¶

A plain-HTTPS binding is required. Each message is a signed object, so its signature is independent of the binding; optional bindings carry the same objects over agent-to-agent protocols such as A2A [A2A] or agentproto protocols.¶

All fields are typed. Every inbound message is validated against its schema by deterministic code before any content reaches a model, and non-conforming messages are rejected. Free text is confined to one optional field marked untrusted, shown to people and either withheld from the model or given only to a quarantined model with no tools or keys.¶

Each message includes the digest of the preceding message in the session, forming a hash chain, plus a timestamp and nonce. The protocol version and algorithm suite are selected by a fixed rule (for example, the responder's most preferred entry in the intersection) from the signed hello messages, which are part of the chain, so stripping options from one hello is detected.¶

 START --hello/hello--> VERIFIED --catalog--> CATALOG
 CATALOG --access-request--> ACCESS_PENDING
 ACCESS_PENDING --approved--> CATALOG (category now visible)
 ACCESS_PENDING --denied or timeout--> CLOSED
 CATALOG --offer--> NEGOTIATING (one live offer; each expires)
 NEGOTIATING --escalation--> PENDING_APPROVAL
 PENDING_APPROVAL --approved--> NEGOTIATING
 PENDING_APPROVAL --declined or timeout--> CLOSED
 NEGOTIATING --accept (digest of offer)--> ACCEPTED
 ACCEPTED --sign/sign (each via its checker)--> SIGNED
 SIGNED --> TESTING (agreement lifecycle)

 Any state: reject, withdraw, expiry, error, failed check --> CLOSED

An accept names the digest of the exact offer accepted, and the agreement is derived from that offer by a fixed rule. Nothing is binding, and no runtime loads an agreement, until both signatures verify. Offer expiries and approval deadlines are carried as typed values in the messages.¶

5.7. The Access Agreement

An access agreement is a JSON object canonicalized with [RFC8785]. Each party signs the canonical bytes with a detached signature (JWS [RFC7515] or COSE [RFC9052]) made with its checker signing key; each signature carries, as a signed attribute, that party's within-mandate reference and any approval references. The signatures are therefore not part of the body they sign. The body contains:¶

Parties:

Both entity identifiers, their agents, any operators, each party's runtime key or certificate (the anchor for token binding and runtime message verification), and, where commercial terms exist, payment-change notification endpoints.¶

Interface:

Endpoints (profile or custom operations), which side calls which, pull or push, formats and profile versions.¶

Access terms:

Typed values from a registry of terms, each with a type, unit, direction of generosity and a flag saying whether a runtime can enforce it: for example requests per minute, records per day, retention, permitted purposes, use for model training, data location and termination notice.¶

Commercial terms (optional):

For example payment terms, currency and protected payment details.¶

Legal terms:

A reference to fixed legal text by address and digest, plus the typed choices it leaves open (such as governing law or liability cap). The text may be a master agreement the parties already have.¶

Metadata:

Format version, agreement identifier, version number, digest of the previous version, digest of the accept message that concluded negotiation, and digest of the rendering template.¶

A human-readable rendering is produced from the canonical data by fixed, versioned rules, not by a model, so any party can regenerate it. The contracting parties are the entities, not their agents: replacing an agent does not affect agreements. Changing any term, endpoint or party requires a new signed version that includes the previous version's digest. Annex entries, such as test confirmations, suspensions and mapping-update notices, are appended to the agreement record without a new version, and the parties periodically countersign the latest annex digest.¶

5.8. Agreement Lifecycle

 SIGNED --> TESTING --both confirm--> ACTIVE
 TESTING --fail or timeout--> CLOSED
 ACTIVE --suspend--> SUSPENDED (some endpoints or all)
 SUSPENDED --cause fixed, re-test passes--> ACTIVE
 ACTIVE --renegotiate--> new version signed and tested
        --> new version ACTIVE, old version SUPERSEDED
 ACTIVE or SUSPENDED --terminate--> TERMINATED

After both signatures, the agreement enters TESTING. The provider issues test-scoped credentials that its gateway honors only against a test data source, such as a platform sandbox, a validate-only mode or synthetic records. The runtimes exchange sample records through every endpoint and mapping and validate them against the profile schema and invariants. Each runtime signs a test-confirm annex entry listing endpoints exercised and digests of the profile-format sample records and of its own mappings. Only when both confirmations are recorded does the agreement become ACTIVE and production credentials exist.¶

Runtimes refuse to operate outside the signed agreement. A failure affecting some endpoints, such as mapping output that violates the profile or an expired attestation, suspends only those endpoints; an endpoint resumes after the cause is fixed and its test passes again, without renegotiation. A platform API change usually requires only that the affected owner update its own mapping (Section 5.10). Disputes are resolved by the parties, using the signed records.¶

5.9. Data Plane: Tokens and Gateway

On activation, the provider issues the consumer short-lived OAuth access tokens identifying the agreement and version and bound, by a confirmation claim using DPoP [RFC9449] or mutual TLS [RFC8705], to the consumer runtime key named in the agreement. Tokens are refreshed at a token endpoint that checks agreement status. The provider's platform credentials stay in a vault used only by its gateway.¶

On every call, the gateway validates the token and proof of possession; checks that the agreement version is ACTIVE (or TESTING for a test token), that the endpoint is not suspended and that neither party is revoked; checks the endpoint and operation against the interface; removes fields outside the agreement; enforces rate, volume and time limits; executes the owner's pinned mapping and calls the platform API; and appends an entry to a signed, hash-chained private log of call metadata (not record contents). These logs make terms that cannot be enforced technically, such as purpose restrictions, demonstrable. Models may be used at run time for monitoring only.¶

An active agreement can also be exposed to the consumer's own AI assistant as tools, for example an MCP [MCP] server generated from the agreement's interface, limited to operations within the agreement.¶

5.10. Capability Profiles and Entity-Owned Mappings

Capability profiles build on existing business-document standards such as UBL [UBL], ISO 20022 [ISO20022] and XBRL Global Ledger [XBRL-GL]. Operations no profile covers are described as custom endpoints in OpenAPI [OPENAPI], with a field mapping confirmed by both parties in negotiation.¶

Each entity translates once, between its own platform as configured and each profile it uses. Its mapping is written in a sandboxed, deterministic language (for example JSONata [JSONATA] with no network, file, clock or random access, bounded execution and exact decimal arithmetic for money); passes the profile's conformance tests against the owner's platform; has its money-bearing fields confirmed by a person; and is signed and pinned by digest, so the bytes executed are the bytes tested. This document places no requirement on how a mapping is produced. There is no shared adapter library, so a defective mapping affects only its owner's agreements. When an owner changes its own mapping, it re-tests and re-signs it and records a signed mapping-update notice in the agreement record; the affected endpoints are re-tested, and no new agreement version is needed.¶

5.11. Protected Payment-Detail Changes

Payment details are a protected part of the commercial terms. A change needs a new agreement version approved by a person holding a finance role (an agent's mandate alone never suffices); direct notice to the paying side's people at notification endpoints in the agreement, by a path that bypasses both agents; a waiting period (for example 72 hours) during which the previous details remain in effect and either side can cancel; and confirmation by a person on the paying side before the first payment to the new details. Selo moves no money; payment approval rules can be agreement terms consumed by existing payment systems.¶

5.12. Compliance

No compliance framework is built into the protocol. Attestations can be presented as credentials; requirements can be typed terms that a mandate attaches to a sensitivity label; if a required attestation lapses, only the dependent endpoints are suspended. The signed transcripts, agreement records, decision logs and call logs are verifiable offline, and implementations may offer them as evidence for audits.¶

6.1. IETF Working Groups

OAuth:

Data-plane tokens use DPoP [RFC9449] or mutual TLS [RFC8705]. Rich Authorization Requests [RFC9396] carry typed grants, Token Exchange [RFC8693] addresses delegation, and Transaction Tokens [I-D.ietf-oauth-transaction-tokens] carry context within a trust domain. An agreement-bound token is expected to be an OAuth profile.¶

GNAP:

GNAP [RFC9635] negotiates an access grant between a client and an authorization server. Selo's agreement could be expressed as, or alongside, a grant.¶

WIMSE:

WIMSE [I-D.ietf-wimse-arch] [I-D.ietf-wimse-aims] addresses workload and agent identity. [I-D.reece-wimse-cross-org-delegation] states requirements for delegation across organizations, and [I-D.hulea-wimse-agent-mandate] proposes verifiable mandates for agents acting across administrative domains, with limits evaluated by the relying party.¶

DAWN, agentproto and AUDIT:

DAWN [DAWN-CHARTER] covers minimal agent discovery, which Selo's discovery should reuse. agentproto [AGENTPROTO-CHARTER] covers agent dialog protocols, over which Selo messages could be carried. AUDIT [AUDIT-BOF] concerns traceability of delegation and interactions; Selo's transcripts and decision logs are relevant inputs.¶

SCITT and RATS:

A SCITT transparency service [RFC9943] is a candidate issuance log. Remote attestation [RFC9334] could let a counterparty or an owner verify that a policy checker runs isolated and unmodified.¶

6.2. Individual Drafts on Agent Identity, Mandates and Negotiation

AGTP family:

AGTP [I-D.hood-independent-agtp] defines an agent transfer protocol, with companion drafts on trust and verification [I-D.hood-agtp-trust], merchant identity [I-D.hood-agtp-merchant-identity], and binding agents to legal entities through the LEI and vLEI, including role credentials that express the human authorization chain behind an agent [I-D.hood-agtp-lei]. This substantially overlaps Selo's entity-to-agent binding (R1, R2). AGTP does not define bilateral agreements or their execution.¶

Mandates:

[I-D.hulea-wimse-agent-mandate], [I-D.martinez-itp-agent-mandates] (mandates for invoice agents, with approval thresholds) and [I-D.sato-soos-mjwt] (a mandate JWT) define signed agent mandates. In these, the limits are generally visible to the party evaluating them.¶

Negotiation and agreement evidence:

[I-D.singh-rajput-rnp] defines signed offer, counter and accept messages with undisclosed internal limits. [I-D.newton-agreement-evidence] defines countersigned evidence of a negotiated outcome, excluding legal identity and terms.¶

Agent identity and naming:

[I-D.le-agent-passport] defines agent passports, delegation receipts and a transparency log. [I-D.narajala-courtney-ansv2] defines a domain-anchored agent name service with assurance tiers.¶

6.3. Work Outside the IETF

Eclipse Dataspace Protocol:

The Dataspace Protocol [DSP] defines catalogs, a contract-negotiation state machine and a transfer process between participants in data spaces, with usage policies in ODRL [ODRL]. It is the closest existing design to Selo's control plane and should be evaluated as a base.¶

vLEI and OpenID Federation:

The verifiable LEI [VLEI] provides organizational identity and role credentials through qualified issuers, and is a candidate trust anchor. OpenID Federation [OIDFED] provides trust chains and entity statements suited to trust lists.¶

UMA and sector consent frameworks:

UMA 2.0 [UMA] lets a resource owner set policies for third-party access. Open banking and FDX [FDX], with the FAPI security profile [FAPI2], already provide typed consent, revocation, accredited-recipient directories and conformance testing within the financial sector, under sector governance.¶

A2A and MCP:

A2A [A2A] is a candidate binding. MCP [MCP] connects a model to tools; an active agreement can be exposed to the consumer's assistant as MCP tools.¶

Business-document networks:

EDI, UBL [UBL] and Peppol [PEPPOL] show that canonical documents and secure exchange between organizations work at scale under governance, and that per-organization configuration remains the hard part.¶

6.4. Why Composition Alone Seems Insufficient

One could assemble a vLEI role chain, a mandate draft, a RAR or GNAP grant, DPoP, a SCITT log and sector-style consent. The author believes four properties are still missing:¶

1. The agreement is bilateral and binds the consumer too. An OAuth or GNAP grant records one side's authorization decision; there is no common object for the consumer's obligations, such as retention, purpose and no model training, signed by both entities.¶
2. Each party's limits stay hidden from the counterparty, while its commitments remain attributable and auditable.¶
3. Execution is tied to the tested, signed artifact: production credentials exist only for an agreement version tested end to end through the exact mappings that will run.¶
4. Either side can change its own mapping, for example after a platform upgrade, without renegotiating, while the change is still recorded, re-tested and visible to the counterparty.¶

6.5. Possible Division of Work

If the community agrees the problem is worth pursuing, one possible split is: the agreement object and negotiation messages as new work (venue to be determined through DISPATCH, possibly agentproto); agreement-bound tokens as an OAuth profile; mandate representation coordinated with WIMSE; discovery through DAWN; issuance logging through SCITT; and issuer accreditation, trust lists, capability profiles and conformance tests in an external trust framework.¶

8.1. Open Security Issues

The following issues are known and not yet resolved by this architecture:¶

• payment details carried inside data-plane records (for example a payee account in an invoice) could bypass the protected payment-change process;¶
• an attacker could redirect the payment-change notification endpoints before changing payment details;¶
• material signed with a key before its compromise was detected (certificates, mandates, invitations, agreements) is not yet invalidated by any defined mechanism;¶
• sensitivity labels are chosen by the provider, which matters when the consumer's own data flows to the provider;¶
• which keys may sign invitations, and their lifetime and reuse, are undefined;¶
• how the consumer runtime key is first authenticated at the token endpoint (token bootstrap) is undefined; and¶
• whether relying parties and gateways fail open or closed when revocation or agreement status cannot be obtained is undefined.¶

A.1. Access Agreement Body

The body below is canonicalized and signed by each party with a detached signature; the signatures and within-mandate references are not part of it.¶

{"format":"1.0","agreement_id":"agr-5f2e","version":1,
 "prev_version":null,
 "parties":{
   "provider":{"entity":"example:ent:acme-supply",
               "agent":"example:agent:acme-supply:a1",
               "runtime_key_jkt":"5d1c..."},
   "consumer":{"entity":"example:ent:ledgerly",
               "agent":"example:agent:ledgerly:k2",
               "runtime_key_jkt":
                 "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"}},
 "interface":[{"id":"e1","category":"finance.ledger",
               "profile":"gl-transactions/1.2","op":"read",
               "caller":"consumer","direction":"pull",
               "format":"application/json"}],
 "access":{"requests_per_minute":30,"max_records_per_day":20000,
           "retention_days":365,
           "purposes":["bookkeeping","tax-preparation"],
           "ai_training":false,"data_location":"US",
           "termination_notice_days":30},
 "commercial":null,
 "legal":{"uri":"https://terms.example.org/data-access/2.0",
          "digest":"sha256:c0ff...",
          "choices":{"governing_law":"US-DE",
                     "liability_cap":{"amount":"50000.00",
                                      "currency":"USD"}}},
 "accept_digest":"sha256:ab12...",
 "render_template":"sha256:7d00..."}

A.2. Agreement-Bound Access Token Claims

Issued at 2026-11-12T17:30:00Z, after both test confirmations were recorded at 17:20:00Z; valid for one hour.¶

{"iss":"https://gw.acme-supply.example",
 "sub":"example:ent:ledgerly",
 "aud":"https://gw.acme-supply.example/p/gl",
 "agreement":"agr-5f2e","agreement_version":1,
 "agreement_digest":"sha256:9b44...","scope":"e1:read",
 "cnf":{"jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"},
 "iat":1794504600,"exp":1794508200,"jti":"t-71c2"}