Table of Contents
MATTR VII is now live!
Pay-as-you-go pricing is now published
- Get a detailed look at how MATTR VII is charged once you elect to upgrade to a paid plan.
- To discuss high-volume discounts, please contact us.
The platform is now known as MATTR VII; URLs and paths updated to reflect this:
- MATTR VII Core is
- OIDC Bridge is a MATTR VII extension found at
Old domains and paths will be discontinued from service within 30 days
Customers can use their tenant to construct and send messages to holders based on their subject DID, which will be delivered to the MATTR Wallet app and notified via a push notification.
- Construct action-based messages in a DIDComm2 JWM format:
- Start a credential issuance using the OIDC Bridge.
- Notify of a credential revocation status change.
- Start a verification flow using a callback.
- Encrypt messages intended for the recipient.
- MATTR VII enforces end-2-end encryption (E2EE), so message contents are never visible to MATTR when held in messaging inboxes.
- Route messages to a dedicated inbox for the wallet user.
Further messaging capabilities are scheduled on the roadmap.
Further functionality to support the use of privacy-preserving credentials using BBS+ signatures.
- Use a query extension to the Verifiable Presentation Request Specification format, Query by Frame, to specify required credential claims.
- Trusted Issuers and Credential Types are used to match credentials in the mobile wallet.
- The latest version (v0.50.0) of the Mobile Wallet is required to process Query by Frame presentation requests.
- ZKP-enabled credentials using BBS+ signatures can be used to derive selectively disclosed presentations.
- New UI screens to actively show the disclosure of claims.
- Update to the Callback URL for all Issuers on the OIDC Bridge to align with future changes.
Ensure that the allowed callback URL for your federated provided is updated with the new path. From
When we first launched the Platform we pioneered the bridging of existing identity solutions using Open ID Connect (OIDC) to a new world of decentralized identity and verifiable credentials. During this time we listened to customers as well as working within the Community as standards evolve. This latest version of the OIDC Bridge is now easier to set up, more flexible to integrate and conforms with OIDC Credential Provider for issuing credentials to the mobile wallet.
- Multiple OIDC Credential Issuers can be enabled to offer credentials using the OIDC Configuration metadata endpoints
scopescan be added to Federated Providers to enable more flexibility in obtaining ID token claims
- OIDC Credential Verifier are easier to set up and associated OIDC Clients can be listed and updated
- Authenticate a DID using OIDC Bridge introduces a new way for OIDC Clients to obtain a Subject identifier that has been verified to come from the holder.
- Claim mappings; OIDC claims > JSON-LD terms and JSON-LD terms > OIDC claims have been revamped to simplify their use and make it clearer on how they are used by the OIDC Bridge
- Unlocks Verifying a Credential using a Callback method to allow non-OIDC verification
- Introduction of a new endpoint to Verify a Credential directly using the API
- In line with the W3C VC Data Model; Subject identifiers are now not required on Create Credential, usually a Subject DID makes up a core part of a Verifiable Credential but in some cases it makes sense without one, such as issuing a ‘bearer’ style credential e.g. a concert ticket or when the credential is to be stored on behalf of a subject and reissued later with subject binding.
- The format of the response from /.well-known/did-configuration is now in a JSON-LD format. Learn more about the Well Known DID Configuration from the Decentralized Identity Foundation working group.
This changes means all holders will need to being using the MATTR Mobile Wallet with a minimum version of
v0.37.1to continue to receive and present credentials, earlier versions of the app will present a generic error message.
Credentials issued on the platform are now revokable and searches can be performed on the Credential Registry.
- Create Credential has new optional
revocableproperty to create a Credential as revocable using a revocation list method.
All Credentials issued using the OIDC Bridge are now revocable by default.
- Management API endpoints for an Issuer to toggle the revoke status of a Credential.
- Provisioned hosting of revocation lists for Credential Issuers.
- Automatic verification of a presented Credential against its revocation list will result in revoked credentials being returned with an error message in the OIDC/OAuth2 callback response back to Verifiers/relying parties.
- Credentials optionally held in the Credential Registry can now be retrieved by
- The meta-data of non-persisted Credentials can also be found using these tags.
All Credentials issued using the OIDC Bridge will only store meta-data.
- Pagination on Retrieve List of DIDs and Retrieve List of Presentation Templates now has pagination using the cursor-based method.
New DID method
did:web is available to be created on the Platform.
- Check out the new DID Web tutorial on how to implement this style of DID.
- Further content on the various DID methods available on the platform is available.
- Enhanced pagination on the List Credentials endpoint, moved from using a page-offset pagination to a much more performant cursor-based pagination.
Support added for issuing privacy-preserving credentials using BBS+ signatures.
ZKP-enabled credential functionality during Preview are considered experimental and may change over time as well as any ZKP-enabled credentials issued during this period may need to be reissued.
- Create DID now has options to set a key type (only for
did:keymethod at this time).
- Use the BLS key type
bls12381G2to create Issuer DIDs for issuing ZKP-enabled credentials.
- Response for Resolve a DID has been altered to include a
localMetadataparameter which will be used for future DID methods.
- Create Credential will automatically issue ZKP-enabled credentials if an issuerDid referencing a
bls12381G2key type is provided.
- New optional parameters are available on Create Credential:
- Providing a value in
tagwill set this value as metadata so it can be referenced on the platform later.
- Setting the
truewill store the created credential on your tenant for future retrieval. The default value is not to store credentials.
- Providing a value in
- Mobile Wallet App bug fixes and improvements.
- Improved support for OIDC query parameters on mobile app authorization requests.
Creation of Sov DIDs on the platform is now possible.
- Create DID can be used to create DIDs using the Sovrin DID method. Note during Preview these will not be anchored on the Sovrin MainNet.
- Resolve a DID will resolve Sov DIDs including MATTR issued ones.
- Tidy up of error response messages on Create Presentation Templates and messaging endpoints.
New endpoints available.
- A cloud-hosted, multi-tenanted environment that can be spun-up on-demand using managed containers
- Authentication and access-control provisioning
- Auditing and privacy-preserving logging
- Cryptographically secure issuance of Verifiable Credentials (VC) to authenticated identity holders
- Configuration options to;
- Bring-your-own OpenID Connect Provider (OP)
- Or, use our step-by-step tutorial for a reference OP
- Map personal information claims from source to VC terms, using linked-data standards
- Decode a JWT signed using a Decentralized Identifier
- Optionally; store issued credentials on-platform to be retrieved (for non-sensitive use-cases)
- Create a credential Offer as a QR code or deep-link to start the issuance flow with the mobile wallet app
- The static offer is ready to display on a website or physical media e.g. a bus shelter advertisement
- Cryptographically secure verification of VCs from identity holders after their consent
- Uses the latest standards-based messaging protocols (JWM) to transmit information from the holder
- Configure an OpenID Connect Relying Party client to accept holder information via a standard ID token
- Map personal information from Credential claims to a standard ID token
- Create a VC Request and embed using a QR code or deep-link into a journey
- The dynamic request can be used in an information-gathering flow e.g. Customer onboarding
- Native iOS and Android apps, supporting a range of models and devices
- On-device biometric access enabled
- Familiar chat-like user-interface approach, designed with core pillars of privacy, accessibility and user-experience
- Puts the user in control during issuance and verification of their Credentials
- Keeps user in-context with in-app-browser technology
- Interoperable to published specifications within the Self-Sovereign Identity ecosystem
- Theming options available to prospective customers