Cross border identity use case - which did methods?

Hi all,

There's nothing like a concrete use case to focus discussions about which
did method is right for which purpose.  Here's an interesting cross-border
trade use case that, IMHO, can only be solved with VCs & DIDs (ie
centralised / federated models cannot work). This is another long one so
i'll understand if most of you don't bother to read it ;). If just a small
handful of you share interest in this use case then I'm keen to
collaborate.

*Definitions*

   - AEO = "Authorised Economic Operator" - a WCO term for an entity that
   has been accredited by the competent authority in their jurisdiction as a
   trusted trader. (see
   http://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/tools/aeo-compendium.aspx).
   AEOs receive benefits like faster processing, deferred duty, etc from their
   regulators.
   - AEO Mutual Recognition - a bilateral or multilateral cooperation where
   one country accepts the AEO accreditation process of another and so offers
   similar benefits to the exporting country trader - see
   http://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/tools/aeo-mra-strategy-guide.aspx
   .
   - ABN - Australian Business Number - a national identity for any
   business in australia - listed in public registers (
   https://abr.business.gov.au/) and verifiable via a national identity
   provider (https://www.mygovid.gov.au/).  Substitute any other country's
   business registration and verification scheme here...
   - LoC - Letter of Credit - a cross border financial instrument, usually
   issued by the buyers bank that ensures that the seller will receive full
   payment when goods are received.
   - piggybacking - a fraudulent practice where an unscrupulous trader
   pretends to be a trusted trader (AEO) to reduce seizure risk of illicit
   goods.
   - LoC fraud exception - rules about how banks, beneficiaries are
   required to behave in the event of fraud. There are many fraud vectors for
   LoCs and so banks have to go to a lot of effort to mitigate risk - usually
   through very cumbersome and manual verification of trade documents

*The problems / opportunities*

   - Some countries publish their AEO lists and some exchange lists as CSV
   files. This only confirms that AEO-1234 exists, not that the trader really
   is AEO-1234. So AEO schemes, whilst conferring benefits on genuine AEOs are
   also essentially an open invitation to piggy-backers.  Even though most
   countries have some means (eg myGovID in Australia) to identify their own
   AEOs, there's no easy way for them to verify that the other country
   exporter really is the AEO they claim to be. National federated identity
   schemes like "login with myGovID" dont easily cross borders. most national
   IDPs do not allow offshore relying parties - and even if they did it would
   be impractical for exporters to login to various other country platforms
   (often in an un-familar language).
   - There is around $1.5Trillion of un-met trade finance demand - much of
   which is due to difficulties and costs involved in the verification of
   trade documents & identities. If banks could perform "algorithmic due
   diligence" on VCs instead of manual due-diligence on paper then trade
   finance risk and cost would be reduced, opening up at least a good part of
   that un-met demand.

The fraud vectors on both AEO schemes and illicit goods and LoC schemes and
finance fraud are largely about the fraudster pretending to be someone they
arent and about faking trade documents (eg claiming finance of $10M for a
$1M actual shipment). It's not so easy for banks and regulators in an
importing country to confirm the identity of a trader in an exporting
country.

*A VC/DID solution*

   - exporter creates a did:[method]:1234 and associated keypair.
   - exporter "logs in with mygovID" (or whatever their national business
   identity scheme is..) and requests a VC that attests to the well known
   public register identity (eg ABN 4567) of the trader.
   - regulator verifies that the requestor owns did:[method]:1234 and
   issues a VC with did:[method]:1234 as the subject and a well known and
   trusted ID (eg did:web:abf.gov.au) as the issuer.  If the trader is an
   AEO than that claim in in the VC too.
   - exporter can now issue any cross border trade document such as a
   commercial invoice as a VC (exporter is issuer and did:shipment is the
   subject)
   - importer lodges an import declaration to the importing customs in the
   normal way, identifying themselves as the importer.  The importer attaches
   (or references) the commercial invoice VC.  Importing customs can verify
   that the invoice has not been tampered, was issued by did:[?1]:exporter AND
   that this did is identity confirmed by ABF as ABN 4567 who is also an AEO.
   - The importer also requests a LoC from their bank - who can similarly
   and algorithmically confirm that the invoice was issued by the specified
   party and hasn't been tampered with.

The link between invoice VC and the regulator issued ABN or AEO VC can
happen in any of three ways

   1. No link in the VC but the AEO VC is provided by exporter to importer
   and hence to regulator as a bearer token and so importing customs can
   confirm that the invoice issuer is the same as the AEO ceritifcate subject.
   2. The invoice VC could include a hashlink to the AEO VC
   3. The exporter DID document could contain a service link to the AEO
   VC.  This is probably the simplest because once done it's there and nobody
   has to remember to hand over VCs or insert hashlinks.  I'd assume that the
   did created by the exporter would be just for this cross-border trade
   purpose.  they'd use different dids for other non related purposes to avoid
   unwanted correlations.  Obviously the did:exporter to AEO VC is a *wanted
   *correlation ;)

the "trust graph" for this is below.  ovals are entity dids, round edged
squares are "thing" dids, arrows between dids are VCs.  Although the
importer and bank/importing customs could be did, they dont need to be so I
dont show it.

[image: image.png]
Note that we cant use verifiable presentations here becausr the party doing
the presenting (the importer usually) is not the subject or holder or
agency of the subject/holder.  So that invoice VC is used more like a
bearer token.

So - phew - the focussing question:  which did method to use for each of
the three dids here?

   1. exporting customs is probably pretty obvious.  did:web should work
   fine.  It's a large organisation with well established web infrastructure
   and a trusted domain name.
   2. did:shipment is a tricky one but not too critical for this use case.
   Doesn't even really have to be a did. However the next use case I'll
   present (in a separate long email) is about traceability & transparency for
   sustainability claims in long supply chains and will get into did:shipment
   use case more seriously.
   3. So that leaves *did:exporter. *
      - did:key wont work.  this did is likely to be longish-lived (years)
      and, if compromised will expose too much fraud opportunity.  Also, the
      simplest way to make the wanted correlation to the AEO VC is
probably via a
      did document service end point.
      - 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.
      - did:ion or some similar side-tree / ipfs system would work quite
      nicely and, to facilitate boot-strapping, could even be offered as a
      service by the regulator "get your did here - if you don't have one
      already".  But, as Manu and others have said - DLtT anchored dids are
      pretty immature and arguably just not "production ready".

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?  "no, we won't do that because we think you made
a bad choice with did:ion - go get yourself a did:web and we'll be pleased
to give you a VC"..  governments would generally be in a tricky spot here -
they cant be seen to be demanding technologies that exclude some groups
from participation.  Neither can they be seen to be preferring one
technology over another equivalent one.  So most likely that government
website for AEO certificate issuing would need to say "bring your own did -
here's the methods we support".  did:key could not be on that list for this
purpose (for others yes but not this use case.  So should that suite list
only did:web?  or is there a short list of others?  I note that Microsoft
Azure is in public beta with an AD based VC issuer -
https://docs.microsoft.com/en-us/azure/active-directory/verifiable-credentials/decentralized-identifier-overview.
It includes the DIF sidetree.  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 ?

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?

I'm not sure of the answer - but it's why did:ion was on my list - as an
allowed *subject* of a government issued vc - and as the issuer of trade
documents.  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"?

-- 
Steve Capell