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

Thank you everyone that has responded privately to this message.

In general, the feedback was supportive and hasn't led to any significant
change in my list of preferred did methods at the end of the email.  One
thing I will be doing though is taking a much closer look at IPLD and
did:ipid.

That pretty much closes this issue for me.  I've got a bit more confidence
that my thinking isn't completely off the rails.  Whether or not W3C
standardises some did methods, I'm content that I can navigate the options
and, as has been repeatedly suggested, the market will hopefully drive some
consolidation anyway.

kind regards,
steve

On Wed, 23 Feb 2022 at 12:00, steve capell <steve.capell@gmail.com> wrote:

> 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
>
>

-- 
Steve Capell