Re: DID methods as W3C standards - a happy compromise?

Hi all,

I'd like to apologise up-front for what I suspect will be a long-ish
response to this.  Also I thank you for taking the time to respond to my
previous post on this.

First up, just to clarify my position / motivation in this.  I run a small
(50-ish people) boutique consultancy in Canberra that offers
strategic advice and builds digital stuff for our customers who are mostly
federal government agencies. We do not own any software products ourselves
and are not aligned with any product vendors and so I've nobody's
commercial interests to promote. Everything we've built for our customers
is built on open source and the resulting solution is often open source
itself. Also, like the silent majority in most nations, I trust my
government to act in my interests and protect my privacy FAR more than I
trust the likes of Google, Facebook, Apple, Microsoft, WeChat, Ali-baba,
Amazon, etc. That doesn't mean that I'm keen to give my government all my
data.  The right place for my data is my own encrypted store.  It just
means that, if I have to choose whether to trust advice from big tech or
from my government regarding this new tech then I'll trust my government.

The trigger that got me into this whole VC/DID space was this
https://www.abf.gov.au/newsroom-subsite/Pages/aus-singapore-trial-reducing-transaction-costs-18-08-2021.aspx
and some advice from some colleagues in Singapore that I really should look
at what's going in in W3C VC/DID space. So I did look at it and what I
found leads me to genuinely believe that what you guys are doing could be
transformative. It also potentially solves some pressing problems regarding
digitisation, trust and compliance in cross border trade which is an
immediate focus for me. I'm a strong supporter of your work in the advice
that I give.

But, as I gear-up to give the next round of advice and possibly build some
actual implementations I realise that I'll need to look beyond the specific
open attestation (OA) protocol that underpinned the first trial.  Not that
there's anything wrong with OA, in fact I think it's pretty good and since
OA V3 is VC data model compliant it'll no doubt remain in the toolkit.  But
the issues we are encountering are that

   - anchoring to Ethereum is getting increasingly expensive.  We were
   using it both to register identities and also to notarise transactions.  It
   was ok a few years ago at 20c per transaction but now at $20 per
   transaction it is not commercially feasible. Might be ok for occasional
   registration of issuing entities but not for anything higher volume.  So
   we'll need to take a position on which did methods are good for trading
   parties, which for "things" like consignments, which for major trust
   anchors like government agencies.
   - we are no longer an island and so must be able to verify VCs issued on
   other platforms as part of a supply chain trust graph - which means there's
   did methods used by other platforms that we won't have chosen but still
   part of the verification chain.  So which did methods are likely to see
   uptake and so we should be ready to consume as verifiers?

I did a bit of study of the rather overwhelming list at
https://www.w3.org/TR/did-spec-registries/#did-methods and, although I have
started to form some opinions, I'm also very cognisant of my own
limitations in this space to be confident that my opinions are well
founded. I expect I'm not alone. I think I've more fingers on my hands than
there are people in the world that really understand all the methods and
have well-informed unbiased opinions - and they are all on this mailing
list. Obviously an easy position for a consultant like me to take is "use
these three methods because they are the W3C standard list" - but I
can't do that because there aren't any on that list. Hence my previous
email where I tried to put a stake in the ground.

   - Manu said
*"I wouldn't touch some of the other ones you listed with a ten foot pole
   in W3C standardization space. That you're mentioning them demonstrates that
   you might not be seeing the full picture wrt. the dangers that they bring
   to the ecosystem. :)"*  Thank you Manu - you are confirming that I'm
   correct in my self-assessment that I don't know enough to make truly
   informed recommendations. But how many people really do? How does the CCG
   community expect the wider group of enthusiastic supporters of
   decentralised trust architectures to promote and uptake the work if you
   leave all the risk of wrong decisions to them?
   - Melvin said that the objections to did core aren't well articulated
   and pointed me at
   https://www.w3.org/2019/did-wg/faqs/2021-formal-objections/.  That link
   has this paragraph *"There seems to be general agreement among the
   objectors and DID Working Group that a good future state would be to have a
   handful of “usefully decentralized methods” that are standardized and
   broadly adopted. The challenge is that there is no concrete proposal among
   the objectors or the DID Working Group that would achieve standardizing a
   set of “usefully decentralized DID Methods”.* I can't help sympathising
   with the objectors here.  I don't know how well informed they are but if,
   like me, they are saying "please, dear experts, tell us which few matter
   and can be standardised" and the CCG response is "we won't tell you that,
   you have to instead be more specific in which ones you think should be
   standardised" - then it looks a bit like the experts telling non-experts
   that they have to make up their own mind - "catch-22" springs to mind.

I understand that working group members face a difficult challenge of
keeping the WG membership happy - many of which are there because they do
have a vested interest in this or that platform that might see more uptake
with a widely supported platform specific did method. And, before anyone
objects, I do observe that everyone on this group does a generally great
job of decoupling their employer specific interests from their standards
work which has a much bigger goal. Nevertheless it leaves people like me to
find my own way through the soup. I suspect that very few people will
bother to do this and that many might walk away until some clearer guidance
is available. So the WG has a balancing act - keep the membership happy but
don't make it so hard for the real community of end users that uptake is
stymied by fear, uncertainty and doubt.

Anyhow, as a non-contributing member of this group /mailing list, I
don't have a community to please. But I do have advice to give to my
customers and I'd much rather be shot down early for saying incorrect
things on this mailing list than make some private decisions and build
consequent implementations that turn out to be dumb.* So here's what I
really think about did methods.*  Please draw your weapons and fire at
will...  If you don't want to support or criticise publicly then feel free
to write directly or even call me on +61 410 437854 - your feedback will be
treated confidentially.

   1. For the life of me, I can't see any point in private permissioned
   ledgers of any kind other than as a tool for operators of centralised
   systems to claim some blockchain magic by plugging a bit of blockchain
   software under their private database. It's happening a lot and I think
   it's just snake oil - at some point everyone will realise it and the
   irrational claims of blockchain magic will stop.  In the meantime, I'll
   cross all did methods designed for private permissioned ledgers off my
   list.
   2. Next are the really well established public permissionless ledgers,
   notably bitcoin and ethereum. I'm sure these aren't going anywhere soon and
   so are candidates for anchoring identities. The trouble is that they are
   too expensive and too slow for all but a few use cases of occasional large
   and long term entity registrations. No good for millions of individuals or
   small businesses that each want to create dozens or hundreds of dids so
   that they can isolate concerns and prevent correlations.  Certainly no good
   for "things" like consignments or trade documents where there would be
   billions created per year.  So did methods that directly interact with
   these major ledgers on a 1:1 basis (ie not through side trees/chains) are
   also off my list. The rare cases where they could be useful are equally
   well served by did web IMHO.
   3. Next are the dozens, maybe hundreds of public ledgers based on "me
   too" cryptocurrency ponzi schemes. They might be cost effective
   alternatives to bitcoin and ethereum today but I've no idea whether they'll
   still exist next year and, if they do, whether the cost will still be
   reasonable.  So all of those are crossed off my list.
   4. Next there are the various side-tree / side-chain protocols that are
   anchored to one of the major public ledgers. These are starting to get
   interesting because they potentially have the integrity and durability of
   the big ledgers but are much more scalable and cost effective. So,
   architecturally, they are candidates to be on my list.  But the deciding
   factor here isnt technology but rather governance.  Who is operating the
   side tree? What is the governance model?. What are the detailed legal /
   governance criteria that I should check before adding one of these to my
   list.  The did rubric has some guidance here. So far as I can see there's
   only one.  did:ion makes my list because I "think" I can trust DIF.
   did:elem looks promising because it's kinda the same as did:ion technically
   but for ethereum rather than bitcoin.  But it doesn't seem to have the same
   transparent governance structure so it's off my list for now.
   5. Next there are the various non-blockchain DLTs like IOTA Tangle and
   Hadera Hashgraph. These are interesting because they are public and
   permissionless and, unlike the crypto ledgers, designed from the beginning
   for scalability. I like them in principle because they'll be cost effective
   for the billions of "things" that are part of the trust graph in the
   international supply chain.  Looking past the tech, the same issue of
   governance arises.  Except that if I'm only recommending these platforms
   for the higher volume of shorter lived dids that identify "things" like a
   consignment then there's less risk. Hadera hashgraph has a lot of big tech
   names behind it and some associated promises of longevity and good
   governance.  Since I don't have a high trust in big tech in general, my
   trust in the promises of the hadera hashgraph consortium is also not very
   high. But so long as I make sure it's only used for transient things and
   not for long term personal or business identities then I'll tentatively put
   it on my list for that purpose.  I'll need to dig a bit more into IOTA but
   it might also make my list for the same limited purpose.
   6. Then there's IPFS. In principle I love the idea that the hash of a
   thing is the address of a thing. And that the thing endures because it's
   distributed around various ipfs nodes and so not susceptible to
   accidentally (or on purpose) deleting it off my website. I'm sure it has an
   important role in this ecosystem. Maybe as a place to store encrypted VCs
   that are the targets of links in other VCs (decrypted with some kind of
   OTP) that is available only to verifiers of the source VC. I note that
   there's a half complete did:ipid method. I don't yet have any strong
   opinions on this becasue I haven't quite figured out how IPFS and IPLD
   ideally fits in the architecture. so this did is neither off nor on pending
   further research. if anyone has some strong views one way or the other id
   love to hear them.
   7. Finally there's the very short list from the previous email which
   have nothing to do with a specific ledger.  did:key, did:web, and did:dns
   are on my list but for different purposes that suit the specific method.

So, in short, if I were asked today about which did methods to use I'd say:

   - If you are a large entity with a well known and trusted domain and the
   capability to maintain well known end points on your web infrastructure for
   a very long time, then use did:web as an issuer DID.  Basically this is
   only for governments and large corporates or global authorities like ICC or
   UN.
   - If you are a well known brand and your domain name matches your brand
   and you want to link your did to your brand identity then use did:dns.
   - for all other entity registration (individuals, small businesses, any
   privacy preserving non-correlating did) then use did:ion.
   - for all "things" for which you want to attach a resolvable and
   verifiable id and also attach additional metadata via the properties of the
   did document model, use did:hedera or did:iota
   - for all remaining temporal (short lived) use cases where all you
   really need to do is to prove ownership of the did, then use did:key.  A
   lot of use cases fit this one but no need for me to detail them

so that's my short list /decision-tree and it covers all the use cases I
care about.  No doubt there's glaring mistakes in my logic and some
important omissions and so on.  So please shoot me now.  As I said, I'd
rather have my mistakes exposed now than after some implementation.

kind regards,

Steve

On Wed, 23 Feb 2022 at 01:43, Manu Sporny <msporny@digitalbazaar.com> wrote:

> I agree with much of what Markus has said. It may seem like a "simple
> matter
> of...", but given the debates that have been raging in the DID WG over the
> past two years, it's anything but that.
>
> Asking W3C to standardize most DID Methods is the equivalent of asking W3C
> to
> "Standardize Microsoft SQL Server" or "Standardize MongoDB". I'm sure all
> of
> us can appreciate why doing such a thing would be misguided.
>
> There are a few DID Methods where we can probably all agree that
> standardizing
> the DID Method favours no one... for example, did:key is probably the
> easiest
> one to drop into that category.
>
> did:web could probably be done as well, as long as some of us can hold our
> nose wrt. favouring the current commercial and governmental interests that
> run
> both the Certificate Authority systems, the browser vendors that impose
> their
> will wrt. "valid" and "invalid certificate authorities, and the commercial
> interests that run the global DNS root servers and other name server
> infrastructure.
>
> So, even did:web is controversial to some... I wouldn't touch some of the
> other ones you listed with a ten foot pole in W3C standardization space.
> That
> you're mentioning them demonstrates that you might not be seeing the full
> picture wrt. the dangers that they bring to the ecosystem. :)
>
> On 2/22/22 6:32 AM, Steve Capell wrote:
> > Of course “web” or “dns” is a technology but nobody could reasonably
> claim
> > that you are preferencing some specific commercial interests
>
> Oh, if only that were true. :) By using did:web or did:dns, you are
> preferring:
>
> * A government's ability to secretly MiTM your did:dns
>   record; there are national firewalls that do a great
>   job at this today.
>
> * A government's ability to take those identifiers away
>   from you by coercing hosting and DNS providers.
>
> * A corporations ability to take those identifiers
>   away from you if you don't serve their commercial
>   interests (leasing identifiers).
>
> Now, I don't personally hold the positions above for all use cases, but I
> do
> find them logically sound.
>
> Standardizing DID Methods is more fraught than it may seem at first,
> second,
> or third glance.
>
> Now, a generalized HTTP API for DID operations... that might actually have
> a
> fighting chance at W3C and result in broader interoperability than just
> picking a few winners. I believe Markus is already working on some
> variation
> of that now.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>

-- 
Steve Capell