DIDs usage

MATTR VII tenants support managing DIDs, which includes creating, retrieving and deleting DIDs. When creating a new DID, MATTR VII generates the required keys and metadata and registers the DID on a public ledger (if applicable). When retrieving DIDs, the tenant resolves them to get the latest key and service information.

MATTR VII establishes a verifiable relationship between your tenant domain and DIDs created by your tenant, enabling linkage between an internet domain owner and a DID owner. This approach creates a bridge that connects the traditional trust model of the internet with a distributed trust model. This follows the Well Known DID Configuration open standard developed by the Decentralized Identity Foundation (DIF).

Common DID usages in MATTR VII

Issuer DID

MATTR VII can be used by issuers to create DIDs that are used in Compact, Compact Semantic and Web Credential proofs. These are referred to as Issuer DIDs for these credential profiles.

The DID Document (refer to DIDs structure for more information) must be publicly discoverable by verifiers so they can know that the DID keys used for the credential proof are from an issuer they trust. This could be via a government backed or large enterprise ecosystem, or another organisation they already know and trust.

Issuer DIDs private keys are stored in the MATTR VII Key Management System (KMS), and published on the DID Configuration endpoint. They can be used to create different types of credentials, as well as support revokable credentials.

Verifier DID

MATTR VII can be used by verifiers to create DIDs that are used in a credential presentation exchange. These are referred to as Verifier DIDs. The credential holder needs to be sure that the received presentation request is from a valid verifier before sending their personal credential data in the response.

Even if other forms of trust are in place (e.g. the journey started from a website that the holder trusts) the DID to domain linkage must still be verified to validate the domain against the values used in the request.

Verifier DIDs private keys are stored in the MATTR VII KMS, and published on the DID Configuration endpoint. They must support message signing or key agreement for encryption.

MATTR Showcase Wallet DIDs

When someone uses their MATTR Mobile wallet app to interact with a new domain (either issuer or verifier), a unique DID is created for that interaction.

Subject DID

Verifiable credentials that are linked to a specific holder (e.g. an education certificate) are referred to as subject-bound credentials. When a DID from a mobile wallet user is used in subject-bound credentials, it is referred to as a Subject DID.

For OIDC Credential issuance flow, the Subject DID is used to sign the request object in the authorisation request, proving the client has control of the DID for the request.

Holder DID

When a DID is used to create presentations in response to verifier requests, it is referred to as a Holder DID. MATTR VII generates a unique and new Holder DID for each issuer/verifier interaction.

If the verifier and the issuer are hosted on the same domain, the same DID will be used for both the Holder DID and the Subject DID.

As part of the W3C Verifiable Credential data model specification, the verifiable presentation model is used to wrap all credentials inside a presentation and apply cryptographic proofs. The Subject DID from each credential is used to sign the presentation, as well as the Holder DID (even if they are the same). The Holder DID is the only DID presented to the verifier during DID auth requests.

Public DID

DIDs enable sending messages and data directly to the DID owner, assuming the sender has a way of retrieving the intended recipient DID. One such example is a Public DID that can be used to send secure messages and issue credentials to a specific digital wallet that is linked to this DID.