Re: Call for Focal DID Use Cases

Important points Stephane on significantly improving transparency and bringing in the concept of beneficial ownership. This is already part of the legal framework in the EU and Canada has started discussions and is taking initial steps to make the legislative changes needed … which will require all 13 provinces and territories as well as the federal government since registrars are at the Prov/Terr level here.

However, I don’t believe that unique identifiers are the solution for all of the reasons I outlined in the previous email. If you consider the global scale of our problem it become even more unworkable that we could have a single authoritative source for unique identifier issuance. This would require some degree of coordination on simple things like what a legal entity is, how to pay for the global system and all these problems of centralized approach that frankly we already know don’t work. It is not a technology problem … we could easily build such a database … we simply can’t govern it effectively.

So, I believe that the identifier is less the issue .. it is the ability for a verification of verifiable credentials from known trusted (maybe) authorities (the registrars) and some sort of new assertion of beneficial ownership that is also a verifiable credential from an authority or perhaps a known identifiable intermediary like lawyers, accountants , notaries or judges, depending on your jurisdictions legal framework. Here in Canada we are working on a Pan Canadian Trust Framework that has three constructs .. Verifiable Person, Verifiable Organization, Verifiable Relationship.

Here are some definitions that come from various docs some of which are here https://github.com/canada-ca/PCTF


A verified person is defined as knowing (or having a degree of certainty) that an individual is real, identifiable, and has truthfully claimed who he or she is. By contrast, an unverified person is anyone who does not meet these conditions.
Verified Organization: A verified organization is an organization the identity and/or existence of which has been proven or sufficiently substantiated in a given service or transactional circumstance. Verification involves a service provider collecting and confirming information about the organization. Details about these identity and/or existence verification processes are outlined elsewhere in this document. The organization may be considered an unverified organization in other circumstances.

Verified Relationship: A verified relationship is a connection the existence and nature of which has been proven or sufficiently substantiated in a given service or transactional circumstance. Verification involves a service provider collecting and confirming information attesting to the status and characteristics of the relationship. The relationship may be considered unverified in other circumstances (i.e., it is an unverified relationship). The Verified Relationship Component is concerned specifically with verifying or verified relationships that represent the existence of a connection between an organization and its agents or between one organization and another

Bringing these constructs together in a trustworthy digital way is what we are aiming for. That trustworthy way must combine technology that scale globally, AND allow for the actors in the ecosystem (issuers, verifiers, holders, subjects) to establish their human means of establishing trust … which can be through trust frameworks, reputation or perhaps some other means. The point being that trust is established by a combination of social and technical factors.

As we move towards a digital capability to request “proofs” on demand for each and every interaction, and we can create the conditions where we have confidence that the presenter of the proof is holding credentials that attest to their being a legitimate representative of an organization in some capacity, we narrow the gaps that are now plentiful in these hybrid paper/digital world we are in. When these proofs are offerable, we can record audit trails on both sides of the transaction, perhaps have services that offer trustworthy third party storage of receipts, or even legislate certain interactions be registered with a government agency (as we do now with large money transfers). However, I would proposed all these interactions are at the verifiable credential layer … enabled by DIDs … but not tied to them so that the world can evolve in its apparently chaotic way and our digital ecosystems can adapt perhaps even help guide this evolution.

In order allow for these credentials to flow and move, as appropriate, from entity to entity, be that people to people, people to organizations, we think there needs to be DID transfer mechanism which my colleague as put together in a DID use case here https://docs.google.com/document/d/1Jf03G19bVKywaO_PjOJ3cTVtJmDj8-8ZHCacUEWXUHw/edit?usp=sharing

This may offer the ability for the verifiable credentials to flow from DID to DID as appropriate and determined by the issuers of those verifiable credentials. For example, if a permit were to be transferred from business A to business B to the next as a result of an acquisition of A by B .. the permit issuer may require B to prove they are now the owners of A via a verifiable credential from the registrar, and then re-issue the permit to B as B may not be able to prove ownership over the DID that A had used to originally receive the permit credentials.

So .. some ideas to consider here and thanks for raising an important issue that we are very interested in.

Best
J




From: Stephane Canon <stephane.canon@scarlet.be>
Date: Sunday, June 3, 2018 at 8:35 AM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: Call for Focal DID Use Cases
Resent-From: <public-credentials@w3.org>
Resent-Date: Sunday, June 3, 2018 at 8:31 AM

« Correlation » is essential when fighting against financial crime, that’s why OECD has defined the concept of TIN (http://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/#d.en.347759) and imposes reporting to banks (CRS), thanks to « Panama Papers » and similar initiatives.

Most discussions are taking the perspective of « me and and my service provider ». A condition of trust in the digital economy is however to know/discover your potential partners and apply some « due diligence ». This means that the potential counterpart must be identified and also the « beneficial owners ».

To fight efficiently against financial crime, there should no limit, honest people have nothing to hide. The financial ecosystem should be organized in such a way that some trusted parties have access to « a lot » of information and can issue some VCs to be used by those who have restricted access.
When making a transaction, the originating party must identify unambiguously the beneficiary. The originating party could establish a relationship with the beneficiary, verify the claims and instruct the transaction.

The problem is to organise such an ecosystem, much more than inventing the technology. In the meantime, Unique identifiers remain the best solution to improve financial security. A DID is nothing else than a unique identifier but it will take time and all side effects must be analysed: do it make sense to write a DID on a pallet and then, what’s the difference with a GLN?
One could say there is a risk of correlating information with global IDs, but that’s exactly what the controllers in an ecosystem must do.

Note that with DIDs, the problem of data management is just the same: the parties can move, merge,… You might be dealing with DID that no longer correspond to real identities.

Stephane


Le 2 juin 2018 à 20:29, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> a écrit :

On 06/01/2018 03:37 PM, Jordan, John CITZ:EX wrote:

I don’t think we need a single identifier like we have been trying to
unsuccessfully have in some places for years. I feel like those
numbers are a bad side effect of centralized database primary keys.

Agreed.


I think the reason I am quite resistant to a single identifier (if
that is what is being contemplated) for an organization is that in
the real world stuff happens.

It was not what was being contemplated nor proposed, but I can see how
one could interpret the use case as such, so we should make it clear
that organizations/entities are expected to have more than one DID.

I said an "Organization gets a DID"... that doesn't mean its the /only
DID/ the organization has.

This group has identified the "single long lived identifier / single
entity" (e.g. SSN, DUNS, email address for identification) design as a
privacy concern in the VC spec here:

https://w3c.github.io/vc-data-model/#identifier-based-correlation


and here:

https://w3c.github.io/vc-data-model/#long-lived-identifier-based-correlation


We list the "desirable ecosystem characteristics" that we want here:

https://w3c.github.io/vc-data-model/#use-cases-and-requirements


So the change that needs to be made to the Decentralized Corporate
Identifiers use case is:

Clarify that organizations will have more than one DID, typically scoped
appropriately to the interactions that they will perform using the DID.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The State of W3C Web Payments in 2017
http://manu.sporny.org/2017/w3c-web-payments/

Received on Sunday, 3 June 2018 22:59:45 UTC