Skip to main content
Once a consumer or business identity is verified, you can securely delegate it to an agent using short-lived, cryptographically signed credentials. A credential is minted on demand and is scoped to one counterparty and agent, so that a stolen credential is useless without the agent’s private key, and so is a stolen merchant session.

​
Before you start

You need a principal_ref (or business_ref) in CURRENT state (see Verifying an Identity), and an Ed25519 keypair the presenting agent generates on its own hardware. Baselayer only ever sees the public JWK.

​
Credential parameters

​
Mint an individual credential

POST /credentials/individual — mints for a verified person as a consumer.
  • L2 — an audience-scoped pairwise DID (“same customer returning”), discloses nothing else. Stable for the same person and audience even across different agent keys. The same customer gets the same ID at that merchant every time, across agents, sessions, and re-verification. At a different merchant, they get an unrelated ID, so merchants cannot pool IDs to track a customer across sites.
  • L3 — discloses exactly the fields you request under the user. prefix (name, email, phone, address, DOB, SSN, residency — see the API Reference for the full attribute list). Logging in a returning customer receives a verified email hash. Age-gated sites receive birth year. Account opening receives name, DOB, the last four digits of SSN, and address. A field outside the vault schema is a 422; a field that is unpopulated for that identity is silently omitted.

​
Mint a business operator credential

POST /credentials/business — the individual mint body plus business_ref. Requires a VERIFIED link between the person and that business; anything short of VERIFIED is a 409. L3 disclosure paths split across business.* (the business’s own attested fields) and actor.user.* (the authorized person’s fields).

​
Mint a counterparty credential

POST /credentials/counterparty — a domain-bound business attestation a merchant hosts at its own /.well-known/baselayer-counterparty-credential, so arriving agents can verify the business behind the site. No agent key, no disclosure selection — every claim is public-record fact, and the domain must match the business’s verified website domain.

​
Selective disclosure modes

  • CLEARTEXT_AND_HASH (default) — each requested leaf is disclosed as cleartext and its family’s recognition hash, so a counterparty can both read the value and recognize the same person later.
  • HASH_ONLY — no cleartext crosses the wire; each leaf collapses to its family’s hash (name.* → name.full_hash, email.* → email.hash, etc.). Families with no hash (dob, residency) drop entirely rather than leaking a matchable identifier.
For exactly how the credential is signed and how a counterparty checks it for tampering, see the Credential Format Reference.

​
Troubleshooting