.svg)
.svg)
We are excited to announce a new addition to our MATTR VII platform capabilities.
As we continue to build out an extensive suite of features to support the exchange of data such as Verifiable Credentials, we have now added secure Decentralized Identifier (DID) messaging capabilities to enable entirely new ways to communicate using our platform.
The common and well-understood ways to interact with verifiable credentials have typically been mechanisms such as scanning QR codes or sharing deep links. In this release, we have focused on adding an option to these approaches that provides an even greater level of transparency and user control. With this new capability, you will be able to facilitate more intuitive user flows that make issuing, verifying, and communicating around verifiable credentials a seamless and efficient process for users. While utilising existing frameworks like push notifications, secure DID messaging maintains a high level of privacy-preserving security. It does this by leveraging a decentralised ecosystem that ensures control of the data in a message remains solely with the participants exchanging the information, and no one else.
Utilising the JSON Web Message (JWM) specification, this new capability allows for encrypted messages to be sent and received in a way that hides their content from all but the cryptographically authorised recipients of the message. That way, the sender of the message can be confident they are only disclosing their details and message with the intended parties.
There are two key pieces of information about a recipient that are fundamental to facilitating secure DID-based messaging on the platform. The first of these is the same as any messaging framework, in that an address or endpoint is needed to understand where to send the message. Unlike traditional messaging capabilities that require you to utilise centralised, service provider created, and controlled identifiers such as email and phone numbers, our DID-based messaging solution allows you to facilitate interactions between parties simply by using a Decentralised Identifier and its associated DID Document. The second piece of information you need is the recipient’s public key, which the platform obtains from the resolved DID document. This public key is then used to encrypt a message to the recipient.
These capabilities ensure that:
- a message is delivered to the correct recipient, and
- only the intended recipient can view the content and other metadata of the message.
A unique DID is also created by the wallet specifically for each unique interaction with a particular party or organisation — further preserving a wallet holder’s privacy and anonymity between the various interactions they may have with issuers and relying parties alike.
Once the recipient’s DID is known, a message is formatted as a JSON Web Message (JWM). In this release, we have focused on adding support for 3 main types of messages:
- Offering a credential — rather than the user having to scan a QR code, a message can be sent directly to them that will initiate the credential offer flow within their wallet.
- Notification about a change in the revocation status of a credential — a mechanism to ensure wallet holders are proactively informed about any status changes for credentials they hold in their wallet, even if they’re not online when the status update occurs.
- Starting a credential verification flow (presentation request) — allows a holder to present a credential to a verifier directly, particularly useful in situations where there isn’t a co-location of parties present in the interaction.
To take advantage of this capability as a wallet user, all you need to do is opt into receiving messages by enabling notifications in your wallet. At this point, a private cloud-based inbox will be created to store messages that are sent to your device.
Messages remain encrypted in the inbox and are only persisted in storage while they are in an unread state. Once the user views the message and its payload is extracted into their wallet, the encrypted message is removed from the inbox and only the payload itself is retained in the user’s wallet.
To give an example, let’s say you call up your bank and they are required to sight a form of government-issued identification in order to revalidate their anti-money laundering (AML) records. Given the bank already has an established relationship with you from your prior communications, they will likely have your DID stored in their system. Using this information, they push a message containing a presentation request to you. This request is then processed by the wallet on your phone and triggers a push notification to make you aware of the update.
Upon receiving the push notification containing the message, the wallet app will decrypt and extract the payload. In this instance, it contains a presentation request that asks you to select the credential to share back to the bank as proof of your identity. Once you have shared the credential presentation to match their request, the bank verifies that it satisfies their requirements giving them assurance that they are talking to the correct person and that they have met their audit requirements from an AML perspective. This allows them to continue the call with you.
Bringing secure messaging into our platform helps facilitate a more intuitive user experience with mobile wallets and helps simplify some of the otherwise complex issuance and verification flows that might otherwise involve scanning multiple QR codes or accessing different embedded links.
We look forward to continuing our collaboration with the community on the underlying messaging and security standards as well as gathering feedback from our customers and the broader ecosystem around ways to enhance and extend the different types of messages, along with ways to digest them into different kinds of interactions and experiences.
Watch our demo on how to use secure DID messaging.
Sign up today to get access to MATTR VII and check out MATTR Learn for a detailed walkthrough to start utilising messaging as part of a verifiable credential flow.
This blog was originally posted on Medium.
