Lire en anglais

Partager via


Activer la prise en charge de did:web:path

Dans cet article, nous allons suivre les étapes pour activer la prise en charge de did:web:path pour votre autorité.

Prérequis

Qu’est-ce que did:web:path ?

Did:web:path est décrit dans la spécification de méthode did :web. Si vous avez un environnement dans lequel vous devez utiliser un grand nombre d’autorités, l’acquisition de noms de domaine pour eux devient un problème. L’utilisation d’un seul domaine et l’affichage des différentes autorités comme des chemins d’accès dans le domaine peut être une approche plus favorable.

Activer le domaine pour la prise en charge de did:web:path

Par défaut, un locataire et une autorité ne sont pas activés pour prendre en charge did:web:path. Vous demandez l’activation de did:web:path pour votre autorité via la création d’une demande de support dans le Centre d’administration Microsoft Entra.

Détails du ticket de support :

  • Type de problème : Technical
  • Type de service : Microsoft Entra Verified ID
  • Type de problème : Configuration organization and domains
  • Résumé : Enable did:web:path request
  • Description : Veillez à inclure
    • Votre Microsoft Entra tenant ID
    • Votre did (exemple : did:web:verifiedid.contoso.com)
    • Nombre estimé de sous-chemins
    • Justification métier

Comment puis-je tester que mon autorité est activée ?

Vous recevez une confirmation sur votre demande de support, mais vous pouvez également vérifier si un domaine did:web est activé pour did:web:path en le testant dans un navigateur normal. En ajoutant un chemin d’accès qui n’existe pas (:do-not-exist dans l’exemple suivant), vous obtenez un message d’erreur avec le code discovery_service.web_method_path_not_supported si votre autorité n’est pas activée, mais le code discovery_service.not_found s’il est activé.

https://discover.did.msidentity.com/v1.0/identifiers/did:web:my-domain.com:do-not-exist

Comment faire configurer une autorité à l’aide de did:web:path ?

Une fois que votre client et votre autorité sont activés pour did:web:path, vous pouvez créer une autorité dans le même client que celui qui utilise did:web:path. Actuellement, cela nécessite l’utilisation de l’API d’administration, car il n’existe aucune prise en charge dans le portail.

  1. Obtenir les détails de votre autorité existante
    • Accédez au Verified ID | Overview domaine et copiez (par exemple : https://verifiedid.contoso.com/)
    • Accédez à Verified ID | Organization settings ce coffre de clés et prenez note de la configuration du coffre de clés.
    • Accédez à la ressource Key Vault et copiez le resource group, le subscription ID et le Vault URI
  2. Appelez l’autorité de création avec le corps JSON suivant (modifier selon les besoins). Le /my-path dans le chemin d’accès est l’endroit où vous spécifiez le nom du chemin à utiliser.
POST /v1.0/verifiableCredentials/authorities

{
  "name":"ExampleNameForPath",
  "linkedDomainUrl":"https://my-domain.com/my-path",
  "didMethod": "web",
  "keyVaultMetadata":
  {
    "subscriptionId":"aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e",
    "resourceGroup":"verifiablecredentials",
    "resourceName":"vccontosokv",
    "resourceUrl": "https://vccontosokv.vault.azure.net/"
  }
}
  1. Générez le document effectué pour la nouvelle autorité en appelant generateDidDocumentnewAuthorityIdForPath est l’attribut id dans la réponse de l’autorité de création :
POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateDidDocument
  1. Enregistrez la réponse de document à un fichier nommé did.json et chargez-le à l’emplacement sur votre serveur web qui correspond à l’appel linkedDomainUrl d’API pour la création de l’autorité. Si votre chemin d’accès est https://my-domain.com/my-path, le nouveau fichier did.json doit résider à cet emplacement.

  2. Récupérez la configuration du domaine lié via l’appel de l’API generateWellknownDidConfiguration avec le corps JSON suivant (modifier selon les besoins). DomainUrl est le nom de domaine sans le chemin d’accès

POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateWellknownDidConfiguration

{
    "domainUrl":"https://my-domain.com/"
}
  1. À partir de la réponse, copiez le jeton JWT à l’intérieur de la linked_dids collection.

  2. Sur votre serveur web, ouvrez le fichier https://my-domain.com/.well-known/did.configuration.json dans un éditeur et ajoutez le jeton JWT comme nouvelle entrée dans la collection linked_dids. Voici comment il se présente après l’ajout.

{
  "@context": "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld",
  "linked_dids": [
    "eyJh...old...U7cw",
    "eyJh...new...V8dx",
  ]
}
  1. Enregistrez le fichier.

Création de contrats à l’aide de la nouvelle autorité did:web:path

Les contrats doivent être créés à l’aide de l’API d’administration. Il n’existe actuellement aucune prise en charge de l’interface utilisateur pour les autorités secondaires.

Émission de contrats basés sur des identifiants dans la nouvelle autorité did:web:path

Pour que les applications émettent des identifiants en fonction des contrats de l’autorité did:web:path, vous devez uniquement modifier le champ de la authority charge utile de la requête pour créer l’API CreateIssuanceRequest.

{
  "authority": "did:web:my-domain.com:my-path",
  "includeQRCode": false,
  ... the rest is the same...
}