Standard trust_v1

The text on this page is fixed for trust_v1. It is not updated, corrected or re-worded once a proof has been issued under it. A change to what a proof states, to what is signed, or to how long it lasts is a new standard version with its own page at its own address, and this page keeps saying what it says today for as long as any proof issued under trust_v1 could still be presented.

That is the whole point of the address being in the signed payload. If this page could change, reading it would tell you what we say now rather than what the proof in your hand says.

This record states that, on the dates given, the company named was present on the Companies House register and its register status passed the issuer's check, and that the person controlling the Agentry account for this company passed an identity check. It does not establish that those are the same person, or that the person is an officer of the company. The checks were performed by the issuer for the subject's own use, are valid only until the expiry date carried in this record, and are not refreshed after issue. This record is:

• not a statement about creditworthiness or solvency (no financial information was collected)
• not an audit
• not a guarantee
• not evidence the issuer is authorised or regulated
• not customer due diligence under MLR 2017
• not confirmation that the person who passed the identity check is an officer of the company
• not a current statement
• not transferable
• This proof carries an `env` claim stating the environment that issued it. Where `env` is `sandbox` this is a test artefact: the checks it names may not have been performed against any register or any person, and it is not evidence of anything about the company it names.

Those 9 lines are part of what is signed. A proof whose signature verifies but whose limits text differs from the text above is refused by the verifier outright, rather than accepted with a warning.

company_register

Establishes: the company number given was present on the Companies House register on the date in asAt, and its register status passed the issuer's check on that date.

Does not establish: anything about the company's finances, its conduct, or its standing on any later date, including today.

On a proof with env of live this check carries source of companies_house; on a proof with env of sandbox it carries sandbox_fixture.

account_controller_identity

Establishes: the person who controls the Agentry account for that company passed an identity check on the date in asAt.

Does not establish: that this person is an officer of the company, or that they are the same person as anyone named on the register.

On a proof with env of live this check carries source of stripe_identity; on a proof with env of sandbox it carries sandbox_fixture.

Each check also carries a result, which is only ever passed because no proof is issued for any other status; an asAt instant, which is when the check was performed and is the date every statement above is anchored to; and an evidenceBasis, which under trust_v1 is always performed_by_issuer.

The payload carries exactly these 13 keys, in this order, no more and no fewer. A payload with a key added, a key missing, or a key holding the wrong type is not a proof under this standard, whatever its signature says.

1. iss
2. sub
3. jti
4. iat
5. nbf
6. exp
7. standard
8. env
9. company
10. status
11. checks
12. limits
13. verify

No natural person appears anywhere in it: no name, no email, no date of birth, no address, no document data, and no pointer to the identity check itself. Nor is there a score, a rating or a band. Nor is there any address a reader could poll to ask whether the company is still verified today, which is an omission by design and is why the expiry policy below matters.

A proof is a compact JWS signed with ES256. The header is exactly alg, kid and typ, and nothing in it is an address a verifier could be tempted to fetch.

• agentry-trust-proof+jwt means the proof was issued in the live environment: the checks it names were put to the third parties they name, on the dates they name.
• agentry-sandbox-proof+jwt means the proof was issued in the sandbox and is a test artefact. The value deliberately does not contain the live value as a substring, so a reader matching the live value by prefix or by substring fails on a sandbox proof rather than waving it through.

The typ is signed, so it cannot be edited after issue, and it must agree with the payload's env and with the signing key. Where the three disagree the proof is refused; it is never read as a sandbox proof on the strength of one of them.

• Live keys: /.well-known/agentry-trust-jwks
• Sandbox keys: /.well-known/agentry-sandbox-trust-jwks

They are two separate documents at two separate addresses. The live document never contains a sandbox key and never links to the sandbox document. Pin the live key set, follow no links out of a proof, and a sandbox proof cannot verify for you at all. Both are unauthenticated, because a reader who has to present a credential in order to check a signature is not verifying offline.

Neither document says anything about any business, and neither will. A key set that varied per business would be a status lookup with extra steps.

env is a required top-level claim on every proof in every environment. It is never defaulted and never omitted, and it takes exactly 2 values:

• live: the checks it names were performed against the third parties it names.
• sandbox: a test artefact. The checks it names may not have been performed against any register or any person, and it is not evidence of anything about the company it names.

It sits immediately after standard and before the first fact about the company, because the two together are the frame the rest is read through: standard is what was checked and env is whether it was really checked.

A sandbox proof also declares itself in its key: a sandbox kid begins sandbox-, and a live kid contains the word sandbox nowhere at all. A key identifier is a key selector rather than a meaning, so this is necessary and nowhere near sufficient on its own; it is the third leg of the agreement described above, so that a reader holding only the header can still tell.

Where a check was not put to the third party it would name, its source is sandbox_fixture, and it never names Companies House or the identity provider instead. That is a claim about the world rather than about the artefact, which is why it exists alongside env rather than being covered by it: a reader may overlook an environment claim, but a reader will rely on a named source.

What sandbox_fixture claims: that a check of this name ran in a sandbox deployment against a fixture, and that the proof was assembled and signed exactly as a live proof would be, so an integration built against it is a real integration.

What it does not claim: that any register was read, that any person was checked, that the company number names a real company, or that the company named consents to or knows about the proof. A proof carrying it is evidence of nothing about the company it names. A live proof may never carry it, in either direction: a proof with env of live and a check sourced sandbox_fixture is refused.

There is no revocation service, no status endpoint and no list to check. A proof stops being good when it expires and at no other moment. That is the deliberate consequence of a credential that verifies offline: an address you could poll to ask whether a proof is still good would be a status lookup, and would put us back in the middle of every reading.

• Live, by default: 30 days from issue.
• Live, maximum: 90 days. A longer lifetime cannot be requested and cannot be signed.
• Sandbox: 7 days, which is both the default and the maximum, so a test artefact that escapes into a screenshot stops verifying within the week.

A proof is not refreshed after issue and its facts are not re-checked. If the company's register status changes the day after issue, the proof stays cryptographically good until its expiry and says nothing about the change. Read checks[].asAt, decide whether a check that old is good enough for what you are about to do, and if it is not, ask for a fresh proof rather than trusting an old one. The subject can mint one in a second.

How a reader verifies a presented proof, and what the three possible results mean, is at /trust/verify-proof.