Issuer, verifier and wallet implementation

For BOC1 Resonate used a dockerized issuer, a dockerized verifier and an app supplied by Verifiable Credentials Ltd. This required a fair bit of additional setup and was too provider specific.

We need to decide what issuer and what verifier tech we want to deploy, i.e. an off-the-shelf provider, open source or develop our own.

To start, here’s the w3c-ccg reference implementation:

Some verifiable credentials providers:

Mattr has some useful reference implementations

See also Verifiable Credentials with Auth0 and MATTR

1 Like

I have had an enquiry from these guys, who are reapplying for the Essif lab infrastructure call…

Mainly of interest for their experience, commitment to an open source toolkit approach and their (new) wallet Introducing the Credible Wallet | Spruce Developer Portal

…but they are also of interest for their work on ID across multiple blockchains…

We could extend the co-operative ecosystem with a ‘commons’ of SSI-aligned membership that includes (appropriate) crypto communities and potential access to alternative, non-conventional funding instruments. (There is still a lot of money with blockchain whales who are having co-operative ‘epiphanies’)


Popping this here

1 Like

Also need to read this… the SIOP stuff that looked ‘too hard’ a while ago may be maturing now? David Chadwick has been looking at this.

OpenID Connect for Verifiable Presentations


This specification defines an extension of OpenID Connect to allow presentation of claims in the form of W3C Verifiable Credentials as part of the protocol flow in addition to claims provided in the id_token and/or via Userinfo responses.

1. Introduction

This specification extends OpenID Connect with support for presentation of claims via W3C Verifiable Credentials. This allows existing OpenID Connect RPs to extends their reach towards claims sources asserting claims in this format. It also allows new applications built using Verifiable Credentials to utilize OpenID Connect as integration and interoperability layer towards credential holders.

This specification enables requesting and delivery of verifiable presentations in conjunction with Self-Issued OpenID Providers (see [SIOPv2]) as well as traditional OpenID Providers (see [OpenID]).


Czech firm Avast acquires evernym.

Congratulations on implementation of the MATTR wallet for applications! I managed to generate a credential on the ancient android device that serves as my mobile unit.

I feel lucky to have circled back through the community this morning to find this update.

I’d like to put some energy into upgrading the ‘song purchase’ credentialing service developed for Resonate in 2021 to the MATTR wallet.

Can someone here provide any leads for where to start? Does Resonate hold a license to develop MATTR implementations? Is this necessary?


Hey @richjensen, sorry for the slow reply. I’ve now added a complete description of the CoopCreds stack here:

Going down this track would require significant technical investment, but if you’re keen for Resonate to develop their own credential, copying the CoopCreds stack wouldn’t be a bad place to start.


Wondering if the ‘Open Wallet’ ( effort is of interest as we close in on the end of 2022?

Hi John - yes indeed it’s something we are tracking, but it’s still quite a long road to achieve inter-operability everywhere, so we’re prepared to make some compromises on the way, provided we can intercept the wider and very noble efforts there. There is a looong discussion about this at W3C CCG including some controversy about the downsides of it…

I guess the point is here that we need to be clear on our own short and mid term business goals and then specify (select) a target architecture focused on that, using proven components. The goals should include transition / migration to future ‘global’ inter-op, but should not build in a dependency on it.