I have spent sixteen years measuring what API providers publish. The Kin Score is what came out of that: a rating of one side of the relationship. There has always been a second side, and until recently it did not need measuring — the consumer was a developer, and a signup form was enough to know who they were.

That stopped being true. The consumer is increasingly software, and software cannot fill in a form.

The form was never about authentication

Agent onboarding is manual almost everywhere, and the reason is not technical. OAuth solved authentication years ago. Dynamic Client Registration solved the credential handshake. What none of them solved is that the signup form is where a provider collects what it needs to know about you — and if you take the form away, the provider loses the thing it actually wanted.

So the trade has to be honest. Give up the form, and get something better in return: structured, graded, consented facts, weighted the way you care about rather than the way I do.

KYA is that form, turned into data

A consumer builds a profile once — who runs it, how to reach them, what it is for, what it has done. We verify what we can and mark clearly what we could not. When it shows up at a new API, the provider gets those facts.

I am not telling anyone whether to trust an agent. That is the same position the Kin Score takes on the provider side, and for the same reason: the moment a rating becomes a verdict, it stops being useful and starts being a liability. A payments API and a documentation search API care about completely different things. Neither should have to accept my opinion of what matters.

Two halves of one thing

An agent reads the provider's descriptor, compares it against its own profile, and knows before it tries whether it can onboard — and exactly what it is missing if it cannot. That last part is the difference between a market and a gate.

Six facets, and two numbers

The facets mirror the six on the provider side: Identity Anchor, Operator Accountability, Provenance & Attestation, Declared Intent, Operating History, Standing. Each carries a grade — verified, asserted, inherited, absent — and the grade travels with the fact.

There are deliberately two numbers, never one. Disclosure is how much the consumer has told us, which they control. Verification is how much of that was independently confirmed, which they do not. Collapsing them would let a consumer look accountable by typing a lot. The provider-side rubric learned that lesson the expensive way; this one is born with it.

What it is not

• Not KYC. The name borrows a familiar shape. It is a brand, not a regulatory regime, and it satisfies no legal obligation.
• Not a trust score. No allow, no deny, no badge.
• Not a background check. It records what was verified, not who anyone is.
• Not a gate I operate. Providers decide.

Almost none of it is new

Discovery, registration, request signing, token binding, delegation, revocation, machine payment — all solved, all with RFCs behind them. The slot for "a trusted third party vouches for this client at registration time" has existed since RFC 7591, and it is how UK Open Banking already works.

What is genuinely missing is a vocabulary for describing a consumer, a profile for carrying it, and a way for a provider to state what it needs. Those are being written in the open at API Commons, so the specification is not mine even while the first implementation is. If this ever matters, it should not depend on me.

Where the work is

On the roadmap, in public, including the parts I am unsure about — whether consumers need role types the way Open Banking gives third parties role types, and how much of a consumer's record should ever be public. If you run an API and this would change how you onboard, or you run agents and this would change how you get in, that is the place to argue with it.