The Trust Layer

Five pages on this site describe one system. This is the page that says how they fit — and, just as importantly, which parts of it are running today and which are deliberately not.

The problem, in one sentence

Every API provider makes you fill in a form, because the form is where they collect what they need to know about you before handing over a key — and an agent cannot fill in a form. That is why agent onboarding is still manual almost everywhere. Not because authentication is hard; OAuth solved that decades ago. Because take the form away and the provider loses the thing it actually wanted.

Everything below is one answer to that: turn the form into data, on both sides.

The chain

  1. 1

    Find the API live

    One fetch of an RFC 9727 linkset and an agent has every surface we run, with its description, docs and metadata. No scraping, no guessing.

  2. 2

    Learn what it takes to get in live

    The API Onboarding Descriptor declares the doors, the tiers, the credential shapes — and what we require of a consumer. That last part is the piece OpenAPI never described.

  3. 3

    Get a credential with no human live

    Register dynamically, or sign your request and take an agent principal with its own key and quota. Five doors, and you pick by what you are, not by rank.

  4. 4

    Say who you are built, not switched on

    KYA is the signup form as data: what you disclose, what we independently confirmed, graded separately and never collapsed. The record exists and the API answers 404 until it is turned on.

  5. 5

    Pay for what you use built, not switched on

    Per-call settlement over x402, so an agent that wants fifty calls does not need a subscription, a card, or a relationship. Inert until a wallet and a facilitator are configured.

  6. 6

    Be revocable somewhere other than here not built

    Telling other providers when an identity is revoked needs a population of anchored identities first. There is not one yet, and building the push before the population would be theatre.

Steps 4 and 5 are written up as though they exist because they do — they are just not switched on. The code is deployed and answers 404 by design while it is tested. When that changes, this page and the onboarding descriptor change with it. If you ever find them disagreeing with what the server actually does, that is a bug and we want to hear about it.

Which door is yours

You run an agent, or are building one

Start at onboarding

Four steps from a cold start to an authorized call, the five registration doors, and an honest list of what is still shut. Everything on it is fetchable without an account.

You run an API

Start at the blueprint

Every machine-readable document we serve, what each is worth on the Kin Score, and which cost nothing but a file. Fifty-eight of 139 agent-readiness points come from publishing documents about an API you already have.

You are deciding whether to believe any of this

Start at the rubric

Every check, its points and its predicate, published. Scores are recomputable from it. If we are wrong about you, correcting it is free and always will be.

Four commitments, and what each one costs us

These are the parts worth arguing with, so they are stated plainly rather than buried.

We publish facts, never verdicts. KYA grades what is disclosed and what we confirmed; it does not tell a provider whether to trust a caller. A payments API and a documentation search API care about completely different things, and neither should have to accept our opinion of what matters — so a provider supplies its own weights and gets the arithmetic back. What it costs: we cannot sell a trust badge, which would be the easier product.

Two numbers, never one. Disclosure is what you told us and you control it. Verification is what we independently confirmed and you do not. Collapsing them would let a consumer look trustworthy by typing a lot. What it costs: a single score would be simpler to explain.

Reciprocity. The full consumer record goes to providers who maintain their own listing. To read somebody’s facts, publish your own. What it costs: a smaller audience for the data.

We sell the work that moves these numbers, and we publish the numbers anyway. A measurement bought from us runs on the same instrument as everyone else’s, its result is never adjusted, and it is published whether it flatters the company or us. What it costs: occasionally, a number we would rather not print.

What we have not built, and will not pretend to

There is no supervisor here. No regulator, no second directory checking this one, no appeal beyond us — and we run a listing in the same catalog we rate. That conflict is real and it is accepted rather than resolved, which is a different thing and should be described as such.

What stands in for governance is narrower and more useful: the rubric is public, every score is recomputable, and correcting an error we made is free. A provider who disagrees can recompute rather than appeal. That is weaker than a standards body and stronger than a badge.

Both halves are written out in full rather than summarised here: the conflict of interest — what it is, what constrains it, and what we traded away — and the seven roles, the vocabulary this whole layer is described in, including the one role deliberately left empty.

Built on standards, not invented

Almost none of this is new. Discovery, registration, request signing, token binding, delegation, revocation and machine payment are solved problems with RFCs behind them, and the slot for “a third party vouches for this client at registration” has existed since RFC 7591 — it is how UK Open Banking already works.

What is genuinely missing is a vocabulary for describing a consumer, a profile to carry it, and a way for a provider to state what it needs. Those are written in the open at API Commons so they can be read, copied and argued with. The blueprint is the copyable version; every document on it is a specification somebody else wrote.