The 4 Layer Digital Trust Infrastructure Stack

The 4 Layer Digital Trust Infrastructure Stack

Thursday 15I

Convener: Drummond Reed & Scott Perry

Notes-taker(s): Drummond Reed & Ben Gregori

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes received from Drummond Reed:

This session was given by Sovrin Governance Framework Working Group chair Drummond Reed and SGFWG member and Sovrin Trust Assurance Framework author Scott Perry.

The framework for the session was this diagram, which is based on Appendix D of the Sovrin Glossary (see link for image to Appendix D)

The first part of the session was focused on explaining the four layers in this diagram, and how they depend on the one below. For detailed explanation see Appendix D of the Sovrin Glossary.

The discussion then moved to the fourth layer, the layer where trust in verifiable credentials is established when those credentials need to be relied upon by verifiers that do not necessarily have any direct business relationship with the issuer. We talked about the five distinct roles at this layer (all explained in depth in Appendix H of the Sovrin Glossary). 

At that point we moved to interactive discussion of many topics related to governance frameworks and these five roles. Some of the questions asked and answered were:

- Q: How do we promote good behavior and privacy practices at layer 3? A: By specifying the rules for issuers, holders, and verifiers in governance frameworks and promoting their use.

- Q: How many governance frameworks are expected at layer 4? A: While it might look like just a few (e.g., credit card networks), we believe there will be thousands or tens of thousands over time, because they will be of any size and complexity for any trust community that needs one.

- Q: Are all the roles at layer 4 needed? A: No, different governance frameworks will need different roles. 

- Q: What will typically be covered in a domain-specific governance framework? A: The "BLT sandwich": business, legal, and technical policies covering: a) what credentials and claims are covered, b) who can issue them under what policies, c) who can hold them under what policies, d) what policies apply to verifiers, e) legal policies and requirements, and f) technical specifications.

- Q: What are early examples of domain-specific governance frameworks? A: CULedger is developing one for MyCUID, a global digital credential of credit union membership which will probably be the first KYC-backed digital credential. DignifID is developing the DignifID Animal Guardianship Framework to establish best practices for SSI for pets. Truu is developing a governance framework for doctors credentials in the UK.

- Q: What is required to create a domain-specific governance framework? A: The Sovrin Governance Framework Working Group has just formed a DSGF Task Force to build templates and provide assistance. You can contact us via the Sovrin website.

Drummond and Scott finished by inviting all attendees (and all IIW note readers) to join the Sovrin Governance Framework Working Group if you are interested. It is open to anyone interested in business, legal, and technical policy or governance frameworks.

***************** ***************** ******************* *******************

2. Notes received from Ben Gregori:

Largely: this model is analogous to SSL (URL at base, connection between browser and server, SSL, and the certificate authority

1. Why do we think that Public Ledger Layer, Agent-to-Agent Layer, and Credential Layer technologically distinct?
2. Why do we think that layer 4 (Governance Framework) is less developed? What exists in this layer, and what is the role of trust issuance (the classic function of auditors will fulfull in this infrastructure)
   • Trust Anchor
   • Credential Registry
   • Governance Authority
   • Auditor
   • Auditor Accreditor
3. We can’t deliver value to the market until the Governance layer is understood
   • In a particular application of SSI, Credit Unions are the issuer and can only issue credential if it is KYC’d. Now, even though that is valuable for the credit union, the assertion of KYC approved will be useful to many other organizations, and they want to charge verifiers for the ability to use their credential for other business uses. Moreover, that organization shouldn’t have to interact in any way with the issuing credit union. So it needs a credentialing template for that domain specific governance frameworks.
   • Trust communities of any size will interoperate (cities, churches, etc) based on the governance framework – standardize the roles so that any trust community can crop up and fill the roles of trust anchor, credential registry, governance authority, etc). Perhaps not all of these will be used based on the scale and application (British Columbia doesn’t have all of these), but these are all possibilities.

The reason why the layers are separated:

• DID layer: anything that refers to a persmissionless or permsissioned blockchain that comprise of a DID network (many different DID networks that issuers can root within). DID networks are roots of trust, but the term “trust anchor” is at the top. Need for clarification of terminology. But there will be different networks at a base level (foreign government, foundations) – it acts as the plumbing and does not discriminate (it like the transport layer?), and will not seek to interpret human trust. Its like URLs

Why wouldn’t consortiums bifurcate and trifurcate? Network effect. Is it therefore in the best interest of these mobile wallets (who are all devising SSI systems) to collaborate and build a governance framework and become a network of credentialing authorities that become the trusted network? Maybe. Applicable in higher education, banking networks, etc. You could even create a DID for the governance framework in the credential to verify that a certain credential complied with a preapproved governance framework that had the support of an audited industry.

To avoid an Aadhaar system, how do you specify which credentials are appropriate for verifiers to use? We use a governance framework and enforce it (regulation, legal, normative, institutional – it can also be rules within a domain), whereby more specific use cases will develop their own rules that are domain specific).

Governance is also important as tech/frameworks evolve. GDPR and creating permanent DIDs fly in the face of GDPR rules even though SSI aligns strongly with spirit of GDPR. Sovrin is going to the EU Commission specifically to see how they can accommodate the governance.

Ex. Visa is a governance stack (private) – requires all participants play by the rules, and to do that tthey bring in credited auditors to ensure that participants are playing at the same level, or fulfilling their obligations and roles.

-start up in Seattles that automate policy decisions by translating policies to data governance implementation. “Salesforce for Compliance” and Dignify.

Scenario:

4. Assuming some new mobile wallet comes out, just the process of taking a physical credential into a digital credential in which a specific COMPANY is the issuer, it has earned millions of funding. This is before looking at the human trust level.

https://sovrin.org/library/sovrin-governance-framework/

- Labels in blue and green blocks should be something more abstract. Certain networks may not need a blockchain.

1. Eg. TSA created the rules for Global Enrollment, which uses a card (Layer 2) to confirm the credential and its given by TSA or other authority (Layer 3) which is governed by TSA/Homeland security (L4).

a. This analogy needs more applications of this TSA credentials outside of flying. DHS is working on that (Customs and Border Protection, TSA and others, find on silicon valley innovation team website)

5. The framework goes from a single identity (L1) to verifying ID between two people, trust of the few (L3) to trust of many (L4)

Governments will be instrumental in building the governance frameworks, but they won’t be the ONLy one. Credential Registry exists specifically because of the cryptography involved with verifiable credentials. The holder is the subject of the credential. But you need to hold someone elses credential (like your child’s healthcard). To get the infrastructure started, went to government issuers (corporate registries) and then used government as the single holder of verified credentials (already public) and issue the relevant credential to a holder. This is how British Columbia kickstarted this chicken before egg scenario.