Habilite o suporte para did:web:path
Neste artigo, examinamos as etapas para habilitar o suporte a did:web:path para sua autoridade.
- A autoridade de ID verificada é integrada manualmente usando did:web. A configuração rápida usa um nome de domínio gerenciado pela Microsoft que não pode ser estendido.
Did:web:path é descrito na Especificação do método did:web. Se você tiver um ambiente no qual é necessário usar um alto número de autoridades, a aquisição de nomes de domínio para elas se tornará um problema. Usar um único domínio e fazer com que as diferentes autoridades apareçam como caminhos sob o domínio pode ser uma abordagem mais favorável.
Por padrão, um locatário e uma autoridade não estão habilitados para dar suporte a did:web:path. Solicite a habilitação de did:web:path para sua autoridade por meio da criação de uma nova solicitação de suporte no centro de administração do Microsoft Entra.
Detalhes do tíquete de suporte:
- Tipo de problema:
Technical
- Tipo de serviço:
Microsoft Entra Verified ID
- Tipo de problema:
Configuration organization and domains
- Resumo:
Enable did:web:path request
- Descrição: inclua
- Seu Microsoft Entra
tenant ID
- Seu
did
(exemplo: did:web:verifiedid.contoso.com) - Número estimado de subcaminhos
- Justificativa empresarial
- Seu Microsoft Entra
Você recebe uma confirmação em sua solicitação de suporte, mas também pode verificar se um domínio did:web está habilitado para did:web:path testando-o em um navegador normal. Ao adicionar um caminho inexistente (:do-not-exist
no exemplo a seguir), você receberá uma mensagem de erro com código discovery_service.web_method_path_not_supported
se sua autoridade não estiver habilitada, mas o código discovery_service.not_found
se ele estiver habilitado.
https://discover.did.msidentity.com/v1.0/identifiers/did:web:my-domain.com:do-not-exist
Depois que o locatário e a autoridade estiverem habilitados para did:web:path, você poderá criar uma nova autoridade no mesmo locatário em que usa did:web:path. Atualmente, isso requer o uso da API de administração, pois não há suporte no portal para isso.
- Obtenha detalhes da autoridade existente
- Vá para
Verified ID | Overview
e copie o domínio (exemplo:https://verifiedid.contoso.com/
) - Vá para
Verified ID | Organization settings
e anote qual cofre de chaves está sendo configurado. - Vá para o recurso cofre de chaves e copie o
resource group
, osubscription ID
e oVault URI
- Vá para
- Chame a autoridade de criação com o seguinte corpo JSON (modifique conforme necessário). O
/my-path
no caminho é onde você especifica o nome do caminho a ser usado.
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/"
}
}
- Gere o documento did para a nova autoridade chamando generateDidDocument, onde
newAuthorityIdForPath
é o atributoid
na resposta para a criação da autoridade:
POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateDidDocument
Salve a resposta do documento did em um arquivo chamado
did.json
e carregue-o no local em seu servidor Web que corresponda àlinkedDomainUrl
na chamada da API para criar a autoridade. Se o caminho forhttps://my-domain.com/my-path
, o novo arquivo did.json deverá residir nesse local.Recupere a configuração do domínio vinculado chamando a API generateWellknownDidConfiguration com o corpo JSON a seguir (modifique conforme necessário). O domainUrl é o nome de domínio sem o caminho
POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateWellknownDidConfiguration
{
"domainUrl":"https://my-domain.com/"
}
Na resposta, copie o token JWT dentro da coleção
linked_dids
.No servidor Web, abra o arquivo
https://my-domain.com/.well-known/did.configuration.json
em um editor e adicione o token JWT como uma nova entrada dentro da coleção linked_dids. O resultado deverá ser semelhante ao mostrado a seguir, após a adição.
{
"@context": "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld",
"linked_dids": [
"eyJh...old...U7cw",
"eyJh...new...V8dx",
]
}
- Salve o arquivo.
Os contratos precisam ser criados usando a API de Administrador. No momento, não há suporte à interface do usuário para autoridades secundárias.
Para que os aplicativos emitam credenciais com base em contratos na nova autoridade did:web:path, você só precisa alterar o campo authority
na carga da solicitação para a API createIssuanceRequest.
{
"authority": "did:web:my-domain.com:my-path",
"includeQRCode": false,
... the rest is the same...
}