Skip to main content

Overview

An agent acts for real people, but to most sites it looks like any other bot. It gets blocked, sent through guest checkout, or asked for a password it shouldn’t hold. Sites have no way to know who it acts for. Key challenges for agent builders:
  • Proving to a site that a verified person is behind the agent
  • Doing that without handing the agent the person’s passwords
  • Sharing only what each site needs, and nothing more
  • Cutting off an agent fast if its key is compromised or something changes
With KYA, Baselayer verifies the person once. When their agent needs to identify itself to a site, the platform’s backend asks Baselayer to mint a short-lived credential for that site.
  • Each credential works at one site and only with the agent key it was issued for.
  • The platform can revoke a credential at any time, and sites refuse it in near-real time.
  • The credential carries identity, not spending authority or payment details.

Choosing a credential level

The same person receives the same ID at one site across agents, keys, sessions and levels. A different site receives a different ID. L2 shares only that ID. L3 can also include verification results and available fields listed in the site’s KYA profile.

How it works

1

Verify the person once

The platform sends the person through Hosted Enrollment, a Baselayer-hosted flow in the platform’s brand. They enter their phone number, date of birth and country, type the code Baselayer texts them, and confirm their details. They enter their details on Baselayer’s page instead of the platform’s forms.A platform that already collected the person’s details can send them through the API instead. Either way, the result is a stable individual_ref.See Hosted Enrollment and Verifying an Identity.
2

Create a key for the agent

Each agent generates and holds an Ed25519 key pair. The private key stays with the agent and is never sent to the platform or Baselayer. The platform sends only the public key when it asks Baselayer to mint a credential.
3

Find out what the site needs

The agent requests a protected page. The site answers 401 with a KYA-Disclosure-Scope header. The agent reads the site’s /.well-known/kya-profile.json to see the exact fields that scope may read.
4

Get a nonce

The agent calls the site’s POST /nonces and gets a single-use nonce and the site’s audience.
5

Mint a credential for that site

The platform’s backend calls Baselayer with its API key, the site’s audience, the agent’s public key, a credential level and the fields the site’s scope lists. Minting always runs on the backend, never in the agent, so the agent never holds the API key.See Minting Credentials.
6

Present it

The agent signs the site’s nonce and audience with its private key, then presents the credential to the site. If the site accepts it, the site returns its own access token. See Presenting a Credential for the full exchange.
The platform can list credentials Baselayer minted for it, look up a credential by ID, and revoke one before it expires. See Managing and Revoking Credentials and Audit Log.

What each party sees

Next steps