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

On Tue, Mar 8, 2022, at 11:11 PM, Steve Capell wrote:
> “If you need correlatable identifiers for particular points in the transaction, put that in a VC (with a unique nonce), put a hash of the VC on chain, and send the VC separately.”
> 
> Could you unpack that a bit?

Sure.

> It’s the exporter (did) that needs to prove their identity using a VC issued by a trusted authority (eg a trust anchor such a government) that confirms the DID == public identity. Then the exporter DID issues a trae document such as an invoice 

Right. DID in VC from authority. Then a trade document such as an invoice is issued by that same DID.

> 
> If the exporter DID is ephemeral then the authority issued VC is equally ephemeral because you need a new one for every ephemeral DID.  I’m not sure that the trust anchor will be keen to support that volume of VCs.  
> 
> Or am I missing something in your flow ?

Yes, but only because of run-away thinking (from me and Manu) about anchoring those VCs to ledgers. Which was not part of your initial question, but I'll unpack it a bit, then come back to your fundamental.

Once you anchor something to a DLT, you have a different set of concerns than just VCs, especially because now proprietary and personal data must be avoided in a "permanent" and "widespread" distribution, which folks sometimes call immutable and public. FWIW, I make this distinction because you have the same problem in permissioned DLTs in industrial sectors. Yes you can make a non-public DLT that only, e.g., accredited educational institutions can even see, but all members of that group get to see everything, and if that includes proprietary data, it's in fact most likely that group of peers is precisely who you don't want to see it.

In that case, you can anchor the activity on a timestamped DLT by posting a hash of a VC that represents the activity, without actually revealing the nature of that activity publicly. You can and should do this using ephemeral DIDs so that chain analysis doesn't correlate a bunch of activity with any given actor. Rather, only those parties who receive the VC in the normal course of business are able to know the activity and the parties involved. This separates the on-chain record from the privileged data in the VC.

In your case, you have one authority issuing a VC (the regulator in a particular jurisdiction attesting to a binding between a given DID and a legal identity) and another authority verifying that VC (import / customs officer). FWIW, the biggest flaw in this flow is there is no cryptographic verification between the exporter and the importer, but that's a different thread.

However, in the exact flow you are talking about, it seems that the business requirement is, in fact, that the customs officer can verify that there is a statement from the exporter *as a known entity*. As such, it's the requirement of the system to enable correlation. So, at the end of the day, correlation is the point.

That said, if the VC is going to travel unencrypted through parties for whom correlation is a risk, then you still have two options:
1. the automated sub-issue option
2. the VC about VCs option

Automated sub-issue means allowing the subject of the VC to automatically get a second VC issued to a new DID upon verification of control of the original subject DID. In that case, assuming we can trust the cryptographic secret of the "anchor" DID (and therefore trust that it isn't compromised), then having an automated system is just as secure as the initial issuance. Note that this includes reliance on BOTH the did method's security *and* the did controller's security processes around their keys. But this is essentially the deal with all of these approaches. You have to trust both the method and the controller's processes. However, this won't address your use case *if* the customs agent needs to know not just that the initial exporter has a legitimate record with their jurisdictional regulator, but, in fact, need to know, across multiple interactions that the *same* exporter is involved in a bunch of transactions. If correlation is the business requirement, no amount of anti-correlation techniques are going to work. It's a logical impossibility.

VCs about VCs does not require the issue to do anything else, but it does require the ultimate verifier to understand and accept the semantics in a secondary VC that links the anchor DID to an ephemeral DID (signed by the anchor DID), potentially JUST for a given credential. This sort of delegatability is sometimes called chained VCs and suffers from huge issues with semantic ambiguity, but it is topologically possible. Without extremely limited, rigorous, and standardized semantics, it should NOT be expected that the verifier will accept the secondary VC as meaningful, any more than a bank would be expected to recognize a hand-written note authorizing access to a bank account. However, banks WILL recognize formal assignments of power of attorney, precisely because they have established a framework of semantics that addresses both ambiguity and regulatory compliance. This approach does have the benefit that you can separate the VCs that establish the anchor DID from VCs that use ephemeral DIDs, making it possible to have some set of interactions that are NOT correlatable while still enabling correlation when it is required.

IMO, automated sub-issuing should be the standard practice. If you can get any VC issued to you, there should be an automated way that you can get a second, essentially identical VC issued to another DID, simply by proving control over both DIDs in question. This scale is no greater than a typical website that responds in an automated fashion to browser queries.

I believe that is the long term, scalable solution to your question about how to have optionally correlatable DIDs.

However, your initial question was even more to the point:
> 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?  

This is going to be both contextual and highly regulated, and is arguably the biggest battlefield for DID method adoption.

Its trivial to imagine a DID method that is known to be compromisable by a foreign entity that may have strategic reasons to manipulate DID authority. In particular, did:web anchored to national TLDs are likely NOT going to be a reasonable subject DID for national services. If the government of any country can redirect a did resolution to a DID Document, then they could fraudulently file documentation on behalf of that subject in the country that accepts did:web without limitation.

Personally, I like did:web as an issuer for government issued credentials when the TLD is clearly under that government's control, e.g., .gov in the US, .uk in the UK, etc. I don't recommend it for any subject identifiers for non-government entities because of so many places in the did:web stack where resolution could be redirected inappropriately.

So, we fully expect that every verifier is going to have some sort of allow-list for DID methods they support. In the US, this will likely be federally mandated for federal agencies, so the agencies themselves will have limited choices, likely deferring to NIST or another agency to vet different methods as suitable for subject and issuer identifiers.

We've recently performed a full DID Method Rubric evaluation of did:web and did:ion (and an update of our evaluation of did:v1) that we'll be publishing shortly.  I'll share that here when we release it.

-j

> 
> Steven Capell
> Mob: 0410 437854
> 
>> On 9 Mar 2022, at 1:26 pm, Joe Andrieu <joe@legreq.com> wrote:
>> . If you need correlatable identifiers for particular points in the transaction, put that in a VC (with a unique nonce), put a hash of the VC on chain, and send the VC separately.

--
Joe Andrieu, PMP                                                                              joe@legreq.com
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com <http://www.legendaryrequirements.com/>