W3C home > Mailing lists > Public > public-credentials@w3.org > March 2022

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 4 Mar 2022 11:25:01 -0500
To: W3C Credentials CG <public-credentials@w3.org>
Message-ID: <eb9b5de8-302f-4070-2937-3d9cde80cba9@digitalbazaar.com>
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.


> 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


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

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Received on Friday, 4 March 2022 16:25:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:29 UTC