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

Hi Joe,

I read your response and thought "great insights, must thank joe" and then
forgot..  So.. Thanks!   for taking the time to respond.

*"**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."* Yes - know about that but yes, it is a fairly big topic for
another thread.  There are couple of perspectives / options

   1. It doesnt matter because the importer is legally bound to the
   importing regulator and the exporter is legally bound the export regulator
   - so it's enough that exporting regulator attestes to identity of the party
   that issued the invoice and the importer attests that this is genuinely
   their supplier.
   2. There is a way to send a key with the physical shipment that can bind
   the exporter to importer via the physical goods.  More on that later.

I'm leaning towards your "automated sub-issuing" model on the question of
non-correlatable dids.

Also very good point about attack vectors for did:web methods other than as
used by the government regulator.

thanks again!

On Thu, 10 Mar 2022 at 05:18, Joe Andrieu <joe@legreq.com> wrote:

> 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>
>
>
>

-- 
Steve Capell