# 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.

Source : https://docs.sealtrust.io/hebergement-du-did/

---

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:42
```

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

```
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é.

> [!INFO] Où vit la clé privée
> La clé qui **signe** ne quitte jamais notre module de sécurité matériel. Aucun
> des trois modes ci-dessous n'y change quoi que ce soit : ils déplacent seulement
> l'endroit où la clé **publique** est publiée.

## 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.

> [!ATTENTION] Ce que `did:web` ne protège pas
> Un identifiant `did:web` vaut exactement ce que vaut le contrôle du domaine. Il
> n'y a pas d'autorité au-dessus : qui prend la main sur le nom de domaine peut
> publier ses propres clés. Traitez ce domaine et son compte DNS comme un secret de
> production, avec la même protection que vos accès les plus sensibles.

## Le changement de mode est définitif

> [!ATTENTION] À décider avant votre premier passeport
> Changez de mode **avant d'émettre votre premier passeport**, jamais après.

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.