bhamlett@gmail.com

Applications and Real-Time Network Working Group agents B2B integration organizational identity access agreements Connecting one organization's systems to another's usually requires a connector built for that pair of systems, whether written by hand, bought from a connector catalog, or packaged as a tool server for an AI model. Connectors scale with the number of pairs, carry long-lived shared credentials, and have no verifiable link to the legal entities involved or to the terms under which access was granted. This document describes that problem and an architecture, called Selo, that aims to reduce the need for such connectors. Agents owned by verified legal entities verify each other, negotiate a typed access agreement that both parties sign, and then execute it through a standard runtime and a gateway in front of each entity's existing API, using credentials bound to the agreement. Each entity maintains its own tested, signed mapping between its system and shared capability profiles. Selo uses existing APIs; it does not replace them. The document states requirements and an architecture to inform discussion of whether, and where, such work belongs in the IETF. It does not specify a protocol. About This Document This is an individual submission. Discussion is invited on the dispatch@ietf.org mailing list, and at a side meeting at IETF 127 on Monday 16 November 2026, 17:30-19:00 (US Pacific time), in room Continental 7. The author has a pending patent application relating to this document. An IPR disclosure will be filed in accordance with BCP 79.

Introduction Most business software exposes an API. Accounting, enterprise resource planning (ERP), commerce, banking, payroll and logistics systems all let authorized callers read and write their records. What is missing is not the API but the connection between two organizations' APIs: something has to decide who may call what, under which terms, translate between two data models, hold the credentials, and keep working as both sides change. Today that is a connector, built for a pair of platforms, configured for a pair of organizations, and operated by one of them or by a third party. Tool servers that expose a platform's API to an AI model, such as Model Context Protocol servers, are a newer form of connector. AI agents make it plausible for software to read an API description and propose how two systems should exchange data. They do not, on their own, make that safe: an agent that can be steered by text from a counterparty cannot be trusted to grant access or sign commitments. Selo is an architecture in which:

• each organization (an "entity") has a verified identity anchored to its legal identifier, and certifies its own agents;
• agents verify each other and disclose endpoints and terms on a need-to-know basis;
• agents negotiate a typed access agreement, but only an isolated, deterministic policy checker acting under the owner's signed mandate can cause a signature;
• each entity's runtime tests the agreement end to end, then executes it through a gateway in front of the existing API, using short-lived credentials bound to the agreement and to the caller's key; and
• each entity translates once, between its own system and shared capability profiles, using a mapping it has tested and signed, so that no executable artifact specific to a pair of parties is needed.

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.

suggests venues for the remaining pieces.

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 () and are left for future work.

Terminology

Entity:

An organization that can be legally accountable for an agreement.

Provider and consumer:

Under an access agreement, the provider is the entity whose capabilities are accessed; the consumer obtains access. An entity can be both.

Platform:

A system of record used by an entity, exposing a platform API. The platform vendor is not a party to agreements.

Owner and operator:

The owner of an agent, runtime or mapping is the entity on whose behalf it acts. An operator runs these components for an owner and may be the owner itself.

Issuer and trust list:

An issuer verifies an entity and signs its entity certificate. A trust list, maintained under a trust framework, lists accepted issuers.

Agent:

Software representing its owner in the control plane: verification, catalog disclosure and negotiation. An agent may use a machine-learning model.

Mandate:

A data object signed by the owner that sets the limits within which an agent's proposals may be signed.

Policy checker:

A component, isolated from the agent's model and containing no machine-learning model, that compares typed proposals with the mandate and alone can cause the owner's signature on an agreement.

Access agreement:

Canonical structured data, signed by both parties, listing the endpoints the consumer may use and the typed terms that apply. It is also the configuration the parties' runtimes load and enforce.

Agreement record:

A signed agreement version plus an append-only, hash-linked sequence of signed annex entries (test confirmations, suspensions, mapping-update notices and similar). Adding an annex entry does not create a new version.

Capability profile:

A versioned definition of a business capability (such as orders, invoices or general-ledger transactions): schema, field semantics, field classes (such as money-bearing), invariants, operations and a conformance test suite.

Mapping:

Expressions in a sandboxed, deterministic transformation language that translate records between one entity's platform and a profile. A mapping is tested and signed by that entity.

Runtime and gateway:

The runtime executes signed agreements. The gateway is the part of a provider's runtime in front of its platform API, through which every call under an agreement passes.

Category and sensitivity label:

A category is a named group of endpoints in a provider's catalog. The provider gives each category a sensitivity label from an ordered set, for example Public < Customer < Confidential < Restricted.

Problem Statement

Connectors scale with pairs.

A connector embodies knowledge of two systems and of an arrangement between two organizations. Costs grow with the number of pairs. Shared connector libraries lower the cost of building one, but each shared connector is a supply-chain target for every deployment that uses it and cannot know any one organization's custom fields, codes and workflows, so each deployment still needs per-customer configuration. Canonical data models (EDI, UBL and the canonical models of integration platforms) have long tried to reduce this; in practice, the per-organization configuration around them is where integrations drift and break.

Agents lack accountable identity.

Existing agent and workload identity work identifies software and endpoints. A counterparty deciding whether to grant access to financial records needs to know which legal entity stands behind an agent, who verified that and when. Names and domains are not identifiers; lookalikes are a common basis for fraud.

An agent's authority is hard to rely on.

An organization needs to limit what its agent can commit to and require human approval above those limits. Its counterparty needs to rely on a commitment having been within the agent's authority, without learning the internal limits, which would weaken the organization's negotiating position.

Access is disconnected from its terms.

Terms such as purpose, retention, rate, data location and termination are usually recorded, if at all, separately from the credentials and configuration that grant access. Nothing ensures the two match, or that a change to either is noticed by the other party.

Model-mediated integration creates new risks.

An agent that reads a counterparty's catalog or messages can be steered by instructions embedded in them (prompt injection). No reliable model-level defense is known, so any key, approval or write operation reachable by the model is effectively reachable by the counterparty. A model-generated translation can differ between runs and produce plausible but wrong values. An integration that was tested is not necessarily the integration that runs.

Payment-instruction fraud.

Changing a supplier's bank details through a compromised or impersonated channel is a well-known form of business payment fraud. Automating buyer-supplier relationships must not make this easier.

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 ().

Requirements These requirements are stated as outcomes a solution needs to achieve, not as normative protocol requirements.

R1:

An entity's identity needs to be anchored to a legal identifier (such as a Legal Entity Identifier), so that it survives a change of issuer.

R2:

Every agent needs to be bound to the entity that owns it and, where different, to its operator.

R3:

It needs to be possible to require identities that no single issuer can create on its own.

R4:

Issuance, key changes and revocations need to be publicly auditable, while relationships and agreements between entities are not published.

R5:

A stolen key needs to be recoverable without loss of identity, and agent credentials need to be short-lived.

R6:

A provider needs to be able to disclose each category of endpoints only to approved requesters, and to make unapproved categories indistinguishable from nonexistent ones.

R7:

The system's guarantees must not depend on the behavior of any machine-learning model: no signature or grant of access can result from a model's output except through deterministic checks against limits signed by the owner.

R8:

Owners need to be able to require approval by an authorized, identifiable person above limits they set, with requests not approved in time treated as declined.

R9:

A counterparty needs to be able to rely on an attributable assertion that a commitment was within the other party's authority, checkable after the fact in an audit or dispute, without learning the limits of that authority.

R10:

Agreement terms need to be typed, with defined meanings and units. No legal language is generated during negotiation; agreements reference fixed legal text by digest.

R11:

Negotiation transcripts and agreement versions need to be tamper-evident, attributable, and protected against replay and downgrade.

R12:

A change of payment details needs approval by a person with a finance role, a waiting period, notice to the paying side's people by a path independent of either agent, and confirmation by a person on the paying side before the first payment.

R13:

Production data must not flow under an agreement until it has been signed by both parties and tested end to end.

R14:

The provider's platform credentials are never disclosed to the consumer; credentials issued to the consumer are bound to the agreement and to a key the consumer holds.

R15:

Every call needs to be checked against the agreement's endpoints, operations, fields and enforceable terms; terms that cannot be enforced technically need to be recorded so compliance can be shown.

R16:

The translation executed at run time needs to be deterministic, sandboxed and byte-for-byte the one that was tested and signed. No model transforms data or grants access at run time.

R17:

No executable artifact specific to a pair of parties should be needed, and a defective mapping should affect only agreements to which its owner is a party.

R18:

The protocol needs to work over plain HTTPS, be independent of transport, use agile algorithms, and reuse existing certificate, credential, transparency, token and business-document standards where possible.

Architecture Overview

Components

Components | 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.

Identity and Keys An issuer verifies an entity and signs its entity certificate, a restricted certificate-authority certificate 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 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 or to a SCITT transparency service ; 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 . The trust framework () defines assurance levels. One level is expected to require verification by two independent issuers, so that no single issuer can create it (R3).

Discovery and Mutual Verification An entity publishes a discovery document at /.well-known/selo on a domain listed in its entity certificate, optionally with a DNS record (for example SVCB ) or a DAWN mechanism . 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.

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.

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.

Policy Checker Outcomes | 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.

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 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.

Negotiation States 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.

The Access Agreement An access agreement is a JSON object canonicalized with . Each party signs the canonical bytes with a detached signature (JWS or COSE ) 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.

Agreement Lifecycle

Agreement Lifecycle 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 (). Disputes are resolved by the parties, using the signed records.

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 or mutual TLS , 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 server generated from the agreement's interface, limited to operations within the agreement.

Capability Profiles and Entity-Owned Mappings Capability profiles build on existing business-document standards such as UBL , ISO 20022 and XBRL Global Ledger . Operations no profile covers are described as custom endpoints in 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 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.

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.

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.

Relationship to Existing Work Most building blocks of Selo already exist or are being developed elsewhere. This section summarizes the closest work.

IETF Working Groups

OAuth:

Data-plane tokens use DPoP or mutual TLS . Rich Authorization Requests carry typed grants, Token Exchange addresses delegation, and Transaction Tokens carry context within a trust domain. An agreement-bound token is expected to be an OAuth profile.

GNAP:

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

WIMSE:

WIMSE addresses workload and agent identity. states requirements for delegation across organizations, and proposes verifiable mandates for agents acting across administrative domains, with limits evaluated by the relying party.

DAWN, agentproto and AUDIT:

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

SCITT and RATS:

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

Individual Drafts on Agent Identity, Mandates and Negotiation

AGTP family:

AGTP defines an agent transfer protocol, with companion drafts on trust and verification , 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 . This substantially overlaps Selo's entity-to-agent binding (R1, R2). AGTP does not define bilateral agreements or their execution.

Mandates:

, (mandates for invoice agents, with approval thresholds) and (a mandate JWT) define signed agent mandates. In these, the limits are generally visible to the party evaluating them.

Negotiation and agreement evidence:

defines signed offer, counter and accept messages with undisclosed internal limits. defines countersigned evidence of a negotiated outcome, excluding legal identity and terms.

Agent identity and naming:

defines agent passports, delegation receipts and a transparency log. defines a domain-anchored agent name service with assurance tiers.

Work Outside the IETF

Eclipse Dataspace Protocol:

The Dataspace Protocol defines catalogs, a contract-negotiation state machine and a transfer process between participants in data spaces, with usage policies in 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 provides organizational identity and role credentials through qualified issuers, and is a candidate trust anchor. OpenID Federation provides trust chains and entity statements suited to trust lists.

UMA and sector consent frameworks:

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

A2A and MCP:

A2A is a candidate binding. 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 and Peppol show that canonical documents and secure exchange between organizations work at scale under governance, and that per-organization configuration remains the hard part.

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.

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.

Questions for the Community

1. Is the problem worth solving at the IETF, and is the proposed core in the right scope?
2. Should the agreement and negotiation build on the Eclipse Dataspace Protocol, GNAP or another existing design rather than be defined anew?
3. Which existing credential, mandate, transparency and token formats should be profiled, and where are new definitions unavoidable?
4. How should the work coordinate with OAuth, WIMSE, DAWN, agentproto, AUDIT and SCITT?

Security Considerations Verified identifiers solve attribution but do not on their own prevent abuse: identities can be cheap, legitimate identities are compromised, and model-based agents read the other side's input. The main threats considered so far, with the architectural response:

Prompt injection:

typed messages validated before any model sees them, quarantined free text, and a policy checker that signs only proposals passing deterministic checks against the signed mandate.

Compromised agent with many relationships:

short-lived agent keys, narrow agreements and gateway-enforced volume ceilings.

Policy checker or operator compromise:

isolation, entity-signed mandates, decision logs, and owners certifying their own keys so an operator cannot mint new identities.

Shell companies and lookalikes:

assurance levels per sensitivity label, issuance-log monitoring and the invitation route.

Issuer compromise:

public logging of issuance and revocation, and assurance levels requiring two independent issuers.

Key theft:

short-lived agent keys and rotation only to a pre-committed next entity key.

Reconnaissance and price fishing:

no catalog before mutual verification, hidden categories, and limits on price disclosure.

Malicious or faulty mapping:

entity-owned, sandboxed, conformance-tested, pinned mappings with human-confirmed money fields.

Replay, downgrade and token theft:

hash-chained signed transcripts, nonces, signed hello messages, and short-lived key-bound tokens checked against agreement status on every call.

Data misuse within an agreement:

purpose and training restrictions are recorded as terms and made demonstrable through logs; enforcement is legal.

Operators and gateways concentrate many owners' platform credentials and are high-value targets. Discovery, status and log services are targets for denial of service.

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.

Privacy Considerations Following the threat categories of :

Surveillance and correlation:

The issuance log never records relationships or agreements. However, per-agent certificate entries, their timing and the operators named in them can reveal how many agents an entity runs and hint at when relationships start or end; status queries can reveal who is checking whom. Logging granularity and status-checking methods need further work.

Identification and disclosure:

Entity facts beyond the public certificate are disclosed selectively, one claim at a time, at a counterparty's request. Counterparties with leverage could demand more than they need; purpose-limited disclosure requests need further work.

Secondary use:

Purpose, retention and model-training terms are typed and recorded; mandates are disclosed only in audit or dispute.

Stored-data compromise:

Call logs record metadata, not record contents. Transcripts, decision logs and approvals identify people (approvers) and need retention limits.

Third-party data subjects:

The records flowing under an agreement often concern people who are not parties, such as employees or customers. Agreements need typed terms for processing roles and data-protection obligations, and testing should use synthetic data where possible.

Individuals as parties are out of scope for this version. Publishing their certificates in an append-only public log would conflict with erasure rights, so a design for individuals would need a different approach. An operator hosting agents for several owners should keep each owner's offers, limits and terms isolated.

IANA Considerations This document has no IANA actions. A protocol specification developed from it would be expected to register the well-known URI suffix "selo" and to establish registries for message types, typed access terms and algorithm suites.

Informative References IETF IETF IETF Eclipse Foundation W3C Kantara Initiative OpenID Foundation OpenID Foundation Financial Data Exchange, Inc. A2A Project Model Context Protocol Project OASIS ISO XBRL International OpenAPI Initiative JSONata Project OpenPeppol AISBL Global Legal Entity Identifier Foundation

Illustrative Data Objects These objects are illustrative only; field names and values are examples, not proposed formats. Identifiers use an "example:" prefix, and some digests are elided.

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.

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.

Acknowledgments The author thanks the authors of the work cited in , on which this document builds.