- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 4 Mar 2022 11:25:01 -0500
- To: W3C Credentials CG <public-credentials@w3.org>
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/
Received on Friday, 4 March 2022 16:25:18 UTC