Decentralized identifiers (DIDs) enable verifiable, decentralized digital identity. DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities.
The DID core specification defines DIDs as "URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject". The DID document contains a set of verification methods and/or services, that can be used to prove control of the DID by the DID subject. DIDs are composed of the following parts:
The DID core specification offers full flexibility to choose any particular technology or cryptography to underpin the generation, persistence, resolution, or interpretation of DIDs. Over a hundred DID methods with different backing technologies are currently in development.
EDC is based on DID Web, a DID method that allows bootstrapping trust using a web domain's existing reputation.
Use DID Web to authenticate IDS calls between participants of the MVD (Minimum Viable Dataspace).
Authorization through verifiable credentials obtained from Identity Hub and policies are out of scope of this document.
The following example shows the deployment of 3 connectors. Each connector requires the following infrastructure for DID Web:
- KeyVault for storing certificates with the connector public and private keys. The certificate in PEM format must be stored as a secret, using the connector name as secret name.
- Storage account for hosting DID documents. DID documents must be exposed at a URL as described in the DID Web spec (e.g.
<STORAGE ACCOUNT DOMAIN>/<CONNECTOR_NAME>/did.json) and must contain the public key in JWK format.
Automated continuous deployment should generate certificates, DID documents and deploy these Azure components for each connector instance as part of a CI/CD workflow. See the DID Core specification for some sample DID documents, and refer to the reference showcase for a DID Web specific DID document template.
EDC sends IDS requests with a header containing a JSON Web Token (JWT). The JWT is generated using the private key in the certicate available in the KeyVault of the consumer connector. The DID is set as issuer of the JWT. The environmental variables VAULTNAME and DID_URL need to be set to the KeyVault name and DID respectively, for the EDC connector to perform this work correctly.
Upon reception, the provider connector verifies the JWT. To achieve this, the DID document URL is resolved from the DID available as the token issuer as described in the DID Web specification. The public key is retrieved from the DID document, which is then used by the provider connector to verify the JWT and thus the identity of the token's signer.
Note: since tokens are credentials, great care must be taken to prevent security issues. In general, JWTs should not be kept longer than required (expire them as soon as possible). A spike will be conducted to do further clarifications around security concerns, this ADR will be adapted accordingly.
No Identity Hub integration is desired at this point. A stub CredentialsVerifier implementation must be used, returning a preconfigured claim collection. Identity Hub integration will be evaluated later together with policies.
