I put that in an earlier post about the W3C Verifiable Credentials meetings and just left it hanging there - sorry!
I’m in awe (mostly) of the technical scholarship of the guys at the W3C Verifiable Creds meetings, but sometimes I detect a mood of gloomy inevitability about the dominance of the big issuers of mobile devices. There’s a feeling they are grimly hanging on to the DID decentralised identity standard in the face of market dominance by Google, Apple and Microsoft, who have been working with FIDO2 and Webauthn standards and Mozilla, who weirdly objected to DIDs to progress with DID. The 1.0 DID standard is nevertheless approved.
However, not everyone (tbh me included) thinks that the DID standard is a necessary part of decentralised, self-sovereign identity or that everything done by Apple, Google, Microsoft or Mozilla is necessarily evil… it depends on how you use it. For me and others, the more important part is agreeing on standards for the verifiable credentials themselves, whether you use DIDs or not. And for me, DIDs are part of a worthy, but long term technical battle.
I think identity is human, not digital, and it’s about community and communities: there’s no such thing as a wholly digital identity. It’s the set of human and social trust protocols, supported by the technology standards or proprietary solutions. Because standards and proprietary platforms are constantly changing, it becomes more a matter of how we use them in a savvy way, to avoid lock-in and potential later exploitation or abuse.
The other problem I have is with coexistence and migration. Or you could say the barrier of ‘network effects’. If i came up with a new phone system, no matter how good, I’d have to recognise that the value of the ‘social graph’ (the network of phone number contact lists) that everyone keeps is a huge barrier to migration to a new system: “oops, it’s empty in here”. Instead, I would be forced to accept the inevitability of using the phone number as a way of helping folks move onto my new system. That social graph is exploited by some (eg WhatsApp/Meta/Facebook) and protected by others (Signal) who provide some assurance that the social graph is cryptographically protected from such exploitation.
The reality is that we live in a world where recognised ‘authorities’ or organisations register us, put us through some process in order to prove we are who we say we are and that what we claim to them is true, and then issue some sort of certificate. They give us a number and stick it on their system. We can’t do much about that, other than insist our privacy and human rights are respected under GDPR: that they don’t ask for, or hold a disproportionate amount of information for the purpose of the ‘certification’. These real world certificates are generally useful to us because the authorities and organisations have done something useful that has some value (and we may have thought it worth paying for).
As a co-op, it’s still useful - or essential - to be able to hook into that wider world of certificates and verification by checking, hopefully once, that the cert is valid and correctly held, and then not have to keep checking again with the issuer, and to keep all the information that goes along with the checking. Coop creds is a network of trust among co-ops to do that simple checking between us, and to then issue simple credentials to our members that can prove to other coops that they hold the certificate. Of course as co-ops there are possibilities for us to issue our own certificates, in the same way: Like a ‘food network member’, ‘approved co-operative carer’ or ‘coop festival event ticket’. These are all possible verifiable credentials we could share and issue amongst us, within that “set of human and social trust protocols” we are working on here at Coop Creds.
Personally I would be happy to accept some compromises on the longer term goals of DID-based inter operability if it meant that we could have and experiment with a user-friendly world of co-operative credentials earlier, yet still avoid being held hostage by the big tech mobile and browser platforms. I think we could take a free ride on what they have done with their own now ubiquitous wallets (Google pay, Apple pay) and the device issuers (Mobile telephone network operators) if we are careful to avoid pitfalls of lock-in by minimising the information we provide to them.
So, in short, I’m asking if there would be any fundamental objections (leaving shortage of time, effort and resources aside for now!!) to exploring this pragmatic exploitation of the wallets for the dominant platforms, alongside what we have set up already.
We could take a closer look at these APIs: