RE: New member - and (hopefully) an interesting use case - and a question

>the method part of the DID is important for interoperability and, although I can see the value in letting anyone setup a new method,
>there is a risk of explosion - as https://w3c-ccg.github.io/did-method-registry/ seems to already show.
>Looking at this list of methods, I really have no idea what problem each is solving, why there are so many, and whether I should re-use one or create another.

Welcome Steve.

I’ll provide an answer from my context which is >> Public Sector // Issuer of Credentials // Verifier of Credentials


  *   There are many DID methods and corresponding issuance infrastructures for them -- all of them are not equal.
  *   It is incumbent upon an Issuer to understand the security, privacy and interoperability aspects of each DID method they choose to support as a Subject DID for a credential they issue.
  *   It is incumbent upon each Verifier to determine the security, privacy and interoperability aspects of each DID method they choose to support as a Subject DID for a credential they verify
  *   It is incumbent upon each Issuer and Verifier to clearly understand the security, privacy and interoperability implications of the Wallets they will support

My general thinking here (there are nuances) is to treat the analysis you conduct on a DID method, the associated DID issuance infrastructure, and the Wallet with the same rigor you would apply to conducting an analysis of a new type of authenticator.

Do I expect Issuers and Verifiers to white-list a set of supported DID methods?

Yes, In the near to mid-term. I am anticipating this to be enforced via the DID resolver infrastructure the issuer and the verifier considers trusted, either because they are running it internally or because they have done an assessment of an external one.  As an example, if you compare the publicly available Resolver run by the DIF @ https://uniresolver.io/, and the one run by Transmute Industries @ https://resolve.transmute.world/, you will note that each of them support a specific set of DIDs.

In the mid to long term, I expect there to be assessment and certification entities that will do independent assessment of DIDs, DID issuance infrastructure, and Wallets using criteria that will be  developed by (TBD / ?).

Until that part of the ecosystem is more mature, I know that in our case, particularly given the chaff in the air, we expect to do a full security, privacy, interoperability assessment of  any infrastructure that we potentially may use to understand the choices made by that infrastructure provider, and use that information to inform our decision on whether that infrastructure is acceptable for our purposes on the issuance and verification sides.

Best Regards,

Anil

Anil John
Technical Director, Silicon Valley Innovation Program
Science and Technology Directorate
US Department of Homeland Security
Washington, DC, USA

Email Response Time – 24 Hours

[https://www.dhs.gov/science-and-technology/svip]

This document contains pre-decisional and/or deliberative process information exempt from mandatory disclosure under the Freedom of Information Act, 5 U.S.C. 552(b)(5). Do not release without prior approval of the Department of Homeland Security.

From: steve capell <steve.capell@gmail.com>
Sent: Tuesday, May 26, 2020 11:32 PM
To: public-credentials@w3.org
Cc: public-did-wg@w3.org
Subject: Fwd: New member - and (hopefully) an interesting use case - and a question

CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.

Hi W3C Verifiable Credentials & Distributed Identifiers teams..

I have just signed up to the W3C credentials group.  I've been looking at the DID and VC documents because they seem very well aligned with some current initiatives that I am working on with AU government and with UN/CEFACT.

For UN/CEFACT, I am leading three projects:

  1.  https://uncefact.unece.org/display/uncefactpublic/RDM2API - is about taking the core UN international supply chain semantic models and publishing them as JSON-LD contexts and OpenAPI specifications.  Most of the objects in the have an "iD" property which, in the legacy EDI world is represented as a collection of attributes like issuer name, schema name, identifier key, etc.  But in the modern JSON-LD world, these IDs are perfect candidates to become W3C DIDs.  the Ids identify things like parties (consiognee/ consignor), consignments (eg way bill numbers), sea containers, and so on.
  2.  https://uncefact.unece.org/display/uncefactpublic/API+Town+Plan - is a project to create a relatively well organised framework for the ongoing delivery of semantics - basically a business domain & resource model for the semantic concepts in international trade.  Less direct impact with this W3C group except maybe this could define one or more standard DiD methods.
  3.  https://uncefact.unece.org/display/uncefactpublic/Cross+border+Inter-ledger+exchange+for+Preferential+CoO+using+Blockchain - is a multi-channel (ie multi-DLT technology) protocol for government to government exchange of cross-border documents.  The documents are mostly "claims" created by an authorised issuer in the exporting country but need to be trusted by the importing country regulator. A typical example is a "preferential certificate of origin" which is a document issued by a chamber of commerce to certify that the goods in a specific consignment do comply with the terms of a specific free trade agreement - so that preferential duty rates can be applied.  It's one of my types of "certificate" that corss borders today and are almost always paper based (due to the lack of a cross border trust framework). It goes without sating that these documents could be the "subject" of a W3C DID and could contain claims as W3C verifiable credentials.  More info on this project at https://edi3.org/icl/

Current projects

  1.  There is a project to implement a live beta Inter-Government Ledger between Australia and some other countries. The implementation will be open source and is currently building at and https://trustbridge.github.io/

  2.  We imagine the IGL as a kind of channel to exchange linked data graphs as little snippets of the graph presented at different times by different parties as the information becomes available.  for example a certificate of origin is typically issued before the transport is booked - so it can be hard to be sure that the certificate you have in your had is the right one for the parcel you have in your warehouse...  If the chamber submits the CoO and sometime later the exporter of freight forwarder submits the linked consignment data then the system starts to get quite powerful.
My Questions

I'm keen to understand in detail the potential use of the work from this W3C community within these projects.  Superficially they seem like a great fit.  But, as usual, questions surface when digging a bit deeper.  I'll start with just one question.

  1.  the method part of the DID is important for interoperability and, although I can see the value in letting anyone setup a new method, there is a risk of explosion - as https://w3c-ccg.github.io/did-method-registry/ seems to already show.  Looking at this list of methods, I really have no idea what problem each is solving, why there are so many, and whether I should re-use one or create another.  I'd be keen to discuss that problem with someone!
lots more questions but probably best to keep each to separate threads.

I look forward to joining one of your calls shortly.

--
Steve Capell
+61 410 437854



--
Steve Capell