The trust registry

The trust registry publishes which organizations may sign what: each registered organization’s public signing keys and its standing resolve in one anonymous, cacheable request. A verifier never trusts a deployment; it resolves the signer’s key against the registry and reads the organization’s standing.

Resolve a member state’s entry →

What it does today

• Resolves any registered organization, anonymously. GET /op/keys/ms-de.json answers the member state’s entry: the organization, its kind, its state, its standing, and its key set. The key set is empty today: organizations’ keys populate as their own administrators enroll them, which is the trust-registry program’s current work (the capture above, dated, shows the honest empty set).
• Refuses unknown organizations honestly. Asking for an organization that was never registered, GET /op/keys/no-such-organization.json, answers 404 with {"error":"organization 'no-such-organization' is not on the organization registry"}: the registry says so rather than guessing.
• Signs with attributable keys on the demo stack. The demo’s seeded EX1 carries its demo signing key, and the demo certificate’s VC and SD-JWT forms sign with the demo federation key, resolvable by did:web at demo.oimlsmart.org/.well-known/did.json, so the whole resolution story is exercisable end to end against the demo today.
• Scopes every key to its authorization. Each authority’s key is scoped to its authorized Recommendations by an X.509 v3 extension that the CNML verifier enforces, so a key answers not only “whose” but “for what”.
• Stays verifiable offline. The resolution document is anonymous, cache-bounded, and CORS-open; a verifier with a downloaded copy resolves a signer without a network path back at verification time.

How it works

The program divides the trust question cleanly: the identity service is the root of trust for who signs, the platform is the record of what was signed, and CNML is the signed artifact. An organization’s signing keys are the organization’s property on the identity service: registered, rotated, and revoked by the organization’s own administrator, with every act on the audit chain. The CNML signer block does not change shape; the binding is by reference, a key identifier plus an organization identifier, so the frozen format is untouched.

Revocation is immediate and auditable, and the time anchor does the honest work: an artifact signed before a revocation still resolves, with the answer “valid at the time; the key since revoked, on a stated date”.

Today (SMART) and the vision (SMART+)

Why it exists

A valid signature answers “is this signature mathematically sound” but not “whose key is this, and was that organization in good standing when it signed”. Without a registry, a certificate’s signing key is a deployment detail, unattributed to any accountable organization, and verification degrades into phoning the issuer. Legal metrology needs the stronger answer, attributed and auditable.

How it interops

The registry is the identity plane of the program’s dataspace work: no parallel trust framework is built, and the same resolution serves the CNML verify pipeline’s signature and scope checks. Because resolution is one cacheable document, verifiers compose it into their own pipelines without a program dependency at verify time.

Who may use it, and who may run it

Member states register; issuing authorities and test laboratories hold their organization keys; verification resolves anonymously. The determination, quoted from the program’s single entitlement source:

The honest questions

Why does the member state’s entry show an empty key set? Because that is the truth today. The registry and the resolution contract are live; organizations’ keys arrive when their own administrators enroll them, and the page shows the dated capture rather than dressing the gap. The demo stack shows the populated shape end to end.

What happens to artifacts signed before a revocation? They still resolve, honestly: the required time anchor proves when the artifact existed, and the answer reads “valid at the time; the key since revoked, on a stated date”. Nothing is rewritten and nothing disappears.

Who controls an organization’s keys? The organization’s own administrator, and nobody else. Registration, rotation, and revocation are the administrator’s acts, each on the audit chain; the program operates the registry but does not hold the keys.

Try it, read it, talk to us