- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 6 Mar 2022 09:24:02 -0500
- To: public-credentials@w3.org
Steve, I didn't read your entire email (again, not enough time)... but it is a space our company plays in, so take the following for what it's worth (advice which you should be sceptical of): On 3/5/22 9:12 PM, steve capell wrote: > 3. * did:key wont work. this did is likely to be longish-lived (years) > and, if compromised will expose too much fraud opportunity. Remember that governments currently manage keys that 1) have lifespans of many years already, and 2) are stored in HSMs that don't export the key. Yes, the second item requires the HSM to be secure, but there are technical and operational audit programs that have done a pretty good job over the past two decades. If you can tie the did:key to an HSM, and there are some of us that are working on this, you should be able to trust a did:key's association w/ a supply chain entity. Yes, you don't get key rotation, but all Issuers need to keep block lists of bad actors, and they all need to map their internal database entries to DIDs (if they go this route). All this to say, you don't absolutely need key rotation (though it is a nice property to have IF you have complete trust in your production DID Method). > Also, the simplest way to make the wanted correlation to the AEO VC is > probably via a did document service end point. Never publish via a DID Document service endpoint what you can communicate with a VC. Digital Bazaar is coming to the conclusion that service endpoints were probably not a good idea for the use cases it was envisioned to be used for. That doesn't mean it's useless, just that we should've used VCs to address most of the "service endpoint" use cases. > * did:web could work. But there are millions of businesses with an ABN. > some dont have websites other than a facebook page. Some will have websites > but may not have the maturity to maintain a highly available end point for > their did document. Others might be put off by the IT effort to get setup. > Some might be just fine with did:web. For those entities, did:key that is provably tied to an HSM is also an option. > If an exporter has already chosen a service (eg ION) and created a did and > then asks their regulator to issue the AEO VC to his/her did:ion - should > the AEO VC issuer refuse? They have to be allowed to refuse if the DID Method has not passed the clearances that they require. I suggest that the current DLT-based DID Methods that some governments are using have certainly NOT been properly vetted and as a result, we're seeing Governments setting up and running their own DLT infrastructure (which is equally concerning -- though, a valid way to approach the problem). There are a lot of operational controls that governments want to see on their DID Methods -- SOC-2 certification, ISO 27001 certification -- these are multi-thousand to multi-million dollar certification programs that require constant and regular audits. No DLT that I know of has passed those certification programs. Many are unlikely to because the certification programs were created in a way that did not contemplate DLTs and many of the people writing the DLTs have never had to go through the multi-year horror of these certification programs. > So most likely that government website for AEO certificate issuing would > need to say "bring your own did - here's the methods we support". That's what we're seeing in the US and EU. > did:key could not be on that list for this purpose (for others yes but not > this use case. I wouldn't be so sure... I think did:key is still in the running there. The x509 certs used today for mutual auth are non-rotatable and in many cases, aren't verified to be held in an HSM. It is true that makes did:key not much better than an x509 cert today, but it does translate the story behind did:key to be one that's compatible w/ government regulated interactions with private industry. > So should that suite list only did:web? or is there a short list of > others? Again, I suggest did:web and did:key are in the running. You don't have to bring the entire industry along all at once. If only the big participants move to this new mechanism, that can have many billions of dollars in savings as a result of faster supply chains. > If that gets some uptake, wouldn't it be unreasonable for a government to > refuse it as a subject did in "bring your own did" method ? Governments have no problem refusing things after a decent baseline has been set. I expect governments might, for the next 5-10 years say: "Nah, just did:key and did:web are good enough for us (for this particular use case)." Remember, many of the larger governments feel like they have all the time in the world to plan 10-50 years into the future. > The broader generalisation of this question is : "for trust anchors like > governments that issue VCs to their constituents, what rules should govern > which did:methods they should accept as the *subject* identifier for the > VCs they issue?" Are those rules context specific? The rules are context specific, and they're not going to be settled for years. Many of us are actively working w/ large and small governments to come up with an acceptable list. The DID Rubric has helped us help those governments navigate these waters: https://www.w3.org/TR/did-rubric/ > should I take it off my list pending a bit more maturity (eg that azure > service goes out of beta into full production)? or is it safe enough for > this use case? if so what others would also be "safe enough"? No thanks, I don't want that sort of target drawn on my back. :) I'll just double-down on my suggestion that there isn't a single DLT-based DID Method that is ready, today, for production use. At least by saying that, I'm being equally negative across the entire DLT-based DID Method industry (even though I really do believe in the future of that industry). We don't want to suggest that the industry is at a certain level of maturity, when it isn't. Any suggestion given at this point won't be data driven (usage, standards conformance, CVEs/year), it'll just be marketing driven. You're going to have to wait for real audits on these DLT-based systems, real deployments (with real data), real CVEs, etc. -- 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 Sunday, 6 March 2022 14:24:20 UTC