Practice statement

1Introduction

1.1Scope

TrustedAnchor is a general signing and identity service. It publishes the identities of organisations, and in future of issuers acting for people, and lets anyone verify what they sign. This version covers only what runs in production today: phytosanitary inspection records sealed in the MetaShip inspection application. Company identities anchored to registers, credentials about people, reusable identity checks (KYC/KYB) and signed documents will each be added here before they go live.

1.2Participants

• Operator: METASHIP LIMITED, which runs the identity hosting and register.
• Organisation: an entity with an identity did:web:trustedanchor.io:org:<id>, for example an inspection authority or packhouse operator.
• Administrator: a user the organisation authorises to approve or revoke device keys.
• Inspector: a logged-in user who seals records on an enrolled device.
• Relying party: anyone who checks a record, such as a border authority, bank, buyer or auditor. No account is needed.

1.3What a valid record proves

A record that verifies proves two things: it was signed by a key the issuing organisation has published, and it has not changed since. It does not prove that the inspection findings are correct. The organisation and its inspectors are responsible for that.

2Publication and repository

The operator publishes this statement, the standards map, the security disclosure and the operator’s legal details at trustedanchor.io, without registration. Identity documents are published at https://trustedanchor.io/org/<id>/did.json. Changes to this statement take effect on publication of a new dated version. Earlier versions stay available.

3Identification

3.1Organisations

Organisations are onboarded by the operator under a commercial agreement. Today, an organisation’s identity is established by that onboarding and is not independently checked against a company register. Register-anchored verification (UK Companies House, NL KvK, ZA CIPC) is in development. Until it ships, a relying party should treat an organisation identity as “known to the operator”, not “verified against a register”.

3.2Inspectors and devices

An inspector signs in to the inspection application with their organisation account. On first use, the device generates a signing key bound to that user and device. The key is enrolled for the organisation according to its approval mode (4.1).

4Key and record lifecycle

4.1Enrolment and approval

Manual approval (default): a new device key is held as pending. Records sealed with it are kept but do not count as verified until an administrator approves the key. Approval then stamps those records. Automatic enrolment (opt-in): the first seal by a logged-in inspector enrols the key immediately. The organisation’s identity document lists only active keys.

4.2Sealing

Sealing builds a credential from the inspection record and signs it on the device. The credential contains a hash of the full inspection sheet, a link to the previous seal’s hash, and a Merkle root over the pallet manifest. The register then checks the signature and confirms that the credential matches the record it holds.

4.3Revocation

An administrator can revoke a device key, for example when a device is lost. A revoked key is removed from the identity document and refused for new records. Records sealed before revocation stay valid. A sealed record can be voided by its organisation. The register reports void status to relying parties, and a voided record is not deleted.

4.4Retention

To be set: how long sealed records and key history are kept, and what happens to them if an organisation leaves the service or the service ends.

5Operational controls

The register and identity hosting run on Amazon Web Services: compute in the Africa (Cape Town) and Europe (Ireland) regions, and a replicated database whose primary is in Europe (Ireland). Production changes ship through the operator’s deployment pipelines, not from individual machines. See data residency.

6Technical security controls

• Algorithms: Ed25519 signatures, SHA-256 hashing and RFC 8785 canonical JSON, under the W3C eddsa-jcs-2022 cryptosuite.
• Device keys: generated by the browser’s WebCrypto as non-extractable keys and stored on the device. They are never sent to the operator. Only the public key is published.
• Register checks: the public verification endpoint refuses keys that are unenrolled, pending or belong to another organisation. Revoked keys are honoured only for records sealed before revocation.
• Operator keys: the root identity did:web:trustedanchor.io publishes no keys today. Before it signs anything, a key-generation ceremony and custody arrangement (a hardware-backed key management service) will be documented here.

7Profiles

Inspection credential: W3C VC 2.0, type PhytosanitaryInspectionCredential, with a DataIntegrityProof array (eddsa-jcs-2022, proof purpose assertionMethod). Identity documents use DID Core with Multikey verification methods. See the developer reference and the specimen.

8Audit and assessment

No independent audit has been performed. Planned assessments are listed on the standards page. Reports will be published here when issued.

9Legal matters

9.1Operator

METASHIP LIMITED, a company registered in England and Wales under number 16185486. Registered office: 9 Thorney Leys Park, Witney, Oxfordshire, OX28 4GE, United Kingdom.

9.2Liability

Awaiting legal review: limitation of liability towards organisations and relying parties.

9.3Governing law and disputes

Awaiting legal review.

9.4Independence

TrustedAnchor is not part of, endorsed by or affiliated with any company registry, plant-protection organisation or government body. Naming a register or authority on this site does not imply endorsement.