Abilitare il supporto per did:web:path
In questo articolo vengono illustrati i passaggi per abilitare il supporto per did:web:path all'autorità.
- L'autorità ID verificata viene inserita manualmente tramite did:web. L'installazione rapida usa un nome di dominio gestito da Microsoft che non può essere esteso.
Did:web:path è descritto nella specifica del metodo did:web. Se si dispone di un ambiente in cui è necessario usare un numero elevato di autorità, l'acquisizione dei nomi di dominio per tali autorità diventa un problema amministrativo. L'uso di un singolo dominio e la presenza delle diverse autorità come percorsi nel dominio può essere un approccio più favorevole.
Per impostazione predefinita, un tenant e un'autorità non sono abilitati per supportare did:web:path. Si richiede l'abilitazione di did:web:path per l'autorità tramite la creazione di una nuova richiesta di supporto nell'interfaccia di amministrazione di Microsoft Entra.
Dettagli del ticket di supporto:
- Tipo di problema:
Technical
- Tipo di servizio:
Microsoft Entra Verified ID
- Tipo di problema:
Configuration organization and domains
- Riepilogo:
Enable did:web:path request
- Descrizione: assicurarsi di includere
- Microsoft Entra
tenant ID
did
(ad esempio: did:web:verifiedid.contoso.com)- Il numero stimato di percorsi secondari
- Motivazione aziendale
- Microsoft Entra
Viene inviata una conferma alla richiesta di supporto, ma è anche possibile verificare se un dominio did:web è abilitato per did:web:path testandolo in un normale browser. Aggiungendo un percorso che non esiste (:do-not-exist
nell'esempio seguente) viene visualizzato e viene visualizzato un messaggio di errore con codice discovery_service.web_method_path_not_supported
se l'autorità non è abilitata, ma il codice discovery_service.not_found
se è abilitato.
https://discover.did.msidentity.com/v1.0/identifiers/did:web:my-domain.com:do-not-exist
Dopo aver abilitato il tenant e l'autorità per did:web:path, è possibile creare una nuova autorità nello stesso tenant che usa did:web:path. Attualmente questa operazione richiede l'uso dell'API Amministrazione perché non è disponibile alcun supporto nel portale.
- Ottenere i dettagli dell'autorità esistente
- Andare su
Verified ID | Overview
e copiare il dominio (ad esempio:https://verifiedid.contoso.com/
) - Andare su
Verified ID | Organization settings
e prendere nota della configurazione dell'insieme di credenziali delle chiavi. - Andare sulla risorsa dell'insieme di credenziali delle chiavi e copiare
resource group
,subscription ID
eVault URI
- Andare su
- Chiamare l'autorità di creazione con il seguente corpo JSON (modificare in base alle esigenze). Il
/my-path
percorso è la posizione in cui si specifica il nome del percorso da usare.
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/"
}
}
- Generare il documento DID per la nuova autorità chiamando generateDidDocument dove
newAuthorityIdForPath
è l'attributoid
nella risposta di creazione dell'autorità:
POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateDidDocument
Salvare la risposta del documento DID in un file denominato
did.json
e caricarlo nel percorso nel server Web corrispondente alinkedDomainUrl
nella chiamata API per la creazione dell'autorità. Se il percorso èhttps://my-domain.com/my-path
, il nuovo file di did.json deve risiedere in tale posizione.Recuperare la configurazione del dominio collegato tramite la chiamata all'API generateWellknownDidConfiguration con il seguente corpo JSON (modificare in base alle esigenze). DomainUrl è il nome di dominio senza il percorso
POST /v1.0/verifiableCredentials/authorities/:newAuthorityIdForPath/generateWellknownDidConfiguration
{
"domainUrl":"https://my-domain.com/"
}
Dalla risposta, copiare il token JWT all'interno della raccolta
linked_dids
.Nel server web, aprire il file
https://my-domain.com/.well-known/did.configuration.json
in un editor e aggiungere il token JWT come nuova voce all'interno della raccolta linked_dids. Dopo l'aggiunta, dovrebbe essere simile al seguente.
{
"@context": "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld",
"linked_dids": [
"eyJh...old...U7cw",
"eyJh...new...V8dx",
]
}
- Salvare il file.
I contratti devono essere creati usando l'API di amministrazione. Attualmente non è disponibile alcun supporto dell'interfaccia utente per le autorità secondarie.
Per fare in modo che le app rilascino credenziali in base ai contratti nella nuova autorità did:web:path, è sufficiente modificare il campo authority
nel payload della richiesta per l'API creareIssuanceRequest.
{
"authority": "did:web:my-domain.com:my-path",
"includeQRCode": false,
... the rest is the same...
}