The MATTR teams have been hard at work adding new capabilities and additional features to our MATTR VII platform, SDKs and MATTR Wallet.

We’ve spent a lot of time collaborating with customers to better understand their needs and expectations when it comes to data security, auditability and user experience.

Here’s a walkthrough of what’s new in the MATTR universe — including new cloud deployment options, enhanced security features and a fully revamped digital wallet.

Introducing event logs to the MATTR VII platform

We have added enhanced logging for all key API calls (platform events logs) to the MATTR VII platform. Over 130 different types of events are now logged!

There are three different levels of logging that can be configured:

• Level 1 — Basic information such as the API name, date, time, request ID
• Level 2 — Basic information + metadata
• Level 3 — Basic information + metadata + full API payload information

All MATTR VII public cloud deployments are set to Level 1, which excludes any personally identifiable information (PII).

In MATTR VII private cloud deployments, the logging level is configurable based on the customer’s audit, user privacy and operational requirements. Private cloud users can also leverage our integration adaptor to extract the platform event logs to their systems, e.g., centralised audit logging stores, SIEM, billing capability or data warehouses.

Get notified of event updates automatically with webhooks

MATTR VII now supports webhooks, a standard design pattern that allows subscription to specific MATTR VII platform events in real time. Customers can be automatically notified of these platform events and either integrate that information into specific workflows or store additional information.

The first webhook that customers can subscribe to will notify them each time a credential is issued by the MATTR VII OIDC bridge. This enables ongoing credential lifecycle management activities with the information returned in the webhook, such as sending additional communications to the holder or augmenting end user records.

We’ll be adding additional webhooks in the future to give MATTR’s customers even more flexibility in integrating their systems with the MATTR VII platform.

Use our HTTP Signatures Library

To provide customers with confidence in the integrity and validity of webhook events, we’ve open-sourced our HTTP signatures library — anyone can now integrate it with their own applications.

HTTP message signatures are a way of digitally signing an HTTP request to give the receiving party assurance of the integrity of the message, and that the party sending the information is who they say they are.

Though this mechanism can be applied to any HTTP request, it’s particularly effective when used with MATTR VII webhook events. It allows the subscriber to authenticate that the signed request is, in fact, coming from MATTR VII. We’ve also published:

• An NPM library to allow for easier software integration of this capability.
• A sample app to demonstrate how to use the open-source library in your implementation.

Read the technical tutorials about implementing webhooks on MATTR Learn.

Read more about how we’re enhancing the security of webhooks with HTTP signatures.

Meet the new MATTR Wallet

We’re thrilled to announce we’ve re-released the MATTR Wallet — our digital wallet app that helps showcase to developers and ecosystem pilot partners how verifiable credentials can work in the real world, in real-time.

The latest release has been designed with end users in mind, accessibility tested and informed by in-depth customer insight.

It includes a fresh onboarding flow, which reduces friction for first-time end users, and a new home screen that consolidates important information. Improved navigation and powerful new search capabilities make it easier and faster for users to find what they need.

An interactive activity tab has been introduced. It lists all interactions and highlights items that need attention. End users can view their history and filter interactions quickly. Clearer transaction screens make it easier to review what’s being received and give consent for sharing.

Our research has shown that end users trust digital credentials that mimic their real-life cards and certificates more readily, so issuers can now customise their credentials. Customers can add logos, choose background colours and create watermarks on digital credentials to make them feel more like real-world versions.

Get in touch with us to explore how the MATTR can accelerate your project’s time to market and how MATTR’s wallet capabilities (including SDKs, white-label options) can be used to support your proof-of-concept phase and beyond.

For those who want to see the MATTR Wallet showcase these new features in action, download and prototype with our latest tech by visiting the App Store, or Google Play store. Remember, this product may only be used in production by pre-approved pilot partners.

Security and deployment to meet enterprise-level needs

One of our top priorities at MATTR is offering the right options when it comes to how and where our platform is deployed, and meeting our customers’ availability, security, efficiency and privacy needs.

MATTR VII is now live in two additional AWS regions — Frankfurt, Germany and Montréal, Canada — which gives our European and North American customers enhanced platform support and options to meet their data sovereignty and compliance requirements.

Find out more about how the MATTR VII platform can be deployed.

We’re committed to providing high-quality enterprise and government-grade solutions with our SOC2 and Cyber Essentials Certified Plus compliance. Additionally, security firm Trail of Bits has completed an independent audit of the key code libraries that power the MATTR VII platform.

We take customer data very seriously and continue to uphold the highest possible standards for confidentiality and integrity throughout our organisation, including our processes, our people and our systems.

Read more about how the MATTR Security Framework supports diverse compliance and safety needs.

More options for OIDC bridge issuances and configurations

For customers, integration with existing infrastructure eases the burden of adopting the new tools and capabilities MATTR provides. In particular, the use of OpenID Connect as a common protocol for credential exchange has been a very effective pattern for our customers and continues to gain traction in the broader internet standards community.

We’ve enhanced our OIDC bridge extension to support additional identity providers like Okta, ForgeRock and AzureB2C. Customers can now easily integrate credential issuing capabilities with more of the identity providers they already use.

Additional OIDC configuration options are also now available to help customers customise and simplify the user experience of collecting credentials.

— —

MATTR helps organisations and governments incorporate verifiable credentials into their operations in a secure, simple and accessible way. If you’re interested in learning how MATTR products can make yours better, get in touch with us today.

What’s new in the MATTR universe was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

An important part of creating a future where digital trust is embedded into business practices is creating tools to strengthen secure communication across systems and applications.

Part of this effort for our products at MATTR includes implementing standards that make our API communications more secure. We recently announced that we’re introducing the use of HTTP message signatures to our flagship MATTR VII platform, which enhance data security and make the interactions between different parties on the web safer.

We also champion open and interoperable standards across the internet and web applications in our mission to make a safer internet for all. To aid both our customers and others in the community in this, we’ve made our HTTP Signatures library fully open-sourced and publicly accessible.

HTTP message signatures

Hypertext Transfer Protocol, more commonly known as HTTP, is a core technology that underpins the internet. As it enables global systems to communicate with each other, it’s critical to secure HTTP messages as much as possible.

Much like an artist’s signature on a painting in the real world, a digital signature assures a verifying party that information:

• has integrity — it hasn’t been tampered with
• originated from an authentic source — it’s from where it says it’s from.

HTTP message signatures apply the power of digital signatures to HTTP, providing integrity and origin authenticity properties to the message or request.

Other digital security methods like OAuth and shared secrets, used to implement authentication and access control on APIs and web applications, require a round-trip to confirm the client. The HTTP Signatures scheme doesn’t. The integrity of a message sent can be verified independently and directly by the receiver and both parties can be confident that information has not been tampered with.

The use of HTTP message signatures is currently a draft standard incubating at the Internet Engineering Task Force (IETF) [Read the draft IETF standard]. If the draft is progressed to a finalised standard, this technology could become more commonly utilised across applications.

HTTP signatures have broader benefits for the community. There are various use cases where security features can be applied to different kinds of interactions. Examples include:

• Authorising access to a secure storage backend
• Filtering spam and other messages sent to a communication endpoint
• Allowing ecosystems to authenticate access to permissioned APIs
• And many more

How we use HTTP message signatures with webhooks

Within our MATTR VII platform, we’re using HTTP message signatures to help customers verify the authenticity and integrity of webhooks sent by the platform. A webhook is a standard design pattern that enables a party to “subscribe” to one or more events on a system by supplying a callback URL. The URL is used to communicate with another party when a certain condition or event occurs.

With a “publish and subscribe” model, MATTR VII customers can be set up to be notified that the specific event has been triggered, such as a credential issuance events or configuration updates –they then use those to take further action based on business needs.

What HTTP message signatures do for webhooks

Using webhooks on the MATTR VII platform requires customers to set up an endpoint to receive information, and that endpoint must be open to the public internet.

Because of this, there needs to be a way for the subscribed system to authenticate that the request is coming from MATTR VII and that the request is valid and not being spoofed, intercepted or modified in any way by malicious actors.

We sign the outbound webhook events with HTTP message signatures so our customers can safely call MATTR VII APIs from webhooks, and any subscriber can confidently verify the received requests are coming from us.

HTTP message signatures provide an easy and scalable way for our customers to authenticate messages or requests from our platform. The same pattern can be used to provide authenticity for any kind of web interaction or event trigger.

Leverage the technology for your own implementations

The application of the HTTP Signatures library in the context of webhooks is one of many implementation examples.

Broader implementation of the HTTP message signatures scheme will lead to more secure digital interactions and a safer internet for all, so we have open-sourced our HTTP Signatures library for both MATTR customers and for the community at large.

The library is permissively open-source, and we believe it will help the community establish higher levels of security between web services and applications.

Open-sourcing the library also encourages interoperability and integration with the MATTR VII platform, making it more accessible for businesses of all shapes and sizes.

Get started

It’s easy to get started today. You can:

• Access the open-source HTTP Signatures library on GitHub
• Check out the HTTP Signatures NPM package for easier integration
• See an example implementation of how to verify a webhook that was generated by MATTR VII

This article first appeared on mattr.global.

Open sourcing our HTTP Signatures library was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since the beginning of our journey here at MATTR, decentralization and digital identity have been central to our approach to building products. As part of this, we’ve supported Decentralized Identifiers (or DIDs) since the earliest launch of our platform. We’ve also considered how we might give you more options to expand the utility of these identities over time.

An important milestone

The W3C working group responsible for Decentralized Identifiers recently published the DID v1.0 specification under “Proposed Recommendation” status. This is a significant milestone as DIDs approach global standardization with the pending approval of the W3C Advisory Committee.

DIDs are maturing, but so is the environment and context in which they were originally designed. With a complex ecosystem consisting of dozens of different methodologies and new ones emerging on a regular basis, it’s important to balance the potential of this decentralized approach with a realistic approach for defining the real utility and value of each DID method. For example, the DID Method Rubric provides a good frame of reference for comparing different approaches.

Different types of DIDs can be registered and anchored using unique rules specific to the set of infrastructure where they’re stored. Since DIDs provide provenance for keys which are controlled by DID owners, the rules and systems that govern each kind of DID method have a significant impact on the trust and maintenance model for these identifiers. This is the key thing to remember when choosing a DID method that makes sense for your needs.

Our supported DID methods

In MATTR VII, by supporting a variety of DID methods — deterministic or key-based DIDs, domain-based DIDs, and ledger-based DIDs — we are able to provide tools which can be customized to fit the needs of individual people and organizations.

• Key-based DIDs — Largely static, easy to create, and locally controlled. This makes them a natural choice for applications where there’s a need to manage connections and interactions with users directly.
• DIDs anchored to web domains — These have a different trust model, where control over the domain can bootstrap a connection to a DID. This makes a lot of sense for organizations with existing domain names that already transact and do business online, and can extend their brand and reputation to the domain of DIDs.
• Ledger-based DIDs — These offer a distributed system of public key infrastructure which is not centrally managed or controlled by a single party. While ledgers differ in their governance and consensus models, they ultimately provide a backbone for anchoring digital addresses in a way which allows them to be discovered and used by other parties. This can be a useful feature where a persistent identifier is needed, such as in online communication and collaboration.

There is no single DID method or type of DID (which at the moment) should be universally applied to every situation. However, by using the strengths of each approach we can allow for a diverse ecosystem of digital identifiers enabling connections between complex networks of people, organizations and machines.

To date, we’ve provided support for three main DID methods in our platform: DID Key, DID Web, and DID Sovrin. These align with three of the central types of infrastructure outlined above.

Introducing DID ION

We’re proud to announce that as of today we’ve added support for DID ION, a DID method which is anchored to IPFS and Bitcoin. We’ve supported the development of the Sidetree protocol that underpins DID ION for some time as it has matured in collaboration with working group members at the Decentralized Identity Foundation.

With contributions from organizations such as Microsoft, Transmute, and SecureKey, Sidetree and DID ION have emerged as a scalable and enterprise-ready solution for anchoring DIDs. The core idea behind the Sidetree protocol is to create decentralized identifiers that can run on any distributed ledger system. DID ION is an implementation of that protocol which backs onto the Bitcoin blockchain, one of the largest and most used public ledger networks in the world.

Sidetree possesses some unique advantages not readily present in other DID methods, such as low cost, high throughput, and built-in portability of the identifier. This provides a number of benefits to people and organizations, especially in supporting a large volume of different kinds of connections with the ability to manage and rotate keys as needed. We have added end-to-end capabilities for creating and resolving DIDs on the ION network across our platform and wallet products.

Although DID ION is just one implementation of the Sidetree protocol, we see promise in other DID methods using Sidetree and will consider adding support for these over time as and when it makes sense. We’ll also continue to develop Sidetree in collaboration with the global standards community to ensure that this protocol and the ION Network have sustainable futures for a long time to come.

At the same time, the community around DID Sovrin is developing a new kind of interoperability by designing a DID method that can work for vast networks of Indy ledgers, rather than focusing on the Sovrin-specific method that’s been used to date. As DID Sovrin gets phased out of adoption, we’re simultaneously deprecating standard support for DID Sovrin within MATTR VII. We’ll be phasing this out shortly with upcoming announcements for customers building on our existing platform.

If you’ve got any use cases that utilize DID Sovrin or want to discuss extensibility options, please reach out to us on any of our social channels or at info@mattr.global and we’ll be happy to work with you.

Looking ahead

We believe this a big step forward in providing a better set of choices when it comes to digital identity for our customers. From the start, we have designed our platform with flexibility and extensibility in mind, and will continue to support different DID methods as the market evolves.

We look forward to seeing how these new tools can be used to solve problems in the real world and will keep working to identify better ways to encourage responsible use of digital identity on the web.

Adding DID ION to MATTR VII was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

At MATTR, we’ve pioneered a way to request and receive credentials using OpenID Connect (OIDC) capability.

However, if you already have a robust mechanism in place to authenticate users, then setting up additional OIDC capability is unnecessary. Sending credentials using secure Decentralized Identifier (DID) messaging or directly with a QR code is a safe, convenient alternative. In this article, we’ll explore this alternative method in more detail.

The MATTR mobile wallet supports two main channels for issuing a credential:

• OpenID Credential Provider
• Secure DID messaging

Note: We’re building DID messaging on the JOSE stack to facilitate signing and encryption.

OpenID Credential Provider

If you haven’t yet authenticated a user, using OpenID Credential Provider offers a secure way to authenticate a user at the point of credential creation. It involves setting up and configuring an OpenID Provider to work alongside the MATTR VII OIDC Bridge Extension — simple if you’re already using OIDC infrastructure, but more complex to set up from scratch.

Secure DID messaging

If you’ve already authenticated a user through another method, issuing a credential through a secure DID message is a reliable alternative to OIDC. This approach works well if you’re authenticating users through a website login or even in person (like a classroom or training centre).

Let’s see how this might work in practice.

1. Authentication

Before issuing a credential, you need to authenticate the user. The most common way to do this is having a user login to a session on your website.

2. Linking

Now that you’ve authenticated the user, you need to link their DID to the session of the user. This DID will be generated by the wallet they are using to hold the credential. You can obtain it in a few different ways:

• If the user already has a credential you’ve issued, and you trust they are still in control of the subject DID in the credential, you can create a new credential based off the DID inside the credential.
• If the user needs to link their DID from their mobile wallet, you can use a DID Auth flow to make sure you’re obtaining a validated DID that the user can prove they own.
• If you needed to verify credential data from the user as part of the transaction anyway, you’ll need to use the Holder DID from the Verifiable Presentation as the determining DID.

For very simple use cases like demo and testing, if a user has the MATTR mobile wallet they can use a Public DID — they can simply copy the DID and pass it to you out-of-band.

3. Constructing the credential and message

Now that the DID is ‘known’ and we’ve authenticated the user, a Verifiable Credential is created using the MATTR VII platform. This credential is then packaged into a secure DID message format to be delivered to the recipient. Because the subject DID is known, the DID message can be encrypted to ensure the data is safe in transit. Use the messaging endpoints to easily perform this step.

4. Delivery

The MATTR mobile wallet can read DID messages in either a secure DID message, QR code or deep-link.

Sending a secure DID message is an easy way to push messages to mobile wallet holders. Once the message has been encrypted, it can be sent to the subject DID and the MATTR VII platform will route the encrypted message to the holder.

QR codes and deep-links typically make the messages too large to be reliably read by most smartphones. To solve this, we embed a URL to an endpoint hosting the DID message. Then, the MATTR mobile wallet simply follows a redirect to obtain the message.

5. Storing the credential

Once the MATTR mobile wallet receives the message, the user can view the credential to make sure it’s correct, then store the credential in the wallet.

At this stage, the wallet will also perform some checks to verify the credential, including:

• Validation of the credential proof
• Resolving the issuer DID document
• Checking that the issuer is publishing a valid DID-to-Domain linkage credential.

The checks are clearly visible to the user, and there’s assurance that when it comes time for a user to present their credential, it’ll be accepted by trusted verifiers.

Wrap up

If you’re already using a secure mechanism to authenticate your users, then setting up OIDC capability isn’t necessary. As we’ve explored, sending credentials using secure DID messaging directly or via a QR code or deep-link is safe, convenient and allows users to obtain their credentials directly.

Try this out for yourself now on the MATTR VII platform and in the MATTR mobile wallet.

MATTR VII trial

Sign up today for a free trial of our MATTR VII platform to experience the powerful capabilities that can be deployed in the context of your organization.

Issuing credentials directly to the MATTR mobile wallet was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

From the start, it’s been a core part of our mission to make sure that end users understand the implications of decentralized identity and the control it affords them over their data and their privacy. This model offers users greater sovereignty over their own information by empowering individuals as both the holder and subject of information that pertains to them. Users are able to exercise their new role in this ecosystem by utilizing a new class of software known as digital wallets.

We first released our Mobile Wallet for smartphones in June 2020, with a simple user interface to allow people to interact with and receive credentials from issuers as well as present credentials to relying parties. In the interim, we have developed a number of improvements and features to the Mobile Wallet to support advanced capabilities such as:

• Authenticating to Identity Providers over OpenID Connect to receive credentials via OIDC Bridge
• Deriving privacy-preserving selective disclosure presentations from credentials using BBS+ signatures
• Establishing a secure DID messaging inbox for users to receive encrypted messages and push notifications

These changes have not only made the wallet more functional; they’ve also evolved to better protect users’ best interests — giving them privacy-by-design and surfacing the information and context that they need to confidently make decisions underpinned by the security of decentralized identity.

This journey has led us to realize the importance of creating a wallet experience that places users front and center. As these systems create more opportunity for user-driven consent and identity management, they’ve simultaneously created a demand for a wallet that can not only perform the technical operations required, but do so in a user-friendly way that surfaces the information that truly matters to people. Our latest feature release to the MATTR Mobile Wallet is a step in this direction.

With Human-Friendly Credentials, we have added the capability to render different kinds of credentials uniquely in the wallet interface according to the information they contain. Until now, the end user experience for verifiable credentials has been largely consistent across different categories of credentials and issuers. In other words, a credential containing medical data from your doctor looks exactly the same as an education credential from your university or a concert ticket from a music venue: they all appear to the user as a long list of claims.

In this release we change that. Thanks to the semantic information encoded in verifiable credentials, the wallet is now able to understand and interpret certain kinds of credentials to render them to the user in a way that makes the data easier to understand.

JSON-LD verifiable credentials have the ability to support common data vocabularies and schemas which are published on the web. For example, if a credential contains a claim describing the name of an individual, the claim can be defined via reference to an existing data vocabulary found here: https://schema.org/Person

Human-Friendly Credentials allow the wallet to start intelligently displaying known credential types and data types. This shows up in a variety of different ways in a user’s dataset.

For example, this update formats address fields to make them more readable; formats names and proper nouns where possible; makes URLs, telephone numbers and email addresses clickable; highlights images and icons for better trust and brand signaling; and creates basic rules for language localization that adjust to a user’s device settings. This logic allows the wallet to create a kind of information hierarchy that starts to draw out the important aspects of data included in a credential, so users can make trust-based decisions using this information.

These rules are applied to any kind of credential the wallet encounters. Whilst all of this is incredibly helpful for users, we have gone a step further: displaying entire credentials in a completely unique UI according to their type. The ‘type’ property of a credential expresses what kind of information is in the credential — is it a degree, a medical record, a utility bill? The usage of common credential types across different implementations and ecosystems is necessary for semantic interoperability on the broader scale. The wallet should be able to recognize these common credential types and display them to the user in a friendly way.

In this update, we have added custom rendering for both Personal Identity Credentials as well as Education Courses. These are common types we see occurring naturally across the decentralized identity landscape, and now the MATTR Mobile Wallet is able to recognize and display them properly.

An important note to consider is that Human-Friendly Credentials only work for known data and credential types. As the ecosystem matures, we expect to add more data types and credential types in the future to support an even broader set of human-related processes and actions. In a general sense, we will also continue to iterate on our digital wallet offerings to provide a greater degree of flexibility and control for end users. We believe it’s a vital component to a healthy digital trust ecosystem.

To check out these changes yourself, download the latest version of our Mobile Wallet to get started.

For more information on Human-Friendly Credentials, check out our tutorials and video content on MATTR Learn.

For everything else related to MATTR, visit https://mattr.global or follow @MattrGlobal on Twitter.

Rendering credentials in a human-friendly way was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 utilizing existing frameworks like push notifications, secure DID messaging maintains a high level of privacy-preserving security. It does this by leveraging a decentralized ecosystem that ensures control of the data in a message remains solely with the participants exchanging the information, and no one else.

Utilizing 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 authorized 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 utilize centralized, 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 Decentralized 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 organization — 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.

Sign up on our website today to get access to MATTR VII and check out MATTR Learn for a detailed walkthrough to start utilizing messaging as part of a verifiable credential flow.

Adding support for Secure DID Messaging was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Internet Identity Workshop continues to be a central nucleus for thoughtful discussion and development of all things related to digital identity. The most recent workshop, which was held in mid-April, was no exception. Despite the lack of in-person interaction due to the ongoing global pandemic, this IIW was as lively as ever, bringing together a diverse set of stakeholders from across the globe to share experiences, swap perspectives, and engage in healthy debates.

One common theme this year was the continued development and adoption of BBS+ signatures, a type of multi-message cryptographic digital signature that enables selective disclosure of verifiable credentials. We first introduced this technology at IIW30 in April 2020, and have been inspired and delighted by the community’s embrace and contribution to this effort across the board. In the year since, progress has been made in a variety of areas, from standards-level support to independent implementations and advanced feature support.

We thought we’d take a moment to round up some of the significant developments surrounding BBS+ signatures and highlight a few of the top items to pay attention to going forward.

Over the past few months, the linked data proofs reference implementation of BBS+ published a new release that introduces a variety of improvements in efficiency and security, including formal alignment to the W3C CCG Security Vocab v3 definitions. In addition, support for JSON-LD BBS+ signatures was added to the VC HTTP API, making it possible to test this functionality in an interoperable way with other vendors participating in an open environment.

An important element in enabling BBS+ signatures is using what’s known as a pairing-friendly curve; for our purposes we use BLS12–381. We have seen some promising signs of adoption for this key pair, with multiple Decentralized Identifier (DID) methods — both did:indy from Hyperledger and did:ion from DIF — indicating they intend to add or already have support for these keys, allowing BBS+ signatures to be issued across a variety of decentralized networks and ecosystems. This development is possible due to the fact that BBS+ signatures is a ledger-independent approach to selective disclosure, effectively no custom logic or bespoke infrastructure is needed for these digital signatures to be created, used and understood.

In addition, the Hyperledger Aries project has been hard at work developing interoperable and ledger-agnostic capabilities in open source. The method used to track interop targets within the cohort and ultimately measure conformance against Aries standards is what’s known as an Aries Interop Profile (AIP). A major upcoming update to AIP will add support for additional DID methods, key types and credential formats, as well as introducing Aries support for JSON-LD BBS+ signatures as part of AIP 2.0. This will allow Aries-driven credential issuance and presentation protocols to work natively with BBS+ credentials, making that functionality broadly available for those in the Aries community and beyond.

There have also been a number of exciting developments when it comes to independent implementations of BBS+ signatures. Animo Solutions has recently implemented JSON-LD BBS+ signatures support into the popular open-source codebase Hyperledger Aries Cloud Agent Python (ACA-Py). In another independent effort, Trinsic has contributed an implementation of JSON-LD BBS+ credentials which they have demonstrated to be working in tandem with DIDComm v2, a secure messaging protocol based on DIDs. Implementations such as these help to demonstrate that open standards are transparent, can be understood and verified independently, and can be implemented with separate languages and tech stacks. They also set the groundwork for demonstrating real testing-driven interoperability via mechanisms such as the VC HTTP API and AIP 2.0. We are continuously looking to improve the documentation of these specs and standards so that their implications and nuances can be more broadly understood by builders and developers looking to engage with the technology.

On the cryptographic side of things, progress is also being made in hardening the existing BBS+ specification as well as expanding BBS+ to support more advanced privacy-preserving features. A significant development in this area is the work of cryptographer Michael Lodder who has been actively conducting research on an enhanced credential revocation mechanism using cryptographic accumulators with BBS+. This approach presents a promising alternative to existing solutions that allow authoritative issuers to update the status of issued credentials without compromising the privacy of the credential holder or subject who may be presenting the credential. We see this as another application of BBS+ signatures in the context of verifiable credentials that carries a lot of potential in pushing this technology to an even more robust state.

There was also initial discussion and tacit agreement to create a new cryptography-focused working group at Decentralized Identity Foundation. As the new WG drafts its charter, the first work item of this group will be the BBS+ Signatures spec which defines the cryptographic scheme known as BBS+ agnostic of its application in areas such as linked data signatures or verifiable credentials. In the future, this WG will likely evolve to include other crypto-related work items from the community.

This is just the tip of the iceberg when it comes to the momentum and development building around this technology in the community. We couldn’t be more excited about the future of BBS+ signatures, especially as we gear up to tackle the next set of hard problems in this area including privacy-preserving subject authentication and revocation using cryptographic accumulators. If you’re interested we encourage you to get involved, either by contributing to the Linked Data Proofs specification, checking out our reference implementations, or participating in the new WG at DIF, to name but a few of the many ways to engage with this work. We look forward to doing this retrospective at many IIWs to come, documenting the ever-growing community that continues to champion this technology in dynamic and interesting ways.

IIW32: BBS+ and beyond was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our story

At its inception, we chose “MATTR” as a moniker because we strongly believed that the movement towards more decentralized systems will fundamentally change the nature of data and privacy on the internet. Matter, in its varying states, forms the building blocks of the universe, symbolically representing the capacity for change and transformation that allows us all to grow and adapt. In another sense, people matter, and the impact of decisions we make as builders of technology extend beyond ourselves. It’s a responsibility we take seriously, as Tim Berners Lee puts it, “to preserve new frontiers for the common good.” We proudly bear the name MATTR and the potential it represents as we’ve built out our little universe of products.

In September 2020, we introduced our decentralized identity platform. Our goal was to deliver standards-based digital trust to developers in a scalable manner. We designed our platform with a modular security architecture to enable our tools to work across many different contexts. By investing deeply in open standards and open source communities as well as developing insights through collaboration and research, we realized that developers want to use something that’s convenient without compromising on flexibility, choice, or security. That’s why we launched our platform with standards-based cryptography and configurable building blocks to suit a broad array of use cases and user experiences in a way that can evolve as technology matures.

At the same time, we’ve continued to work in open source and open standards communities with greater commitment than ever to make sure we’re helping to build a digital ecosystem that can support global scale. We launched MATTR Learn and MATTR Resources as hubs for those interested in these new technologies, developing educational content to explore concepts around decentralized identity, offering guided developer tutorials and videos, and providing documentation and API references. We also unveiled a new website, introduced a novel approach to selective disclosure of verifiable credentials, built and defined a new secure messaging standard, developed a prototype for paper-based credentials to cater for low-tech environments, and made a bridge to extend OpenID Connect with verifiable credentials. We’ve consistently released tools and added features to make our products more secure, extensible, and easy to use. In parallel, we also joined the U.S. Department of Homeland Security’s SVIP program in October to help advance the goals of decentralized identity and demonstrate provable interoperability with other vendors in a transparent and globally-visible manner. Zooming out a bit, our journey at MATTR is part of a much larger picture of passionate people working in collaborative networks across the world to make this happen.

The bigger picture

It has been an incredible year for decentralized and self-sovereign identity as a whole. In light of the global-scale disruption of COVID-19, the demand for more secure digital systems became even more critical to our everyday lives. Start-ups, corporations, governments, and standards organizations alike have been heavily investing in building technology and infrastructure to support an increasingly digital world. We’re seeing this innovation happen across the globe, from the work being done by the DHS Silicon Valley Innovation Program to the Pan-Canadian Trust Framework and New Zealand Digital Identity Trust Framework. Many global leaders are stepping up to support and invest in more privacy-preserving digital security, and for good reason. Recent legislation like GDPR and CCPA have made the role of big tech companies and user data rights increasingly important, providing a clear mandate for a wave of change that promises to strengthen the internet for the public good. This provides an incredible catalyst for all the work happening in areas such as cryptography, decentralized computing and digital governance. Just in the last year, we’ve seen the following advancements:

• Secure Data Storage WG created at DIF and W3C to realize an interoperable technology for encrypted and confidential data storage
• Decentralized Identifiers v1.0 specification reached “Candidate Recommendation” stage at the W3C, establishing stability in anticipation of standardization later this year
• Sidetree protocol v1.0 released at DIF, providing a layer-2 blockchain solution for scalable Decentralized Identifiers built on top of ledgers such as Bitcoin and Ethereum
• DIDComm Messaging v2.0 specification launched at DIF, a new protocol for secure messaging based on Decentralized Identifiers and built on JOSE encryption standards
• Self-Issued OpenID (SIOP) became an official working group item at the OpenID Foundation, advancing the conversation around the role of identity providers on the web
• Google’s WebID project started developing features to allow the browser to mediate interactions between end-users and identity providers in a privacy-preserving way

For more information on how all of these technologies are interconnected, read our latest paper, The State of Identity on the Web.

In addition, as part of our involvement with the DHS SVIP program, in March of this year we participated in the DHS SVIP Interoperability Plugfest. This event saw 8 different companies, representing both human-centric identity credentials as well as asset-centric supply chain traceability credentials, come together to showcase standards-compliance and genuine cross-vendor and cross-platform interoperability via testing and live demonstrations. The full presentation, including demos and videos from the public showcase day, can be found here.

These are just a handful of the significant accomplishments achieved over the last year. It’s been incredibly inspiring to see so many people working towards a common set of goals for the betterment of the web. As we’ve built our products and developed alongside the broader market, we’ve learned quite a bit about how to solve some of the core business and technical challenges associated with this new digital infrastructure. We’ve also gained a lot of insight from working directly with governments and companies across the globe to demonstrate interoperability and build bridges across different technology ecosystems.

Launching MATTR VII

We’ve been hard at work making our decentralized identity platform better than ever, and we’re proud to announce that as of today, we’re ready to support solutions that solve real-world problems for your users, in production — and it’s open to everybody.

That’s why we’re rebranding our platform to MATTR VII. Inspired by the seven states of matter, our platform gives builders and developers all the tools they need at their fingertips to create a whole new universe of decentralized products and applications. We provide all the raw technical building blocks to allow you to create exactly what you have in mind. MATTR VII is composable and configurable to fit your needs, whether you’re a well-established business with legacy systems or a start-up looking to build the next best thing in digital privacy. Best of all, MATTR VII is use-case-agnostic, meaning we’ve baked minimal dependencies into our products so you can use them the way that makes the most sense for you.

Starting today, we’re opening our platform for general availability. Specifically, that means if you’re ready to build a solution to solve a real-world problem for your users, we’re ready to support you. Simply contact us to get the ball rolling and to have your production environment set up. Of course, if you’re not quite ready for that, you can still test drive the platform by signing up for a free trial of MATTR VII to get started right away. It’s an exciting time in the MATTR universe, and we’re just getting started.

We’re continuing to build-out features to operationalize and support production use cases. To this end, in the near future we will be enhancing the sign-up and onboarding experience as well as providing tools to monitor your usage of the platform. Please reach out to give us feedback on how we can improve our products to support the solutions you’re building.

We’re excited to be in this new phase of our journey with MATTR VII. It will no doubt be another big year for decentralized identity, bringing us closer to the ultimate goal of bringing cryptography and digital trust to every person on the web.

Follow us on GitHub, Medium or Twitter for further updates.

Why we’re launching MATTR VII was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

The rise of OpenID Connect

The core of modern identity is undoubtedly OpenID Connect (OIDC), the de-facto standard for user authentication and identity protocol on the internet. It’s a protocol that enables developers building apps and services to verify the identity of their users and obtain basic profile information about them in order to create an authenticated user experience. Because OIDC is an identity layer built on top of the OAuth 2.0 framework, it can also be used as an authorization solution. Its development was significant for many reasons, in part because it came with the realization that identity on the web is fundamental to many different kinds of interactions, and these interactions need simple and powerful security features that are ubiquitous and accessible. Secure digital identity is a problem that doesn’t make sense to solve over and over again in different ways with each new application, but instead needs a standard and efficient mechanism that’s easy to use and works for the majority of people.

OpenID Connect introduced a convenient and accessible protocol for identity that required less setup and complexity for developers building different kinds of applications and programs. In many ways, protocols like OIDC and OAuth 2.0 piggy-backed on the revolution that was underfoot in the mid 2000’s as developers fled en-mass from web based systems heavily reliant on technologies like XML (and consequently identity systems built upon these technologies like SAML), for simpler systems based on JSON. OpenID built on the success of OAuth and offered a solution that improved upon existing identity and web security technologies which were vulnerable to attacks like screen scraping. This shift towards a solution built upon modern web technologies with an emphasis on being easy-to-use created ripe conditions for adoption of these web standards.

OIDC’s success has categorically sped up both the web and native application development cycle when it comes to requiring the integration of identity, and as a result, users have now grown accustomed to having sign-in options aplenty with all their favorite products and services. It’s not intuitively clear to your average user why they need so many different logins and it’s up to the user to manage which identities they use with which services, but the system works and provides a relatively reliable way to integrate identity on the web.

Success and its unintended consequences

While OIDC succeeded in simplicity and adoption, what has emerged over time are a number of limitations and challenges that have come as a result of taking these systems to a global scale.

When it comes to the market for consumer identity, there are generally three main actors present:

1. Identity Providers
2. Relying Parties
3. End-Users

The forces in the market that cause their intersection to exist are complex, but can be loosely broken down into the interaction between each pair of actors.

In order for an End-User to be able to “login” to a website today, the “sweet spot” must exist where each of these sets of requirements are met.

The negotiation between these three parties usually plays out on the relying party’s login page. It’s this precious real-estate that drives these very distinct market forces.

Anti-competitive market forces

In typical deployments of OIDC, in order for a user to be able to “login” to a relying party or service they’re trying to access online, the relying party must be in direct contact with the Identity Provider (IdP). This is what’s come to be known as the IdP tracking problem. It’s the IdP that’s responsible for performing end-user authentication and issuing end-user identities to relying parties, not the end-users themselves. Over time, these natural forces in OIDC have created an environment that tends to favour the emergence and continued growth of a small number of very large IdPs. These IdPs wield a great deal of power, as they have become a critical dependency and intermediary for many kinds of digital interactions that require identity.

This environment prevents competition and diversity amongst IdPs in exchange for a convenience-driven technology framework where user data is controlled and managed in a few central locations. The market conditions have made it incredibly difficult for new IdPs to break into the market. For example, when Apple unveiled their “Sign in with Apple” service, they used their position as a proprietary service provider to mandate their inclusion as a third party sign in option for any app or service that was supporting federated login on Apple devices. This effectively guaranteed adoption of their OpenID-based solution, allowing them to easily capture a portion of the precious real-estate that is the login screen of thousands of modern web apps today. This method of capturing the market is indicative of a larger challenge wherein the environment of OIDC has made it difficult for newer and smaller players in the IdP ecosystem to participate with existing vendors on an equal playing field.

Identity as a secondary concern has primary consequences

Another key issue in the current landscape is that for nearly all modern IdPs, being an identity provider is often a secondary function to their primary line of business. Though they have come to wear many different hats, many of the key IdPs’ primary business function is offering some service to end-users (e.g. Facebook, Twitter, Google, etc.). Their role as IdPs is something that emerged over time, and with it has surfaced a whole new set of responsibilities whose impact we are only just beginning to grapple with.

Due to this unequal relationship, developers and businesses who want to integrate identity in their applications are forced to choose those IdPs which contain user data for their target demographics, instead of offering options for IdP selection based on real metrics around responsible and privacy-preserving identity practices for end-users.

This cycle perpetuates the dominance of a few major IdPs and likewise forces users to keep choosing from the same set of options or risk losing access to all of their online accounts. In addition, many of these IdPs have leveraged their role as central intermediaries to increase surveillance and user behavior tracking, not just across their proprietary services, but across a user’s entire web experience. The net result of this architecture on modern systems is that IdPs have become a locus for centralized data storage and processing.

The privacy implications associated with the reliance on a central intermediary who can delete, control, or expose user data at any time have proven to be no small matter. New regulations such as GDPR and CCPA have brought user privacy to the forefront and have spurred lots of public discourse and pressure for companies to manage their data processing policies against more robust standards. The regulatory and business environment that is forming around GDPR and CCPA is pushing the market to consider better solutions that may involve decentralizing the mode of operation or separating the responsibilities of an IdP.

Identity Provider lock-in

Lastly, in today’s landscape there is an inseparable coupling between an End-User and the IdP they use. This effectively means that, in order to transfer from say “Sign In With Google” to “Sign In With Twitter,” a user often has to start over and build their identity from scratch. This is due to the fact that users are effectively borrowing or renting their identities from their IdPs, and hence have little to no control in exercising that identity how they see fit. This model creates a pattern that unnecessarily ties a user to the application and data ecosystem of their IdP and means they must keep an active account with the provider to keep using their identity. If a user can’t access to their account with an IdP, say by losing access to their Twitter profile, they can no longer login to any of the services where they’re using Twitter as their IdP.

One of the problems with the term Identity Provider itself is that it sets up the assumption that the end-user is being provided with an identity, rather than the identity being theirs or under their control. If end-users have no real choice in selecting their IdP, then they are ultimately subject to the whims of a few very large and powerful companies. This model is not only antithetical to anti-trust policies and legislation, it also prevents data portability between platforms. It’s made it abundantly clear that the paradigm shift on end-user privacy practices needs to start by giving users a baseline level of choice when it comes to their identity.

A nod to an alternative model

Fundamentally, when it comes to identity on the web, users should have choice; choice about which services they employ to facilitate the usage of their digital identities along with being empowered to change these service providers if they so choose.

The irony of OpenID Connect is that the original authors did actually consider these problems, and evidence of this can be found in the original OIDC specification: in chapter 7, entitled “Self Issued OpenID Provider” (SIOP).

Earning its name primarily from the powerful idea that users could somehow be their own identity provider, SIOP was an ambitious attempt at solving a number of different problems at once. It raises some major questions about the future of the protocol, but it stops short of offering an end-to-end solution to these complex problems.

As it stands in the core specification, the SIOP chapter of OIDC was really trying to solve 3 significant, but distinct problems, which are:

1. Enabling portable/transferable identities between providers
2. Dealing with different deployment models for OpenID providers
3. Solving the Nascar Problem

SIOP has recently been of strong interest to those in the decentralized or self-sovereign identity community because it’s been identified as a potential pathway to transitioning existing deployed digital infrastructure towards a more decentralized and user-centric model. As discussion is ongoing at the OpenID Foundation to evolve and reboot the work around SIOP, there are a number of interesting questions raised by this chapter that are worth exploring to their full extent. For starters, SIOP questions some of the fundamental assumptions around the behaviour and deployment of an IdP.

OpenID and OAuth typically use a redirect mechanism to relay a request from a relying party to an IdP. OAuth supports redirecting back to a native app for the end-user, but it assumes that the provider itself always takes the form of an HTTP server, and furthermore it assumes the request is primarily handled server-side. SIOP challenged this assumption by questioning whether the identity provider has to be entirely server-side, or if the provider could instead take the form of a Single-Page Application (SPA), Progressive Web Application (PWA), or even a native application. In creating a precedent for improving upon the IdP model, SIOP was asking fundamental questions such as: who gets to pick the provider? What role does the end-user play in this selection process? Does the provider always need to be an authorization server or is there a more decentralized model available that is resilient from certain modes of compromise?

Although some of these questions remain unanswered or are early in development, the precedent set by SIOP has spurred a number of related developments in and around web identity. Work is ongoing at the OpenID Foundation to flesh out the implications of SIOP in the emerging landscape.

Tech giants capitalize on the conversation

Although OIDC is primarily a web-based identity protocol, it was purposefully designed to be independent of any particular browser feature or API. This separation of concerns has proved incredibly useful in enabling adoption of OIDC outside of web-only environments, but it has greatly limited the ability for browser vendors to facilitate and mediate web-based login events. A number of large technology and browser vendors have picked up on this discrepancy, and are starting to take ownership of the role they play in web-based user interactions.

Notably, a number of new initiatives have been introduced in the last few years to address this gap in user privacy on the web. An example of this can be found in the W3C Technical Architecture Group (TAG), a group tasked with documenting and building consensus around the architecture of the World Wide Web. Ahead of the 2019 W3C TPAC in Japan, Apple proposed an initiative called IsLoggedIn, effectively a way for websites to tell the browser whether the user was logged in or not in a trustworthy way. What they realized is that the behavior of modern web architecture results in users being “logged in by default” to websites they visit, even if they only visit a website once. Essentially as soon as the browser loads a webpage, that page can store data about the user indefinitely on the device, with no clear mechanism for indicating when a user has logged out or wishes to stop sharing their data. They introduced an API that would allow browsers to set the status of user log-ins to limit long term storage of user data. It was a vision that required broad consensus among today’s major web browsers to be successful. Ultimately, the browsers have taken their own approach in trying to mitigate the issue.

In 2019, Google created their Privacy Sandbox initiative to advance user privacy on the web using open and transparent standards. As one of the largest web browsers on the planet, Google Chrome seized the opportunity provided by an increased public focus on user privacy to work on limiting cross-site user tracking and pervasive incentives that encourage surveillance. Fuelled by the Privacy Sandbox initiative, they created a project called WebID to explore how the browser can mediate between different parties in a digital identity transaction. WebID is an early attempt to get in the middle of the interaction that happens between a relying party and an IdP, allowing the browser to facilitate the transaction in a way that provides stronger privacy guarantees for the end-user.

As an overarching effort, it’s in many ways a response to the environment created by CCPA and GDPR where technology vendors like Google are attempting to enforce privacy expectations for end-users while surfing the web. Its goal is to keep protocols like OIDC largely intact while using the browser as a mediator to provide a stronger set of guarantees when it comes to user identities. This may ultimately give end-users more privacy on the web, but it doesn’t exactly solve the problem of users being locked into their IdPs. With the persistent problem of data portability and limited user choices, simply allowing the browser to mediate the interaction is an important piece of the puzzle but does not go far enough on its own.

Going beyond the current state of OpenID Connect

Though it is a critical component of modern web identity, OIDC is not by any means the only solution or protocol to attempt to solve these kinds of problems.

A set of emerging standards from the W3C Credentials Community Group aim to look at identity on the web in a very different way, and, in fact, are designed to consider use cases outside of just consumer identity. One such standard is Decentralized Identifiers (DIDs) which defines a new type of identifier and accompanying data model featuring several novel properties not present in most mainstream identifier schemes in use today. Using DIDs in tandem with technologies like Verifiable Credentials (VCs) creates an infrastructure for a more distributed and decentralized layer for identity on the web, enabling a greater level of user control. VCs were created as the newest in a long line of cryptographically secured data representation formats. Their goal was to provide a standard that improves on its predecessors by accommodating formal data semantics through technologies like JSON-LD and addressing the role of data subjects in managing and controlling data about themselves.

These standards have emerged in large part to address the limitations of federated identity systems such as the one provided by OIDC. In the case of DIDs, the focus has been on creating a more resilient kind of user-controllable identifier. These kinds of identifiers don’t have to be borrowed or rented from an IdP as is the case today, but can instead be directly controlled by the entities they represent via cryptography in a consistent and standard way. When combining these two technologies, VCs and DIDs, we enable verifiable information that has a cryptographic binding to the end-user and can be transferred cross-context while retaining its security and semantics.

As is the case with many emerging technologies, in order to be successful in an existing and complicated market, these new standards should have a cohesive relationship to the present. To that end, there has been a significant push to bridge these emerging technologies with the existing world of OIDC in a way that doesn’t break existing implementations and encourages interoperability.

One prominent example of this is a new extension to OIDC known as OpenID Connect Credential Provider. Current OIDC flows result in the user receiving an identity token which is coupled to the IdP that created it, and can be used to prove the user’s identity within a specific domain. OIDC Credential Provider allows you to extend OIDC to allow IdPs to issue reusable VCs about the end-user instead of simple identity tokens with limited functionality. It allows end-users to request credentials from an OpenID Provider and manage their own credentials in a digital wallet under their control. By allowing data authorities to be the provider of reusable digital credentials instead of simple identity assertions, this extension effectively turns traditional Identity Providers into Credential Providers.

The credentials provided under this system are cryptographically bound to a public key controlled by the end-user. In addition to public key binding, the credential can instead be bound to a DID, adding a layer of indirection between a user’s identity and the keys they use to control it. In binding to a DID, the subject of the credential is able to maintain ownership of the credential on a longer life cycle due to their ability to manage and rotate keys while maintaining a consistent identifier. This eases the burden on data authorities to re-issue credentials when the subject’s keys change and allows relying parties to verify that the credential is always being validated against the current public key of the end-user. The innovations upon OIDC mark a shift from a model where relying parties request claims from an IdP, to one where they can request claims from specific issuers or according to certain trust frameworks and evaluation metrics appropriate to their use case. This kind of policy-level data management creates a much more predictable and secure way for businesses and people to get the data they need.

OIDC Credential Provider, a new spec at the OpenID Foundation, is challenging the notion that the identity that a user receives has to be an identity entirely bound to its domain. It offers traditional IdPs a way to issue credentials that are portable and can cross domains because the identity/identifier is no longer coupled to the provider as is the case with an identity token. This work serves to further bridge the gap between existing digital identity infrastructure and emerging technologies which are more decentralized and user-centric. It sets the foundation for a deeper shift in how data is managed online, whether it comes in the form of identity claims, authorizations, or other kinds of verifiable data.

Broadening the landscape of digital identity

OIDC, which is primarily used for identity, is built upon OAuth 2.0, whose primary use is authorization and access. If OIDC is about who the End-User is, then OAuth 2.0 is about what you’re allowed to do on behalf of and at the consent of the End-User. OAuth 2.0 was built prior to OIDC, in many ways because authorization allowed people to accomplish quite a bit without the capabilities of a formalized and standardized identity protocol. Eventually, it became obvious that identity is an integral and relatively well-defined cornerstone of web access that needed a simple solution. OIDC emerged as it increasingly became a requirement to know who the end-user (or resource owner) is and for the client to be able to request access to basic claims about them. Together, OIDC and OAuth2.0 create a protocol that combines authentication and authorization. While this allows them to work natively with one another, it’s not always helpful from an infrastructure standpoint to collapse these different functions together.

Efforts like WebID are currently trending towards the reseparation of these concepts that have become married in the current world of OpenID, by developing browser APIs that are specifically geared towards identity. However, without a solution to authorization, it could be argued that many of the goals of the project will remain unsatisfied whenever the relying party requires both authentication and authorization in a given interaction.

As it turns out, these problems are all closely related to each other and require a broad and coordinated approach. As we step into an increasingly digital era where the expectation continues to evolve around what’s possible to do online, the role of identity becomes increasingly complex. Take, for example, sectors such as the financial industry dealing with increased requirements around electronic Know-Your-Customer (KYC) policies. In parallel with the innovation around web identity and the adoption of emerging technologies such as VCs, there has been a growing realization that the evolution of digital identity enables many opportunities that extend far beyond the domain of identity. This is where the power of verifiable data on the web really begins, and with it an expanded scope and structure for how to build digital infrastructure that can support a whole new class of applications.

A new proposed browser API called Credential Handler API (CHAPI) offers a promising solution to browser-mediated interactions that complements the identity-centric technologies of OIDC and WebID. It currently takes the form of a polyfill to allow these capabilities to be used in the browser today. Similar to how SIOP proposes for the user to be able pick their provider for identity-related credentials, CHAPI allows you to pick your provider, but not just for identity — for any kind of credential. In that sense, OIDC and CHAPI are solving slightly different problems:

• OIDC is primarily about requesting authentication of an End-User and receiving some limited identity claims about them, and in certain circumstances also accessing protected resources on their behalf.
• CHAPI is about requesting credentials that may describe the End-user or may not. Additionally, credentials might not even be related to their identity directly and instead used for other related functions like granting authorization, access, etc.

While OIDC offers a simple protocol based upon URL redirects, CHAPI pushes for a world of deeper integration with the browser that affords several useability benefits. Unlike traditional implementations of OIDC, CHAPI does not start with the assumption that an identity is fixed to the provider. Instead, the end-user gets to register their preferred providers in the browser and then select from this list when an interaction with their provider is required. Since CHAPI allows for exchanging credentials that may or may not be related to the end-user, it allows for a much broader set of interactions than what’s provided by today’s identity protocols. In theory, these can work together rather than as alternative options. You could, for instance, treat CHAPI browser APIs as a client to contact the end-user’s OpenID Provider and then use CHAPI to exchange and present additional credentials that may be under the end-user’s control.

CHAPI is very oriented towards the “credential” abstraction, which is essentially a fixed set of claims protected in a cryptographic envelope and often intended to be long lived. A useful insight from the development of OIDC is that it may be helpful to separate, at least logically, the presentation of identity-related information from the presentation of other kinds of information. To extend this idea, authenticating or presenting a credential is different from authenticating that you’re the subject of a credential. You may choose to do these things in succession, but they are not inherently related.

The reason this is important has to do with privacy, data hygiene, and best security practices. In order to allow users to both exercise their identity on the web and manage all of their credentials in one place, we should be creating systems that default to requesting specific information about an end-user as needed, not necessarily requesting credentials when what’s needed is an authentic identity and vice versa.

Adopting this kind of policy would allow configurations where the identifier for the credential subject would not be assumed to be the identifier used to identify the subject with the relying party. Using this capability in combination with approaches to selective disclosure like VCs with JSON-LD BBS+ signatures will ensure not only a coherent system that can separate identity and access, but also one that respects user privacy and provides a bridge between existing identity management infrastructure and emerging technologies.

An emergent user experience

Using these technologies in tandem also helps to bridge the divide between native and web applications when it comes to managing identity across different modalities. Although the two often get conflated, a digital wallet for holding user credentials is not necessarily an application. It’s a service to help users manage their credentials, both identity-related and otherwise, and should be accessible wherever an end-user needs to access it. In truth, native apps and web apps are each good at different things and come with their own unique set of trade-offs and implementation challenges. Looking at this emerging paradigm where identity is managed in a coherent way across different types of digital infrastructure, “web wallets” and “native wallets” are not necessarily mutually exclusive — emerging technologies can leverage redirects to allow the use of both.

The revolution around digital identity offers a new paradigm that places users in a position of greater control around their digital interactions, giving them the tools to exercise agency over their identity and their data online. Modern legislation focused on privacy, portability, security and accessible user experience is also creating an impetus for the consolidation of legacy practices. The opportunity is to leverage this directional shift to create a network effect across the digital ecosystem, making it easier for relying parties to build secure web experiences and unlocking entirely new value opportunities for claims providers and data authorities.

Users shouldn’t have to manage the complexity left behind by today’s outdated identity systems, and they shouldn’t be collateral damage when it comes to designing convenient apps and services. Without careful coordination, much of the newer innovation could lead to even more fragmentation in the digital landscape. However, as we can see here, many of these technology efforts and standards are solving similar or complementary problems.

Ultimately, a successful reinvention of identity on the web should make privacy and security easy; easy for end-users to understand, easy for relying parties to support, and easy for providers to implement. That means building bridges across technologies to support not only today’s internet users, but enabling access to an entirely new set of stakeholders across the globe who will finally have a seat at the table, such as those without access to the internet or readily available web infrastructure. As these technologies develop, we should continue to push for consolidation and simplicity to strike the elusive balance between security and convenience across the ecosystem for everyday users.

Where to from here?

Solving the challenges necessary to realize the future state of identity on the web will take a collective effort of vendor collaboration, standards contributions, practical implementations and education. In order to create adoption of this technology at scale, we should consider the following as concrete next steps we can all take to bring this vision to life:

Continue to drive development of bridging technologies that integrate well with existing identity solutions and provide a path to decentralized and portable identity

• E.g. formalization of OIDC Credential Provider to extend existing IdPs

Empower users to exercise autonomy and sovereignty in selecting their service provider, as well as the ability to change providers and manage services over time

• E.g. selection mechanisms introduced by SIOP and WebID

Adopt a holistic approach to building solutions that recognizes the role of browser-mediated interactions in preserving user privacy

• E.g. newer browser developments such as CHAPI and WebID

Build solutions that make as few assumptions as necessary in order to support different types of deployment environments that show up in real-world use cases

• E.g. evolution of SIOP as well as supporting web and native wallets

Ensure that the development of decentralized digital identity supports the variety and diversity of data that may be managed by users in the future, whether that data be identity-related or otherwise

Taking these steps will help to ensure that the identity technologies we build to support the digital infrastructure of tomorrow will avoid perpetuating the inequalities and accessibility barriers we face today. By doing our part to collaborate and contribute to solutions that work for everybody, building bridges rather than building siloes, we can create a paradigm shift that has longevity and resilience far into the future. We hope you join us.

The State of Identity on the Web was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of decentralized identity and digital trust, there are a variety of new concepts and topics that are frequently referenced, written, and talked about, but rarely is there a chance to introduce these concepts formally to audiences who aren’t already familiar with them.

For this reason, we have created a new “Learn Concepts” series to outline the the fundamental building blocks needed to understand this new technology paradigm and explore the ways that MATTR thinks about and understands the critical issues in the space.

Over on our MATTR Learn site, we have been building out a variety of resources to assist developers and architects with understanding the MATTR universe of tools and products. We are happy to announce we have updated the site to include this new educational content series alongside our existing resources.

Our Learn Concepts series covers the following topics:

• Web of Trust 101
• Digital Wallets
• Verifiable Data
• Semantic Web
• Selective Disclosure
• Trust Frameworks

To facilitate context sharing, each of these Learn Concepts has a distinct Medium post with a permanent URL in addition to being published on our MATTR Learn site. We will keep these resources up to date to make sure they remain evergreen and relevant to newcomers in the space.

We are excited to share what we’ve learned on our journey, and we look forward to adapting and expanding this knowledge base as standards progress and technologies mature.

Intro to MATTR Learn Concepts was originally published in MATTR on Medium, where people are continuing the conversation by highlighting and responding to this story.