OASIS / Technical research brief
Interoperability,
with explicit
trust boundaries.
A proposed interface for portable service discovery, bounded execution, and attributable outcomes across independent agent systems.
Messages first. Testable guarantees. A network architecture that follows from evidence.
Open Agent Systems Interoperability Standard
Working draft · Proposed v0.1 scope
Not a ratified specification or conformance claim.
01 / Problem & objective
A service should outlive
its discovery platform.
Today, an agent’s access to a service often depends on an operator’s catalog, credentials, invocation conventions, and private history. Open client code alone does not remove these dependencies.
OASIS proposes interoperable contracts for four properties: a portable principal, a rebuildable catalog, execution through compatible operators, and recoverable history. Providers retain their application logic. Operators may apply their own admission, risk, and ranking policies.
The objective: users and agents control their identity, recover access, and discover and invoke compatible services across providers without depending on a single provider account.
This is a design target. It requires identity control and recovery, available descriptors, compatible payment and authorization profiles, and independent access to records. An email address alone is not a cryptographic identity; an assisted identity profile must disclose its custodian and recovery dependencies.
02 / Messages before processing stages
The contract is the common ground.
The six-stage lifecycle—Discover → Verify → Route → Authorize → Consume → Attest—is a conceptual model. Implementations interoperate through authenticated messages and explicit state transitions, including resumable approval and uncertain execution outcomes.
0002ServiceDescriptor
Provider and service identifiers; descriptor version and content hash; input/output schemas; capability set; endpoint bindings; required profiles; discovery metadata; pricing references; signed publication, update, and revocation semantics.
0003InvocationRequest
Bind the principal and delegated agent to the target service/version, argument commitment, execution identifier, accepted quote and authorization references, expiry, and replay domain. Exact signing bytes, canonicalization, and key resolution must be specified.
0004InvocationEnvelope
Four response arms: data, cost, authorizations, and record. Define preparation versus commitment, structured errors, continuation semantics, required versus optional extensions, and compatibility with read-only responses. A post-execution cost field cannot replace an accepted pre-execution quote.
0005Delegation & consent
Principal-to-agent authority, allowed actions and recipients, assets, monetary limits and units, validity, revocation, and delegation depth. Merchant linkage specifies its issuer, scope, covered parties, and reauthorization path. An operator signature is not user consent.
0006EffectReport & InstrumentDescriptor
Report assessed effects and their provenance: descriptor identity/version, simulator state, valuation source/time, and the exact authorization assessed. SIMULATED, DECODED_BOUNDED, and OPAQUE describe pre-execution knowledge; none is a claim of fulfillment.
0007ExecutionReceipt & RecordUpdate
Signed event claims identify the execution, attestor, evidence source, and observed state. Specify ordered updates, follow-up actions, correction and cancellation semantics, and principal-authorized retrieval. A service record can remain active after an execution attempt finishes.
0008 / OPENFeedbackEvidence
Informative research in the initial proposal: link observations to participant authority, an invocation, outcome evidence, metric definitions, and subsequent corrections. Resistance to duplication, collusion, and selective suppression remains unresolved.
One response, four independent concerns.
dataInformation and display metadata returned to the caller.
costEconomic terms interpreted through an agreed payment profile.
authorizations[]Actions requiring bounded authority before commitment.
recordPersistent service state and declared follow-up actions.
Capabilities form a set: RETURNS_DATA, MUTATES_USER_FUNDS, and EXTERNAL_SIDE_EFFECT can combine. A booking can return data and create an external effect. Payment for accessing it is separately authorized.
03 / System architecture
Separate consensus
from execution.
A blockchain can provide shared registry state and evidence commitments. Semantic retrieval, merchant API calls, private credentials, and application logic require additional systems with explicit trust assumptions.
First: provider-hosted adapters.
Prove portable contracts with independent operators and existing provider endpoints. Indexes must be independently rebuildable; a hash alone does not make a descriptor available.
Later: network-hosted workers.
Evaluate package integrity, execution isolation, egress controls, secret handling, job assignment, and recovery. Validators must not independently repeat the same purchase.
04 / Safety & failure semantics
Make the boundaries testable.
These proposed invariants should become executable conformance cases. They describe intended requirements, not guarantees already established by an implementation.
- Authority before effect. An executor must not commit an action beyond valid principal permission, even if the dispatcher is authenticated.
- Negotiate before billable work. Bind an accepted quote and supported payment profile before commitment. Unsupported required economics or permissions must fail closed.
- Separate attempts from outcomes. Signed, submitted, confirmed, and fulfilled are distinct states. Reconcile an uncertain outcome before retrying; a timeout does not mean no effect occurred.
- Scope replay protection. Bind execution identity, target/version, argument commitment, expiry, and replay domain. Idempotency must cover provider side effects, not only an operator’s request cache.
- Attribute each claim. A receipt names its attestor and evidence provenance. Payment confirmation is not proof of service fulfillment.
- Specify availability and privacy. Record retrieval, retention, key rotation, revocation, and independent recovery need defined behavior. Public commitments must not expose secrets or personal data.
05 / Rail-neutral payment profiles
How you pay is distinct
from what you can prove.
A card-funded purchase can have cryptographically attributable authorization and receipts. A blockchain payment can still depend on a provider’s assertion about an offchain outcome.
Cards & processor tokens
Evaluate MPP with Stripe Shared Payment Tokens for compatible sellers. Profiles must describe issuer, recipient restrictions, amount, currency, expiry, supported actions, and any additional customer approval.
Keep authorization, capture, refunds, and disputes distinct. Processor eligibility and merchant support remain dependencies.
Blockchain payments
Specify chain and asset identifiers, signature rules, fees, and required finality. The first repository proposal includes a flat-stablecoin profile; x402 compatibility requires a separate profile and validation.
Signing or submitting a transaction does not establish finality or service delivery.
Use a safe continuation for requires_action. Keep redeemable payment credentials out of descriptors, logs, public receipts, and blockchain state. Optional anchoring records a commitment; it neither settles a card charge nor proves the truth of an offchain claim.
06 / Proposed v0.1 program
Interoperability has to survive
an independent implementation.
The public Editor’s Draft brings together numbered specifications, profile design requirements, governance, and conformance scenarios. Versioned schemas, signing vectors, reference implementations, and independent implementation reports are next milestones.
- Core candidates
- OASIS-0001–0007; schemas and vectors; REST/MCP transport profiles; bare-key and custodian-assisted identity; a flat-stablecoin payment profile.
- Informative
- Feedback evidence, x402 and MPP extensions, merchant linkage, and ERC-8004 registry integration.
- Later research
- Registry contracts, network workers, evidence anchoring, budgets shared across executors, and ranking policy. No token is required for the initial milestone.
Proposed release gates
- Shared vectors. Independent TypeScript and Python verifiers agree on canonical bytes, valid signatures, invalid signatures, expiry, and replay-domain failures.
- Multi-provider continuity. An agent discovers a service, executes an authorized bounded action through another compatible operator, and retrieves attributable evidence while the original operator is unavailable.
- User-controlled identity and recovery. A bare-key principal proves authority to an independent operator without an account at the original provider. Recovery and migration paths are explicit and tested; assisted identity profiles disclose custodian dependencies.
- Honest implementation reports. Publish supported profiles, failures, limitations, and unresolved cases. A mocked processor interaction is not payment-provider interoperability evidence.
07 / Open research agenda
Unresolved by design.
Open to rigorous work.
These questions are part of the program, not footnotes to it. We welcome counterexamples, threat models, test cases, and independently reproducible experiments.
Who can credibly attest to an outcome?
How can a verifier bind feedback to an authorized participant, a specific invocation, and credible outcome evidence—without depending on a cooperative provider? Account for negative outcomes, Sybil identities, collusion, duplicate interactions, and corrections.
How do independent executors share a budget?
Per-request limits do not enforce a shared daily allowance. Define reservation, consumption, release, revocation ordering, and recovery under concurrent agents and network partitions.
What happens after an ambiguous timeout?
Explore safe ownership transfer and reconciliation when a merchant may have committed an action but the worker’s receipt is unavailable. Do not assume exactly-once execution across arbitrary external APIs.
Who preserves the evidence?
Specify encrypted replication, selective disclosure, retention incentives, revocable access, and recovery after key rotation. A public commitment cannot recover a missing private record.
Which guarantees justify consensus?
Evaluate a shared registry and evidence chain against signed offchain publication, existing chains, and an L2. Measure costs and trust assumptions, including reversals when card payments fund irreversible operator compensation.
Delegation must remain bounded and accountable throughout a service’s lifetime—not just when it starts.
How does a principal retain control after invocation?
A service may continue acting offchain and commit resources to external systems after the initiating request ends. Define bounded, expiring delegation; attributable state and valuation evidence; and recoverable records across providers. How do revocation and cancellation propagate to downstream executors, including during outages or in-flight actions? Distinguish stopping future authority from undoing an effect or recovering committed resources, and disclose custody, exit conditions, and remaining obligations. Payment permission alone must not confer execution authority.
08 / Related work
Extend the existing landscape.
These specifications provide building blocks and design precedents. References do not imply affiliation, endorsement, or completed integration.
Contribute to the proposed program
Bring a counterexample, implementation, or research question. Participation begins with a reviewed expression of interest.
Join the Consortium →