Re: Cross border identity use case - which did methods?

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