Re: Call for Focal DID Use Cases

John,

Thanks for the documentation. The context your are describing looks similar to the European context that led to the development of eIDAS, while eIDAS is based on existing digital identity technology and multiple unique identifiers are supported. I personally make a distinction between « legal identity » and « other identity"  created to access digital services.

Natural Person and Legal Entity identity is the responsibility of some authoritative source in a jurisdiction. This is not exactly the same thing as a Twitter account. I am not requesting access to a service, I am registered as a member in a community and as such, I have some rights but also some duties. My autonomy is limited: I can change nationality and register in another community but they are rules to follow (like paying the taxes due before changing). The GDPR « Right to be forgotten » does not apply.

Such identity cannot be entirely « self sovereign » . If SSI/DID is the technology to use, a DID could be created with the « sovereign » authority, and each attribute of the identity could be a verifiable claim issued by the same « sovereign » authority. Whenever Personal ID or Organisation ID are used today, it could also be a VC. This would allow to add value to existing systems without having to change them all.

Service providers, such as banks, could then specify their requirements in term of verifiable claims to be provided.

It should not be too difficult to define an international standard for such « legal » identity for natural person and legal entity, if it focuses only on « who are you?» and not on « do you qualify ?».  The current practice is often to mix both and to assign Identifiers to « the authorized role «  of a legal entity or natural person.
From this international standard for legal identity specifying a set of verifiable claims to be issued by « sovereign authorities » ,  domain specific standard profiles could be specified. A banking profile would, for example, request claims such as name, address, date of birth, gender, country of nationality, country of residence,…, TIN for non-resident….

Unique Identifiers are not the solution but they are a solution to many operational problems:  
Unique identifiers are not managed by a single authoritative source, they are assigned by an authoritative source in a community. In most cases, the unique ID is assigned by a local authority that can easily verify the attributes and control engagement in the community. 
Unique identifiers are used to reference « someone » in a community. It determines how a member of a community is known by the other members of the community. One cannot expect to have multilateral DID between all members in a community
It also allows to retrieve a set of attributes that must be public in a community
Example: When GS1 assigns a GLN (on demand of an organisation), it follows some rules and the GLN can be used by all other members in the GS1 community and outside. All GLNs are published in some register to provide additional information to the community
Unique identifiers are however not digital identifiers. They provide access to information and serve to identify a party in some processes but they are not used to grant access to restricted resources
If unique identifiers such as GLN, DUN, LEI, BIC,… are issued as verifiable claims, we keep the current flexibility while adding the benefits of having digital, verifiable attributes

Stephane


> Le 4 juin 2018 à 00:59, Jordan, John CITZ:EX <John.Jordan@gov.bc.ca> a écrit :
> 
> 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/
>