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 :
did:web:api.sealtrust.io:brand:42La règle did:web transforme cet identifiant en une adresse web :
https://api.sealtrust.io/brand/42/did.jsonN'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
| Mode | Qui héberge le document | Ce que vous fournissez |
|---|---|---|
platform | nous | rien |
delegated | nous, sur votre propre domaine | votre domaine personnalisé, déjà vérifié chez nous |
self_hosted | vous | le 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ément | Survit ? | Pourquoi |
|---|---|---|
| L'ancrage sur la chaîne | oui, définitivement | la transaction est publique, nous ne pouvons ni la retirer ni la réécrire |
La signature, en self_hosted | oui | le fichier est déjà sur votre serveur |
La signature, en delegated | oui, après un geste | c'est nous qui servons le fichier aujourd'hui, repointez votre DNS et republiez le document |
La signature, en platform | oui, si vous avez gardé le document | l'adresse est la nôtre |
| Le contenu des passeports | oui, via votre export | il n'est servi que par notre API |
| La preuve d'inclusion | oui, si vous avez collecté les quatre valeurs | elles ne sortent que de notre API |
| La copie sur IPFS | non par défaut | un 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 puces | non si elles pointent vers nos domaines | une 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.
Cette page vous a-t-elle été utile ?
Votre réponse ouvre un courriel pré-rempli dans votre messagerie, à destination de contact@sealtrust.io. Vous le relisez avant de l'envoyer.