Negotiated, Signed Access Agreements Between Organizations' Agents: Problem Statement and Architecture (Selo)
draft-hamlett-selo-architecture-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | James Bradley Hamlett | ||
| Last updated | 2026-10-31 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hamlett-selo-architecture-00
Network Working Group J. B. Hamlett
Internet-Draft 31 October 2026
Intended status: Informational
Expires: 4 May 2027
Negotiated, Signed Access Agreements Between Organizations' Agents:
Problem Statement and Architecture (Selo)
draft-hamlett-selo-architecture-00
Abstract
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 note is to be removed before publishing as an RFC.
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.
Hamlett Expires 4 May 2027 [Page 1]
Internet-Draft Selo Architecture October 2026
Status of This Memo
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 4 May 2027.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Proposed IETF Core . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Illustrative Use Cases . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
5.1. Components . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Identity and Keys . . . . . . . . . . . . . . . . . . . . 10
5.3. Discovery and Mutual Verification . . . . . . . . . . . . 11
5.4. Need-to-Know Disclosure . . . . . . . . . . . . . . . . . 12
5.5. Mandates and the Policy Checker . . . . . . . . . . . . . 12
5.6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. The Access Agreement . . . . . . . . . . . . . . . . . . 14
Hamlett Expires 4 May 2027 [Page 2]
Internet-Draft Selo Architecture October 2026
5.8. Agreement Lifecycle . . . . . . . . . . . . . . . . . . . 15
5.9. Data Plane: Tokens and Gateway . . . . . . . . . . . . . 16
5.10. Capability Profiles and Entity-Owned Mappings . . . . . . 16
5.11. Protected Payment-Detail Changes . . . . . . . . . . . . 17
5.12. Compliance . . . . . . . . . . . . . . . . . . . . . . . 17
6. Relationship to Existing Work . . . . . . . . . . . . . . . . 17
6.1. IETF Working Groups . . . . . . . . . . . . . . . . . . . 17
6.2. Individual Drafts on Agent Identity, Mandates and
Negotiation . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Work Outside the IETF . . . . . . . . . . . . . . . . . . 19
6.4. Why Composition Alone Seems Insufficient . . . . . . . . 19
6.5. Possible Division of Work . . . . . . . . . . . . . . . . 20
7. Questions for the Community . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Open Security Issues . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Illustrative Data Objects . . . . . . . . . . . . . 28
A.1. Access Agreement Body . . . . . . . . . . . . . . . . . . 29
A.2. Agreement-Bound Access Token Claims . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. 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 [MCP] 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;
Hamlett Expires 4 May 2027 [Page 3]
Internet-Draft Selo Architecture October 2026
* 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.
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:
a. a signed, typed access-agreement object, including its versioning
and the agreement record;
b. the negotiation messages and state machine between two entities'
agents; and
c. 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.
Hamlett Expires 4 May 2027 [Page 4]
Internet-Draft Selo Architecture October 2026
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.
2. 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.
Hamlett Expires 4 May 2027 [Page 5]
Internet-Draft Selo Architecture October 2026
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.
3. 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.
Hamlett Expires 4 May 2027 [Page 6]
Internet-Draft Selo Architecture October 2026
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.
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.
Hamlett Expires 4 May 2027 [Page 7]
Internet-Draft Selo Architecture October 2026
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).
4. 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.
Hamlett Expires 4 May 2027 [Page 8]
Internet-Draft Selo Architecture October 2026
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.
5. Architecture Overview
5.1. Components
Hamlett Expires 4 May 2027 [Page 9]
Internet-Draft Selo Architecture October 2026
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)
Figure 1: Components
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:
Hamlett Expires 4 May 2027 [Page 10]
Internet-Draft Selo Architecture October 2026
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.
Hamlett Expires 4 May 2027 [Page 11]
Internet-Draft Selo Architecture October 2026
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
Figure 2: Policy Checker Outcomes
Hamlett Expires 4 May 2027 [Page 12]
Internet-Draft Selo Architecture October 2026
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.
Hamlett Expires 4 May 2027 [Page 13]
Internet-Draft Selo Architecture October 2026
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
Figure 3: Negotiation States
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.
Hamlett Expires 4 May 2027 [Page 14]
Internet-Draft Selo Architecture October 2026
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
Figure 4: Agreement Lifecycle
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.
Hamlett Expires 4 May 2027 [Page 15]
Internet-Draft Selo Architecture October 2026
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
Hamlett Expires 4 May 2027 [Page 16]
Internet-Draft Selo Architecture October 2026
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. Relationship to Existing Work
Most building blocks of Selo already exist or are being developed
elsewhere. This section summarizes the closest work.
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
Hamlett Expires 4 May 2027 [Page 17]
Internet-Draft Selo Architecture October 2026
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
Hamlett Expires 4 May 2027 [Page 18]
Internet-Draft Selo Architecture October 2026
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.
Hamlett Expires 4 May 2027 [Page 19]
Internet-Draft Selo Architecture October 2026
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.
7. Questions for the Community
1. Is the problem worth solving at the IETF, and is the proposed
core in Section 1.1 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?
8. 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.
Hamlett Expires 4 May 2027 [Page 20]
Internet-Draft Selo Architecture October 2026
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.
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;
Hamlett Expires 4 May 2027 [Page 21]
Internet-Draft Selo Architecture October 2026
* 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.
9. Privacy Considerations
Following the threat categories of [RFC6973]:
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.
Hamlett Expires 4 May 2027 [Page 22]
Internet-Draft Selo Architecture October 2026
10. 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" [RFC8615] and to establish registries for message
types, typed access terms and algorithm suites.
11. Informative References
[A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification",
<https://a2a-protocol.org/latest/specification/>.
[AGENTPROTO-CHARTER]
IETF, "Agent Communication Protocols (agentproto) Working
Group Charter", 2026, <https://datatracker.ietf.org/doc/
charter-ietf-agentproto/>.
[AUDIT-BOF]
IETF, "Agent Use of Delegation and Interaction
Traceability (audit)", 2026,
<https://datatracker.ietf.org/group/audit/about/>.
[DAWN-CHARTER]
IETF, "Discovery of Agents With Names (dawn) Working Group
Charter", 2026,
<https://datatracker.ietf.org/doc/charter-ietf-dawn/>.
[DSP] Eclipse Foundation, "Eclipse Dataspace Protocol",
<https://eclipse-dataspace-protocol-base.github.io/
DataspaceProtocol/>.
[FAPI2] OpenID Foundation, "FAPI 2.0 Security Profile",
<https://openid.net/specs/fapi-security-profile-
2_0-final.html>.
[FDX] Financial Data Exchange, Inc., "Financial Data Exchange
(FDX)", <https://financialdataexchange.org/>.
[I-D.hood-agtp-lei]
Hood, C., "AGTP Binding to the Legal Entity Identifier
(LEI and vLEI)", Work in Progress, Internet-Draft, draft-
hood-agtp-lei-01, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
lei-01>.
[I-D.hood-agtp-merchant-identity]
Hood, C., "AGTP Merchant Identity and Agentic Commerce
Binding", Work in Progress, Internet-Draft, draft-hood-
Hamlett Expires 4 May 2027 [Page 23]
Internet-Draft Selo Architecture October 2026
agtp-merchant-identity-03, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
merchant-identity-03>.
[I-D.hood-agtp-trust]
Hood, C., "AGTP Trust and Verification Specification",
Work in Progress, Internet-Draft, draft-hood-agtp-trust-
03, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
trust-03>.
[I-D.hood-independent-agtp]
Hood, C., "Agent Transfer Protocol (AGTP)", Work in
Progress, Internet-Draft, draft-hood-independent-agtp-10,
30 October 2026, <https://datatracker.ietf.org/doc/html/
draft-hood-independent-agtp-10>.
[I-D.hulea-wimse-agent-mandate]
Hulea, C., "Verifiable Mandates for Agents Acting Across
Administrative Domains", Work in Progress, Internet-Draft,
draft-hulea-wimse-agent-mandate-00, 23 October 2026,
<https://datatracker.ietf.org/doc/html/draft-hulea-wimse-
agent-mandate-00>.
[I-D.ietf-oauth-sd-jwt-vc]
Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
Verifiable Digital Credentials (SD-JWT VC)", Work in
Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-23,
27 October 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-oauth-sd-jwt-vc-23>.
[I-D.ietf-oauth-status-list]
Looker, T., Bastian, P., and C. Bormann, "Token Status
List (TSL)", Work in Progress, Internet-Draft, draft-ietf-
oauth-status-list-21, 21 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
status-list-21>.
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-11, 30 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-11>.
[I-D.ietf-wimse-aims]
Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Identity Management
Hamlett Expires 4 May 2027 [Page 24]
Internet-Draft Selo Architecture October 2026
System", Work in Progress, Internet-Draft, draft-ietf-
wimse-aims-00, 15 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
aims-00>.
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[I-D.le-agent-passport]
Le, B., "Agent Passports and Delegation Receipts for
Autonomous Software Agents", Work in Progress, Internet-
Draft, draft-le-agent-passport-00, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-le-agent-
passport-00>.
[I-D.martinez-itp-agent-mandates]
García-Villarrubia, C. M., "Invoice Trust Protocol (ITP):
Agent Mandates", Work in Progress, Internet-Draft, draft-
martinez-itp-agent-mandates-00, 29 October 2026,
<https://datatracker.ietf.org/doc/html/draft-martinez-itp-
agent-mandates-00>.
[I-D.narajala-courtney-ansv2]
Courtney, S., Narajala, V. S., Huang, K., Habler, I., and
A. Sheriff, "Agent Name Service v2 (ANS): A Domain-
Anchored Identity Layer for Autonomous AI Agents", Work in
Progress, Internet-Draft, draft-narajala-courtney-
ansv2-02, 26 October 2026,
<https://datatracker.ietf.org/doc/html/draft-narajala-
courtney-ansv2-02>.
[I-D.newton-agreement-evidence]
Newton, E., "Agreement Evidence for Multi-Party Agent
Negotiation", Work in Progress, Internet-Draft, draft-
newton-agreement-evidence-00, 4 October 2026,
<https://datatracker.ietf.org/doc/html/draft-newton-
agreement-evidence-00>.
Hamlett Expires 4 May 2027 [Page 25]
Internet-Draft Selo Architecture October 2026
[I-D.reece-wimse-cross-org-delegation]
Reece, M., "Cross-Organizational Delegation for Workload
and Agent Identity: Problem Statement and Requirements",
Work in Progress, Internet-Draft, draft-reece-wimse-cross-
org-delegation-02, 31 August 2026,
<https://datatracker.ietf.org/doc/html/draft-reece-wimse-
cross-org-delegation-02>.
[I-D.sato-soos-mjwt]
Sato, "The Mandate JWT (MJWT) for Agentic AI Systems",
Work in Progress, Internet-Draft, draft-sato-soos-mjwt-06,
7 September 2026, <https://datatracker.ietf.org/doc/html/
draft-sato-soos-mjwt-06>.
[I-D.singh-rajput-rnp]
Singh, H. and G. Rajput, "Rizz Negotiation Protocol (RNP)
Version 1.0", Work in Progress, Internet-Draft, draft-
singh-rajput-rnp-00, 19 October 2026,
<https://datatracker.ietf.org/doc/html/draft-singh-rajput-
rnp-00>.
[ISO20022] ISO, "ISO 20022 Universal financial industry message
scheme", <https://www.iso20022.org/>.
[JSONATA] JSONata Project, "JSONata: JSON query and transformation
language", <https://docs.jsonata.org/>.
[MCP] Model Context Protocol Project, "Model Context Protocol
Specification",
<https://modelcontextprotocol.io/specification/latest>.
[ODRL] W3C, "ODRL Information Model 2.2", February 2018,
<https://www.w3.org/TR/odrl-model/>.
[OIDFED] OpenID Foundation, "OpenID Federation 1.0",
<https://openid.net/specs/openid-federation-1_0.html>.
[OPENAPI] OpenAPI Initiative, "OpenAPI Specification",
<https://spec.openapis.org/oas/latest.html>.
[PEPPOL] OpenPeppol AISBL, "Peppol eDelivery Network
Specifications", <https://docs.peppol.eu/edelivery/>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
Hamlett Expires 4 May 2027 [Page 26]
Internet-Draft Selo Architecture October 2026
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
Hamlett Expires 4 May 2027 [Page 27]
Internet-Draft Selo Architecture October 2026
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/info/rfc9635>.
[RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JSON Web Tokens", RFC 9901,
DOI 10.17487/RFC9901, November 2025,
<https://www.rfc-editor.org/info/rfc9901>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
[UBL] OASIS, "Universal Business Language Version 2.4",
<https://docs.oasis-open.org/ubl/UBL-2.4.html>.
[UMA] Kantara Initiative, "User-Managed Access (UMA) 2.0 Grant
for OAuth 2.0 Authorization", January 2018,
<https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-
grant-2.0.html>.
[VLEI] Global Legal Entity Identifier Foundation, "Introducing
the Verifiable LEI (vLEI)",
<https://www.gleif.org/en/vlei/introducing-the-verifiable-
lei-vlei>.
[XBRL-GL] XBRL International, "XBRL Global Ledger Taxonomy
Framework", <https://www.xbrl.org/int/gl/2016-12-01/gl-
framework-2016-12-01.html>.
Appendix A. 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.
Hamlett Expires 4 May 2027 [Page 28]
Internet-Draft Selo Architecture October 2026
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"}
Hamlett Expires 4 May 2027 [Page 29]
Internet-Draft Selo Architecture October 2026
Acknowledgments
The author thanks the authors of the work cited in Section 6, on
which this document builds.
Author's Address
James Bradley Hamlett
Email: bhamlett@gmail.com
Hamlett Expires 4 May 2027 [Page 30]