Héberger votre document DID

Où est publiée la clé publique qui vérifie vos passeports, les trois modes d'hébergement possibles, comment passer sur votre propre domaine, et ce qui reste vérifiable si SealTrust disparaît.

Sur cette page

En quittant cette page, vous saurez où est publiée la clé qui permet de vérifier vos passeports, quels sont les trois modes d'hébergement possibles, lequel choisir, et exactement ce qui reste vérifiable le jour où SealTrust cesserait d'exister.

#Le principe

Chaque passeport que nous émettons pour vous est signé. Vérifier une signature demande la clé publique correspondante. Cette clé est publiée dans un document appelé document DID, à une adresse fixe, et l'adresse est inscrite dans le passeport lui-même.

Un passeport porte donc un identifiant de la forme :

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

La règle did:web transforme cet identifiant en une adresse web :

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

N'importe quelle bibliothèque did:web et SD-JWT-VC standard fait cette transformation, télécharge le document, y prend la clé et contrôle la signature elle-même. Nous ne rendons pas de verdict, nous publions une clé.

#Les trois modes

ModeQui héberge le documentCe que vous fournissez
platformnousrien
delegatednous, sur votre propre domainevotre domaine personnalisé, déjà vérifié chez nous
self_hostedvousle fichier, sur votre serveur

#platform, le mode par défaut

Votre identifiant est did:web:api.sealtrust.io:brand:<votre numéro>. Vous n'avez rien à faire, rien à maintenir, et le document se met à jour tout seul quand votre clé change.

Contrepartie : la première vérification d'un passeport passe par nos serveurs.

#delegated

Ce mode demande l'offre Inside et un domaine personnalisé déjà vérifié chez nous. Ce n'est pas un sous-domaine à part : c'est le même nom d'hôte que celui qui sert déjà vos pages de vérification, par exemple id.example.com. Ce domaine se demande à SealTrust, puis vous prouvez que vous le contrôlez en publiant les enregistrements DNS que la console vous donne. Tant qu'il n'est pas en état vérifié, le basculement est refusé.

L'adresse devient la vôtre et la mise à jour de la clé reste automatique.

#self_hosted, l'indépendance complète

Vous servez https://id.example.com/.well-known/did.json depuis votre infrastructure. Nous ne servons plus le document sous lequel vous émettez.

Contrepartie à connaître avant de choisir ce mode : à chaque rotation de votre clé de signature, vous devez republier le fichier. Si vous l'oubliez, les passeports émis après la rotation ne se vérifient plus, et rien ne vous préviendra.

#Le changement de mode est définitif

Un passeport porte l'identifiant sous lequel il a été signé, gravé dans sa signature. Changer votre mode change l'identifiant sous lequel vous émettez, mais ne change pas ceux qui sont déjà signés. Vous vous retrouvez donc avec deux identifiants en circulation, et les passeports antérieurs continuent de pointer vers l'ancien.

Cette ancienne adresse reste servie par nous, avec vos clés non révoquées, pour que les passeports signés avant le basculement restent vérifiables par un outil standard. En revanche notre propre point de contrôle GET /passport/{identifiant}/vc/verify ne sait vérifier que sous l'identifiant courant : après un basculement il répond en erreur sur vos passeports antérieurs, même quand ils sont valides. Prévenez vos auditeurs avant de basculer.

C'est pour cette raison que le basculement se demande explicitement, et qu'il ne se fait pas depuis vos réglages.

#Ce qui survit si SealTrust disparaît

C'est la question qu'un auditeur pose, et voici la réponse exacte, sans arrondi.

ÉlémentSurvit ?Pourquoi
L'ancrage sur la chaîneoui, définitivementla transaction est publique, nous ne pouvons ni la retirer ni la réécrire
La signature, en self_hostedouile fichier est déjà sur votre serveur
La signature, en delegatedoui, après un gestec'est nous qui servons le fichier aujourd'hui, repointez votre DNS et republiez le document
La signature, en platformoui, si vous avez gardé le documentl'adresse est la nôtre
Le contenu des passeportsoui, via votre exportil n'est servi que par notre API
La preuve d'inclusionoui, si vous avez collecté les quatre valeurselles ne sortent que de notre API
La copie sur IPFSnon par défautun fichier n'y reste que tant que quelqu'un l'épingle, et c'est nous aujourd'hui
Les adresses gravées dans vos QR et vos pucesnon si elles pointent vers nos domainesune puce ne se réécrit pas à distance

#Les quatre gestes qui rendent cette liste verte

Gardez une copie de votre document DID. Il est public, à l'adresse indiquée plus haut. Téléchargez-le et conservez-le avec vos archives. C'est le fichier qui permet de vérifier une signature sans nous, et il tient en quelques lignes.

Téléchargez votre export de réversibilité, régulièrement. Il contient vos données complètes et vos passeports signés. Sans lui, la signature reste valable mais vous n'avez plus le contenu qu'elle protège.

Collectez vos preuves d'inclusion, passeport par passeport. Appelez GET /passport/{identifiant}/proof et enregistrez, dans le bloc passport_anchor, les valeurs merkle_root, leaf, leaf_index et proof. Personne ne pourra les reconstituer une fois notre API arrêtée.

Épinglez vos copies IPFS de votre côté. Les adresses de vos copies sont dans votre export, sous le champ ipfs_uri. Tous les passeports n'ont pas de copie IPFS, et sur la preuve publique l'adresse n'apparaît pas toujours. Les épingler chez un fournisseur de votre choix coûte peu et rend la copie indépendante de notre abonnement.

#La rotation de clé

Une clé de signature se remplace sans invalider le passé. Chaque clé porte un numéro de version, et chaque passeport indique dans son en-tête la version qui l'a signé. Le document DID publie toutes vos clés non révoquées, donc un passeport ancien continue de se vérifier avec son ancienne clé.

Révoquer une clé est un geste plus fort : elle sort du document, et les passeports signés avec elle cessent de se vérifier. Ne révoquez que si la clé est compromise.

Une seule chose à retenir : en mode self_hosted, republiez le document après chaque rotation.

Votre réponse ouvre un courriel pré-rempli dans votre messagerie, à destination de contact@sealtrust.io. Vous le relisez avant de l'envoyer.

Proposer une correctionSignaler un problème