Re: Call for Focal DID Use Cases

A few thoughts on the use of DIDs for corporate identities.

TL;DR: Corporate identities are the graphs of statements.
The purpose of DID and VC standards (as standards for self-sovereign
identities and cryptographically signed statements) is to allow us
(society/government) to create, manage and audit these graphs more
transparently and reliably, than by using traditional centralized
identifiers and not-cryptographically signed documents.

To make discussion about the use of decentralized identifiers within
corporate space simpler, it is better visualize corporate identities as
graphs of statements. (See attached image - blue rectangles represent
statements, red dots represent DIDs.)

Mainly these graphs of statements should tell us:
- what assets/liabilities exist
- who owns/controls assets and liabilities (tax, debt and other
responsibilities)
- who has hiring/firing power
- who are the end-beneficiaries

These questions should be continuously answerable with flow of time. In
other words - assets and liabilities should be always owned by someone. At
any point in time, it should be possible to find a human person in the
physical world, who was/is responsible for the actions of corporate
identity.

For illustration of the idea that "identity is a graph" let's look at Yahoo
and try to define and identify Yahoo in 2015 and 2018 (see image attached).


Before we begin, we need to contrast "define" vs "identify".
When we define something - we describe attributes of the entity, that are
the most important in this entity in some context.
When we identify something - we describe/provide unique attribute of this
entity.

In 2015 if you wanted to identify Yahoo you could use exchange ticker
"NASDAQ:YHOO" as unique identifier.
In the context of investments you would define Yahoo as a legal entity that
owns the following assets: 100% yahoo.com (~5B USD), 35% in yahoo.jp (~7B
USD) and 16% stake in Alibaba Inc (~100B USD).
In the context of the brand you would define Yahoo as a legal entity that
owns brand 'Yahoo', yahoo.com and yahoo.jp.
In the context of history you would define Yahoo as a legal entity founded by
Jerry Yang and David Filo in 1994 and that owns yahoo.com.
In 2015 all the the common ways by which you define Yahoo and the ways to
uniquely identify Yahoo, would result in the same legal entity.

In 2018 defining and identifying Yahoo is not that simple.
In 2016 legal entity uniquely identified by ticker "NASDAQ:YHOO" sold
yahoo.com and 'Yahoo' brand to company called "Oath" solely owned by
Verizon and renamed itseld to "Altaba". If you were investor in
"NASDAQ:YHOO" shares in 2015, you would now own shares of  "NASDAQ:AABA"
and have no stake in brand 'Yahoo' and in domain yahoo.com.
Now if you want to define Yahoo using brand context "as a legal entity that
controls brand "Yahoo" and domain yahoo.com" you would get legal entity
"Oath" owned by Verizon.
If you want to define Yahoo using historical context, "as a legal entity
founded by Jerry Yang and David Filo in 1994" you would get legal entity
"Altaba". Funny, right?

The key idea that I want to demonstrate here is – corporate identity is not
just a legal construct identified with some permanent or not permanent,
centralized or decentralized identifiers – it is a graph of statements that
tells us "who owns what" and "who is responsible for what".

Therefore, IMO the central question that "Focal DID use case within
corporate space" should answer is  – "How DIDs and VCs make creation,
management and audit of these graphs of statements more transprent and
reliable across diferent jurisdictions and time?".

Logic and intuition says, that  DID and VC standards will gradually replace
multitude of current national standards and make creation, management and
audit of these graphs much easier, reliable and transparent.






--Bohdan



On Mon, Jun 4, 2018 at 1:59 AM, Jordan, John CITZ:EX <John.Jordan@gov.bc.ca>
wrote:

> 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/docume
> nt/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/autom
> atic-exchange/crs-implementation-and-assistance/tax-identifi
> cation-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-b
> ased-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/
>
>