Hosting your DID document

By the end of this page you will know where the key that verifies your passports is published, which three hosting modes exist, which one to choose, and exactly what stays verifiable the day SealTrust ceases to exist.

#The principle

Every passport we issue for you is signed. Checking a signature requires the matching public key. That key is published in a DID document, at a fixed address, and the address is written inside the passport itself.

A passport therefore carries an identifier shaped like this:

did:web:api.sealtrust.io:brand:42

The did:web rule turns that identifier into a web address:

https://api.sealtrust.io/brand/42/did.json

Any standard did:web and SD-JWT-VC library makes that transformation, fetches the document, takes the key from it and checks the signature itself. We do not return a verdict, we publish a key.

#The three modes

#platform, the default

Your identifier is did:web:api.sealtrust.io:brand:<your number>. Nothing to do, nothing to maintain, and the document updates itself when your key changes.

The trade-off: the first verification of a passport goes through our servers.

#delegated

This mode requires the Inside plan and a custom domain already verified with us. It is not a separate subdomain: it is the same hostname that already serves your verification pages, for example id.example.com. You request that domain from SealTrust, then prove you control it by publishing the DNS records the console gives you. Until it reaches the verified state, the switch is refused.

The address becomes yours and key updates stay automatic.

#self_hosted, full independence

You serve https://id.example.com/.well-known/did.json from your own infrastructure. We no longer serve the document you issue under.

One trade-off to understand before choosing this mode: every time your signing key is rotated, you must republish the file. If you forget, passports issued after the rotation no longer verify, and nothing will warn you.

#Changing mode is permanent

A passport carries the identifier it was signed under, sealed inside its signature. Changing your mode changes the identifier you issue under, but not the ones already signed. You end up with two identifiers in circulation, and earlier passports keep pointing at the old one.

That old address stays served by us, with your non-revoked keys, so that passports signed before the switch remain verifiable by a standard tool. Our own check GET /passport/{identifier}/vc/verify, however, only knows how to verify under the current identifier: after a switch it answers with an error on your earlier passports, even when they are valid. Warn your auditors before switching.

That is why the switch is requested explicitly, and is not available from your settings.

#What survives if SealTrust disappears

This is the question an auditor asks, and here is the exact answer, unrounded.

#The four moves that turn this list green

Keep a copy of your DID document. It is public, at the address shown above. Download it and store it with your archives. It is the file that lets anyone check a signature without us, and it is only a few lines long.

Download your reversibility export, regularly. It holds your full data and your signed passports. Without it, the signature stays valid but you no longer hold the content it protects.

Collect your inclusion proofs, passport by passport. Call GET /passport/{identifier}/proof and record, from the passport_anchor block, the values merkle_root, leaf, leaf_index and proof. Nobody will be able to rebuild them once our API is switched off.

Pin your IPFS copies on your side. The addresses of your copies are in your export, under the ipfs_uri field. Not every passport has an IPFS copy, and the address does not always appear in the public proof. Pinning them with a provider of your choice costs little and makes the copy independent of our subscription.

#Key rotation

A signing key can be replaced without invalidating the past. Each key carries a version number, and each passport states in its header which version signed it. The DID document publishes all of your non-revoked keys, so an older passport keeps verifying with its older key.

Revoking a key is a stronger move: it leaves the document, and passports signed with it stop verifying. Only revoke when the key is compromised.

One thing to remember: on self_hosted, republish the document after every rotation.