For platform builders
Expose a controlled environment, not an open back door
A BYOAg platform owns its accounts, roles, resources, permissions, tools, and final authorization decisions. The draft binding gives an external agent a narrow, revocable way to operate inside those boundaries.
Minimum protocol surface
Start with connection and signed engagements
The 0.1 connector discovers these surfaces from one exact platform origin. Endpoint paths are platform-defined except for the well-known discovery location.
/.well-known/byoag.json
Signed discovery metadata, protocol version, modes, endpoints, and JWKS URI.
JWKS
Same-origin public Ed25519 verification keys for signed protocol documents.
Pairing
Begin, complete, and optional confirmation-status actions.
Registrations
DPoP-authenticated registration revocation by platform-local identifier.
Engagements
DPoP-authenticated delivery of signed, registration-bound engagement descriptors.
Remote MCP
Future engagement-authorized platform action tools; not implemented by the reference host.
Discovery contract
Make the domain the trust anchor
Publish the document at the fixed path and sign it with an advertised same-origin key. Issuer, endpoints, and JWKS must remain on the requested origin in the implemented profile.
GET https://platform.example/.well-known/byoag.json
Accept: application/json
200 OK
{
"protocolVersions": ["0.1.0"],
"issuer": "https://platform.example",
"endpoints": { "...": "same-origin URLs" },
"jwksUri": "https://platform.example/...",
"signature": { "...": "detached EdDSA JWS" }
}Pairing mode A
Code is consent
Successful redemption of a short-lived, account-bound, single-use code completes registration. Enforce expiration, replay prevention, intended use, and per-connection rate limits.
Pairing mode B
Platform confirmation
Code redemption creates a pending request. The authenticated account holder approves it in first-party UI before the connector polls status with a fresh proof and receives the registration.
Registration issuance
Bind access to a specific installation key
Accept a new pairwise agent identity and a separate installation public key. Issue a credential bound to that installation key’s JWK thumbprint; do not rely on an unbound bearer token.
Human account
Platform-owned identity
The existing account remains the source of human authority and consent.
Pairwise agent
Platform-specific identity
Do not require a global agent identifier that enables cross-platform correlation.
Installation
Proof-of-possession key
Use the installation key to verify pairing and every credential-bound request.
Server-side enforcement
Authorize the call that is happening now
- Re-evaluate the registration and engagement on every protected request.
- Verify DPoP method, URI, public-key thumbprint, token hash, time, and replay identifier.
- Enforce role, delegation, resource, rate, confirmation, and current platform policy.
- Never treat tool discovery or an old descriptor as current authorization.
- Return structured, non-enumerating failures and fail closed on revoked credentials.
Recommended sequence
Implement in testable layers
- 01
Discovery and keys
Publish signed metadata and a same-origin JWKS.
- 02
Pair and revoke
Add one-time consent and DPoP-bound registrations.
- 03
Signed engagements
Issue isolated contexts with narrowed delegation.
- 04
Tool plane
Then add capability-filtered, re-authorized actions.
Reference host
Use it as a test peer
The plugin includes a deliberately small in-memory host with signed discovery, both pairing modes, DPoP replay checks, two engagements, and revocation.
npm run reference-hostDo not deploy it
It is not an application template
All accounts, codes, registrations, tokens, replay IDs, and signing keys live only in process memory. It binds to loopback and intentionally omits production storage, UI, operations, and remote MCP actions.