Re: Call for Focal DID Use Cases

On Mon, Jun 4, 2018, at 6:00 PM, Stephen Curran wrote:
> A question I have about the use cases that we are trying to collect.
> My understanding is that we are looking for "DID Use Cases".  How
> much should those Use Cases overlap into the Verifiable Credentials
> space?  The discussion on Organizations has been extremely useful
> and interesting, but seems much more focused on conveying verifiable
> attributes vs on DIDs. Simply being able to convey Verifiable
> Credentials between DIDs is a key use case that must be included,
> but should these use cases going deeply into how the VCs are
> subsequently used?
Good question. For better or worse, the VC Use Cases are a separate
document from the DID Use Cases. There is  overlap inevitably, but each
serves different purposes. Not to oversimplify, but the VC Use Cases
should explain why Verifiable Credentials are uniquely value while DID
Use Cases should do the same for DIDs.
Since these technologies support each other, there is an inevitable
bleedover.
I expect the good use cases for each will be something like this:

*VC Use Cases* -- Illustrate the value when any issuer can say ANYTHING
about ANYONE by describing someone in particular saying something
specific about  a certain someone, using cryptographic and procedural
techniques to allow verifiers to confidentally evaluate what has been
said. Complete the picture by showing how individuals can package
various VCs together (including self-issued VCs) for presentation to
verifiers and we tell the story of how people use VCs to assert relevant
facts to verifiers.
*DID Use Cases* -- Illustrate the value when, independent of a central
authority, anyone can create and manage publicly resolvable identifers
and assocaited credentials. Specific benefits include verifiability that
can outlive the issuer, the ability to perform complex key management
without reissuing credentials--thanks to the indirection between the DID
and DID document, and the ability to enhance privacy through myriad pair-
wise DIDs (They're cheap, take three).
To my mind, the clearest benefit is survivability in the face of
administrative or entropic failure. DIDs can be created and used even
when identifiers controlled by traditional authorities aren't
available/reliable/trustable. And depending on the method, the history
of transactions on chain can provide grounded provenance so observers
can tell how the DID's credentials (or the DID document) has evolved
over time.
For example, in the Digital Executor use case, when the probate
mechanism was invoked, it was an on-chain, indelible act. The new keys
now had authority to manage the services related to that DID, AND
verifiers can know by inspection that the reason the new keys have
control is because of an assertion of probate. So the transfer occurs
and the fact of that occurance is part of the permanent record.
*Overlapping use cases*, obviously, involve using DIDs for VCs in
someway. Whichever document one of those shows up in should
highlight how the use of the other tech enhances the core capability
for that document.
For example, you can use DIDs to identify issuers of claims. That's
easy. But then, how do you know that issuer is who you think they are?
You look up the did and there's a service endpoint that resolves to
Nike.com... but that's no gaurantee that Nike.com controls the DID.
Unlike traditional PKI, there's no CA to assert that a DID is actually
owned by Nike or IBM or whoever you think owns it. However, the DID
owner *can* provide evidence, in the form of VCs, which in turn endorse
the conclusion that the DID in question *is* owned by who you think.
That is, VCs where the DID is the subject can be used to evaluate the
trustworthiness of that DID referent as an issuer of particular claims.
I particularly like this when peer attestations can help you resolve
that question: every observer can endorse issuers to build a... wait for
it... a web of trusted identities.
These examples are the kind of things that would be great to capture in
our core use cases. What makes DIDs--as identifiers--more useful than
everything else out there by describing key value-creating transactions
that improve people's lives.

So... that said, my main comment on Bohdan's commentary is that DIDs are
"identifiers" not "identities", which provide one of the building blocks
of decentralized identities. DID Use Cases would do well to distinguish
from the power of decentalized identifiers rather than focus on
decentralized identity.
Unfortunately "identity" is a flash point for many. As we'll talk about
tomorrow, there may be an upcoming workshop to help tease out how
various W3C efforts work with identity and, for good reasons, it will be
a delicate dance to convince detractors that DIDs do something unique
and worthy of W3C support. The more we veer into benefits of
"*decentralized* *identity*" the easier it is for technically savvy
readers to point out that "DIDs don't do that." And they will be right.
DIDs on their own don't solve all the problems of identity. But they do
solve certiain specific problems EXCEEDINGLY well.
The more we can focus on how *decentralized* *identifiers* are
fundamentally different and valuable in the DID Use Case document, the
easier it will be for fellow technologist to evaluate DIDs and decide
for themselves whether or not that highly specific capability is
achievable and/or valuable.
The standardization path for both of these technologies are independent
roads. They must each stand on their own and provide credible, unique
value independent of the other. If we can describe that, we have a good
chance of getting these specs adopted as a standards.
If we invest too much attention in the "big picture" of decentralized
identity, we may well lose the trees because people don't believe in
the forest.
-j

p.s.
Although I do hope to shift the perspective in DID Use Cases away from
"identity", Bohdan is spot on about how these things come together to
provide a new framework for identity. It's just hard to sell that bigger
vision, and hopefully much easier to sell the simpler, more concrete
capabilities of DIDs and VCs separately.
> 
> On Mon, Jun 4, 2018 at 10:59 AM, Bohdan Andriyiv
> <bohdan.andriyiv@validbook.org> wrote:>> 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/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/
>>> 
>> 
> 
> 
> 
> -- 
> Stephen Curran
>  Cloud Compass Computing, Inc. (C3I)

> *Cell: (250) 857-1096*



--
Joe Andrieu, PMP
joe@legreq.comLEGENDARY REQUIREMENTS
+1(805)705-8651Do what matters.
http://legreq.com[1]


Links:

  1. http://www.legendaryrequirements.com