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

Using a fresh key pair for every transaction (ie each invoice issued by the exporter) would also require a corresponding fresh identity VC (proof of business registration or AEO status) issued by the customs regulator. So those government issued VCs would be as throw-away / temporal as the transaction keys 

Maybe that’s not a problem - need to think about it 

Anyone else have opinions on this?

Steven Capell
Mob: 0410 437854

> On 8 Mar 2022, at 9:59 pm, David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:
> 
> 
>> 
>> On 07/03/2022 22:10, Steve Capell wrote:
>> 
>> Hi Steve
>> 
>> comments below
>> 
>> Hi David 
>> 
>> Thanks for your considered response 
>> 
>> I agree 100% with your distinction between identity and identifiers.  I also agree that the identifiers that verifiers really care about are the public ones like business registration numbers and DUNS number, not so much random dids
>> 
>> As you point out, this use case depends on dids not really as a meaningful identifier but rather as a means to prove ownership of the public identifier attested by the authority issued VC.  
>> 
>> I think your jwk-uri method can work just as well as a did.  However I don’t really see much difference between that and (for example) did:key.  I think there’s a key (forgive the pun) question here - which relates to the did-issuing strategy of the exporter.  The exporter could :
>> 
>> 1- self issue a did and use it almost like a public identifier - ie long term for multiple purposes with multiple trading partners.  I wouldn’t recommend that at all
>> 2- self issue a did and use if only for the deliberate correlation with the AEO vc.  Use a different did for other purposes.  That’s ok but maybe not ideal
>> 3- self issue a different did (and hence get a separate AEO VC) for each trading partner - but reuse that did for multiple transactions with the same trading partner.  This is the ideal imho 
>> 4- create a new did for every transaction. Doable but involves a lot of hits on the AEO authority which would need an automation interface to be practical.  This one seems like an over-the-top soliton that imposes higher cost with no additional privacy / security benefit 
> This is where I disagree with you. Using long lived keys and VCs requires a revocation mechanism. Using short lived keys does not. This is why OIDC and SAML use short lived claims in preference to X.509 that uses long lived ones. There have been no end of problems with revocation of X.509 certs. So 4 does have significant security benefits over 1, 2 and 3.
> 
> 
> 
>> 
>> If we think of dids this way - ie as a throw away thing that serves to link identity claims then what’s the difference between using did:key (or did:web) as per model 2 or 3 above and using your proposed jwk-uri key pair ? Seems like a case of “same architecture, different protocol”.
> the difference is simplicity of implementation. Performing base64 encoding is easy to do, well supported with tools and ubiquitously known. If you are using JWK you already have the JSON data structure ready to base64url encode
> 
> Kind regards
> 
> David
> 
>> 
>> Kind regards 
>> 
>> Steven Capell
>> Mob: 0410 437854
>> 
>>> On 8 Mar 2022, at 8:39 am, David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:
>>> 
>>> 
>>> Hi Steve,
>>> 
>>> I have followed your posts with interest. Thankyou for sending them.
>>> 
>>> First, I must state that our implementation does not use did's or blockchains. To date, I have not found a use case that needs them. So I am intrigued to find out if your use case below might be the first one.
>>> did:web can simply be replaced by https:// and a well-known name registered with IANA, such as vc-issuer.
>>> did:key can simply be replace by jwk-uri (see my Internet draft for this) assuming you are using JWTs for crypto (which is the most popular mechanism on the web today).
>>> 
>>> Secondly lets differentiate between identifiers and identities. All organisations have a real world identity and they dont need a did or other identifier for this, although they can help. So an organisation can get a national identifier e.g. from Companies House in the UK, or a LEI, or a DUNS number etc. All these identifies can be included in the identity of the organisation, in the VCs that it is given by different issuing authorities.
>>> 
>>> Third, organisations can create key pairs whenever they need them, and should not have to have the burden of keeping them securely in perpetuity. I am sure you are aware that 20% of bitcoins have been irretrievably lost by users losing access to their private keys. So an organisation should not lose its identity by simply losing a key pair. After all, the organisation still exists. Its identity has not been lost.
>>> 
>>> So how does all this fit into your export use case?
>>> 
>>> 1. The exporting organisation creates a temporary key pair, gets an AEO VC containing its identity (with as many attributes as are needed to unambiguously identify it), with the subject id being the temporary public key e.g. using a jwk-uri
>>> 
>>> 2. The exporting organisation can prove to any RP that this VC belongs to it by signing a VP with the private key of the public key subject id (eg. jwk-uri)
>>> 
>>> 3. The exporting org can produce any other VCs that are needed (e.g. cross border trade docs and commercial invoice) and sign them with its temporary key pair and include these in the VP. It can include the IDENTITY of the importer, customer or any other organisation in the VCs it creates. These identities can contain any number of recognised identifiers like DUNS, LEIs etc. so as to unambiguously identify these other organisations.
>>> 
>>> 4. The importing org can similarly get its own VC from the local authority to assert its identity. It can create its own documents (e.g. import declaration) and prove ownership of them all with its own VP. It can reference the identity of the exporting organisation (or any other organisation) in these VCs.
>>> 
>>> 5. Linking between these VCs is done by the identities of the organisations, not via their subject IDs. The subject IDs are only use for proof of ownership of the VCs, by creating VPs signed with this key pair. Subject IDs can change for each shipment. Identities never change.
>>> 
>>> Does this solve your use case. If not, why not?
>>> 
>>> Kind regards
>>> 
>>> David
>>> 
>>> So the exporter creates a short lived key
>>> On 06/03/2022 02:12, steve capell wrote:
>>>> 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
>>>> 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.
>>>> The invoice VC could include a hashlink to the AEO VC
>>>> 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.  
>>>> 
>>>> 
>>>> 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?
>>>> 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.  
>>>> 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. 
>>>> 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
>>>> 
>>> 
>