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é.
- L’autorité d’ID vérifiée est intégrée manuellement à l’aide de did:web. La configuration rapide utilise un nom de domaine géré par Microsoft qui ne peut pas être étendu.
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.
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
- Votre Microsoft Entra
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
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.
- 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
, lesubscription ID
et leVault URI
- Accédez au
- 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/"
}
}
- Générez le document effectué pour la nouvelle autorité en appelant generateDidDocument où
newAuthorityIdForPath
est l’attributid
dans la réponse de l’autorité de création :
POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateDidDocument
Enregistrez la réponse de document à un fichier nommé
did.json
et chargez-le à l’emplacement sur votre serveur web qui correspond à l’appellinkedDomainUrl
d’API pour la création de l’autorité. Si votre chemin d’accès esthttps://my-domain.com/my-path
, le nouveau fichier did.json doit résider à cet emplacement.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/"
}
À partir de la réponse, copiez le jeton JWT à l’intérieur de la
linked_dids
collection.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",
]
}
- Enregistrez le fichier.
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.
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...
}