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

thanks manu,

I recognise it was a wall of text - driven by some frustration i'll
admit..  So this response is much shorter.

I thought I was largely very negative about almost all DLT based dids (ie I
said I'd forget about private ledgers and the big public ledgers and all
the various smaller ledgers including veres one). I'm interested (please
maybe) to see that you are even more negative - ie just stick to did:web
and did:key).  To your points

   - Rationale for did:dns was just that it will be inherently much higher
   availability than did:web because it depends on global dns and not on a
   specific website.  Maybe I'm wrong here but i still suspect there might be
   valid use cases for did:dns over did:web.  I dont know yet and maybe you're
   right - just use did web.
   - I should have been clearer about metadata in did documents. Of course
   I would never recommend that any private data or commercially sensitive
   data be put in publically accessible documents.  All I meant was that SOME
   use cases do benefit from the discoverability of further information via
   service end point references. whether the data at that end point is also
   public depends on the use case - for example product metadata keyed via a
   barcode might make perfect sense to be public. maybe even where's my
   consignment information accessible only if you know the
   otherwise un-gessable did these are just reflections of how the world works
   today.  more sensitive data would obviously be encrypted or behind some
   kind of authentication/authorisation.
   - But, once you accept that there are valid use cases for dids that
   identity "things" and usefully offer further service discovery then you are
   a bit stuck if you only limit yourself to did web and did key.  The first
   requires too much website maintenance (plus the identity is a "thing" like
   a consignment and not an entity with a domain name) and the second doesn't
   support service end-points.  So, whilst I accept your point that things
   like did:ion did:iota etc are very early in their lifecycle and
   haven't seen any serious use yet - and therefore should be approached with
   caution, we will still prototype and experiment with them so that we can
   discover for ourselves all strengths and weaknesses and thereby build a
   better informed decision tree on when and how they could/should be used.
   - and, for the same reason, we'll be experimenting with did:ipld which I
   think likely has some promise.

So, I still don't really see a reason to change my list (assuming we are
clear about the mis-communication around private data in public
documents).  But we do have a lot of experimentation and analysis ahead -
particularly to identify and mitigate security concerns.  When we've done
that we'll be pleased to share it here for further criticism - as that's
the best way to avoid silly mistakes.  Also, hopefully goes without saying,
nothing goes into production use without a very solid security assessment &
testing process.

kind regards,

On Sat, 5 Mar 2022 at 03:28, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 3/3/22 7:15 PM, steve capell wrote:
> > 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.
>
> I'm not so sure you received enough feedback to feel certain about any of
> your
> reasoning, Steve. I personally didn't respond because your email had an
> overwhelming amount of information in it with a number of things to take
> issue
> with (and I'm very time poor, so didn't have time to elaborate).
>
> You do seem to know enough to not make catastrophic mistakes in the process
> and adjust as things change in the market.
>
> I'm going to offer some quick thoughts with zero backing argument (because
> I
> don't have the time). I don't want you to walk away thinking your mental
> model
> is correct -- you've got some dangerous thinking going on there.
>
> > 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.
>
> Yes.
>
> > 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.
>
> No, just use did:web.
>
> > for all other entity registration (individuals, small businesses, any
> > privacy preserving non-correlating did) then use did:ion.
>
> Not a single entity I know that's doing production deployments has actually
> vetted did:ion and found it to be production capable.
>
> This goes for /every/ DLT-based DID Method out there -- even the one we're
> working on. I am highly sceptical of anyone that says that /any/ DID
> Method is
> ready for production usage at present.
>
> > 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
>
> DO NOT put metadata in the properties of the DID Document data model. DO
> NOT
> ever put metadata on a ledger other than a simple: "Here's a GDPR-compliant
> endpoint in order to get metadata from the DID Document.". Use Verifiable
> Credentials to transmit information associated w/ the DID Document
> (including
> service endpoints).
>
> Putting anything other than keys in a DID Document requires careful
> consideration and thought that I'm not seeing many of these DID Method
> implementers doing.
>
> > 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
>
> Yes.
>
> I would argue that did:key can be used for more long-term use cases IF you
> can
> prove its binding to an HSM of some kind. IoT is an example of a good
> long-term use case for did:key. Again, I hesitate to give this general
> advice
> because someone is going to misinterpret it and say: "You can use did:key
> for
> ANY long lived use case!".
>
> I think the fundamental flaw in your thinking at present, Steve, is
> trusting
> DLT-based DID Methods too early. They are important, and they'll have their
> day, but not this year... until then, did:key and did:web can carry a lot
> of
> water.
>
> -- 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