Key Points

References

Jim's Trust Concepts - What if I told you .. Trust Fuels the World

https://www.axios.com/trust-crisis-government-business-media-2e614f4b-0bc4-4f3b-97ea-5eac34ea09fc.html

Trust Engineering Questions for a Solution

Trust Questions to ask for a use case

Trust Engineering Questions for a DLT

• Are there multiple independent parties in the system?
• Yes
  DTCC and it’s clients are independent entities who will use ION
  
  
• Are there multiple content writers?
• Yes
  DTCC manages the marketplace
  Clients will update their metadata and view post-trade settlements
  
  
• Is there counter-party risk between parties?
• Yes
  The parties in the market do not automatically trust each other
  As market manager, DTCC needs to build trust with better governance and operations proofs
  
  
• Is data provenance important?
• Yes
  In a securities market ensuring the accuracy of the data and verifying identity of the owner and data creator is critical where high volumes and expensive assets are stored and traded
  
  
• Is regulatory compliance important?
  • Yes
    Securities post-trade settlements are a regulated process by the SEC
    DLT can provide data provenance to support regulatory compliance audits

Trust Engineer a use case to find required proofs

Key DLT features create a proof system

Essentially a blockchain system is a system of proofs. Not all solutions clearly require all the proofs a blockchain offers. Other solutions like a simple, centralized, secured database application or service may fit enough of the proofs required. As a solution architect, review each of the use case requirements and identify which proofs are specifically needed for that use case.

Often, if a DLT Solution is engineered correctly, the new solution can improve trusts between parties or in some cases, eliminate the trusts needed.

Look at the DLT features below. If some of these features are important and they aren’t addressed in your solution now, adding the right DLT services may improve your solution. Like databases, there are many types of DLTs. Not all DLTs support all of these features. For Enterprise DLTs, most of the features below are supported in some fashion.

1. Ledger - proof transactions not changed since write by smart contract
   provides a historically accurate record of every transaction state that has occurred
   1. different strategies exist to prove data hasn't changed on a ledger:
      store the whole transaction, update a world state, store a transaction hash, store a transaction json doc etc
2. Distributed - proof data has been shared to authorized parties
   each organization has direct access to it’s authorized data from the DLT
3. Decentralized - proof the DLT governance is shared by authorized members
   Governance of a DLT network can be centralized or decentralized to fit the specific use case. With decentralized governance, control and management responsibilities are shared by multiple parties.
4. Secure protocols - proof transactions not tampered with during processing
   ensures bad actors can access transaction data in flight or at rest
5. Signed transactions - proof who created transaction and who approved a transaction
   verifies the authorized account that signs a transaction showing who created it.
   A witness may validate the transaction signature.
   Added signers allowed for multi-party signatures
6. Transaction Validation - proof transaction was independently validated
   Some DLTs allow flexible endorsement policies by multiple validators or endorsers. DLTs also support different methods for reaching transaction consensus. Some consensus methods add significant overhead reducing transaction performance for those networks compared to others using different methods. Replay attacks are prevented ( the “double spend” problem).
   1. Validation can include validation of related master data in a transactions ( eg the order.customerNumber is valid for an active customer )
7. Smart Contracts - proof reads and writes to the ledger enforce business rules
   authorized user can execute a smart contract to create signed ledger transactions that is reviewed and approved by the assigned network validators before its committed reducing significant data threats from bad actors. On transaction finalization, the contract can return a result and / or fire an event to listeners depending on the DLT platform.
   Smart contracts can also query ledger transactions relatively efficiently.
8. Smart Contract events - proof business events shared to event listeners
   Smart contracts on better blockchains can support the event listener pattern.
   A contract can add application event listeners.
   When the event is fired in the contract, the event is sent to the event hub and distributed to the event listener applications.
   This allows automated integration of contract processing with dependent applications..  
   
9. Transaction Life Cycle - proof a write transaction was approved, committed
   DLTs have custom transaction life cycles. DLTs don’t normally use blocks or consensus for transactions.
   Blockchains will cover these basic steps on active ledger hosts:
1. Submit a proposed transaction from an application to a smart contract
2. Validate the transaction inputs
3. Execute the transaction generating outputs
4. Verify the transactions is correctly created
5. Order the transaction output into a transaction block ( blockchain only )
6. Add the block to ledger
7. Return a transaction and block ID to the client application indicating the transaction has been posted to the ledger successfully or an error
8. Send an event on the transaction result
10. Publish transaction events to subscribed consumers
    Proof subscribed consumers were notified of transaction events so they can respond appropriately
11. Private Data -  proof only authorized parties can see data
    only authorized accounts can view the transaction details on the DLT ( eg a buyer and a seller can see a trade but no one else has access to the trade details )
12. Private Data Selective Disclosure - proof minimal data shared to meet verification requirements
    1. Prove you are over 21 to order alcohol.  Verifiable Credential can use selective disclosure to show birth date ( vs all data on a physical drivers license )
       or ( even better ) use a zero-knowledge proof to prove you are over the legal drinking age without disclosing any personal data including birth date
13. Event message history for producers, consumers
    Proof that events were: published by a producer, received by a listener in order
14. Permissioned Access - proof that authorized parties only have access to DLT
    for Secure Financial Systems. At a minimum, registered users have  accounts with assigned public and private keys. Authentication methods may include access to the private key and or MFA ( Multi-Factor authentication methods ).
15. Token Transfers - proof buyer, seller conditions were met on contract execution
    Larger platforms are adding flexible support for custom tokens with policy and privacy support for many token operations ( issue, redeem, transfer ). 
16. CQRS - proof who read data if requests logged ( blockchain or log )
    Command Query Request Separation proves who read the data separately from the party that wrote the data
17. Encrypted Data Store - proof data at rest required keys to read
18. Encrypted Data Transmission - proof data in flight required keys to read
19. Secure Enclaves - proof that data in process was protected from access by other entities or processes
20. Authentication - proof that a party correctly identified themself to a verifier 
21. Authorizations - proof that a party has been granted rights to access resources
22. Logs - proof of what was processed and the result based on log level
23. DID - Decentralized Identifier - digital proof of identity issued by a party that can be automatically digitally verified
24. VC - Verifiable Credential - digital proof of a credential ( a degree, an authorization, a role etc ) issued by a party  that can be automatically digitally verified

Trust Engineering Example for DLT

see >  

For more details see slide 9 here:

https://docs.google.com/presentation/d/1dpzLBkx8MaOdzq_W5d246WCWizJ3QLQ6fugIvItXLQo/edit#slide=id.p9

Fabric event listener implementations

https://hyperledger-fabric.readthedocs.io/en/latest/search.html?q=events&check_keywords=yes&area=default 

Event listener info on Fabric v1.4

https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-listening-to-events.html

Add events in Fabric video

https://www.youtube.com/watch?v=KLWLCjKf5Xw

Lessons NOT yet learned on Trust 

• You don't build trust by discrediting others
• If you want to be trusted be transparent and generous with your first-hand source data, limit your opinions and analysis
• Censorship never leads to trust regardless of what other impacts it has
• Invite more to share their ideas and find areas of consensus and opportunity

Trust Over IP Concepts, Services, Architecture Overview

The TOIP model

The Trust Over IP Interactive Model

https://trustoverip.org/wp-content/toip-model/

Proof of Governance Services often operate at the Application Layer

ToIP Foundation produces a wide range of tools and specifications, organized into five categories:

• Specifications to be implemented in code
• Glossaries to be incorporated in other documents
• Recommendations to be followed in practice
• Guides to be executed in operation
• White Papers to assist in decision making.

TOIP Governance Work

• Governance Architecture Specification V1.0 (PDF)
  This is the core specification for the interoperability requirements for ToIP-compliant governance frameworks. (Note that it references the Governance Metamodel Specification as a subset; see below.)
• Governance Metamodel Specification V1.0 (PDF) and Companion Guide V1.0 (PDF)
  A subset of the ToIP Governance Architecture Specification, this specifies the required, recommended, and optional components of a ToIP-compliant governance framework document set.
• Risk Assessment Worksheet Template V1.0 (Excel) and Companion Guide (RACG) V1.0 (PDF)
  A guided template to help complete a ToIP recommended Risk Assessment in advance of a governance framework construction.
• Trust Criteria Matrix Template V1.0 (Excel) and Companion Guide V1.0 (PDF)
  A container to organize and operationalize the accountability of governance framework mandates.
• Trust Assurance and Certification Controlled Document Template V1.0 (PDF) and Companion Guide V1.0 (PDF)
  A starter shell for the production of a ToIP-approved trust assurance framework.
• Governance Framework Matrix V1.0 (Excel) and Companion Guide V1.0 (PDF)
  A structure to evaluate, define and operationalize governance objectives, structure, process, and incentives for ToIP solutions.

TOIP Governance Stack Workgroup

https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group

VON Use Case - BC Gov Verifiable Organizations Network

BC OrgBook Case Study

https://www.hyperledger.org/wp-content/uploads/2019/03/Hyperledger_CaseStudy_OrgBook_Printable_V1.pdf

bc-von-bc-hyperledger.org-OrgBook Case Study Hyperledger gdrv

OrgBook github

https://github.com/bcgov/TheOrgBook

OrgBook Search Page

https://www.orgbook.gov.bc.ca/en/home

BC Digital Government

https://digital.gov.bc.ca/

BC Digital Transformation Actions & Objectives 

https://digital.gov.bc.ca/digital-transformation

bc-DG-plan-digital.gov.bc.ca-Digital Transformation gdrv

BC Digital Transformation Standards and Guides

https://digital.gov.bc.ca/standards-and-guides

BC Service Design Guide

https://www2.gov.bc.ca/gov/content/governments/services-for-government/service-experience-digital-delivery/service-design/service-design-in-the-bc-public-service

bc-dg-stds-service-design-playbook-beta.pdf  uploaded

bc-dg-stds-service-design-playbook-beta gdrv

BC Web Design Component Guide

https://developer.gov.bc.ca/Design-System/About-the-Design-System

BC.GOV FAQS

OrgBook is a "community verifiable credential wallet/holder" for credentials about businesses. 

The BC Services Card app is centralized and has a multi-week/month process to onboard new issuers. 

Bluink app is vendor app, scans the document, detects data, and matches the document image to create a credential

Verified.Me has the banks storing the credentials on a private (across banks) instance of Hyperledger Fabric

Key Concepts

Stephen Curran's TOIP presentation - 

toip-economics-of-digital-trust-von-team-2020.pdf

https://drive.google.com/file/d/1zegONePbGglTscCNdjrqjg-MSGkHagvE/view?usp=sharing

1. toc
2. economy scale digital trust
3. trust is broken on the internet
4. do you trust buying a house, admitting a student, helping a Nigerian Prince based only Internet data?
5. paper credentials proved - who issued it, what the credential is, who holds it, claims are not changed
6. in person trust - do they look believable?
7.  >> we learned from covid that health outcomes are secondary to data privacy, will digital identity be any different?
8. digital credential proves:  who issued it, who holds it, claims are not changed, credential not revoked
   1. do you trust the issuer?  governance
9. get sample credential - https://vonx.io/how_to/confbook
10. get sample safe entry credential - https://vonx.io/safeentry  for covid entry 
11. dual stacks in toip  — governance and technology
    1. layers >   DID utilities >  DIDcomm p2p >  issuers, holders, verifiers, wallets > apps ( enter a bar )
12. your credentials in a wallet, not on a blockchain
13. zero knowledge proofs or control over credential provide selective disclosure to verifiers
14. credential proofs are recorded on blockchain to proof they have not been changed
15. possible use cases
    1. logins  >   safe entry  >  id for licensed orgs > professional credentials >  authorization credentials > voting 
16. related stds:  w3c did, claims, credentials 
17. more

VON Conference Book demo 

https://vonx.io/how_to/confbook

https://drive.google.com/file/d/1Z7kLWUNg-EdidnWPfLMLX36R9BCG-WRV/view?usp=sharing

VON Safe Entry demo 

https://vonx.io/safeentry/

SafeEntryBC is a contact-less way to manage the risk of service providers coming into a space you control. As we gain a better understanding of the science, people could have a set of credentials (whatever those might be) to help manage that risk. Think of SafeEntryBC as a replacement for the “Visitor’s Log” you saw in many businesses in the old days (you remember, back in January 2020). With SafeEntryBC, instead of writing down your name, company and date of visit, you are sent a real-time request for a set of (digital) credentials that you must present that are suitable for mitigating the risk of you entering the facility. In some places, that might be just your name and the company for whom you work. In high risk locations, such a request might include asking for a credential about your COVID-19 status—perhaps a recent “negative” test or (if/when such a thing becomes available) an immunity credential.

SafeEntryBC is not a surveillance program to monitor and record the activities of the population in a central database. It uses a technology (“verifiable credentials” —see a very brief backgrounder here) that provides you with the digital equivalent of the paper credentials we use every day, credentials like your drivers licence. For service providers (or anyone) to gain entry to a SafeEntryBC controlled-access location, they acquire from various issuers the credentials they need in their digital wallet before arrival, and when entering a facility, scan a QR code to transmit proof they possess the set of credentials required by the facility. A “gatekeeper” (likely a person, but it could be a device) monitoring the access point decides to allow or refuse entry based on the presented information.

Ready to see what SafeEntryBC might look like in person? Follow these links to see the participants in the scenario and a guide to navigating the prototype.

Digital Trust Seminar Series 

https://drive.google.com/file/d/1OpB-nj6dSitIdyTIIfkKF2Ybgbi3Yw9N/view?usp=sharing

For individuals, groups and organizations, trust is the foundation of every relationship, decision or action we take. Literally, trust is the fuel that society runs on. This series looks at some of the key innovations in the world of digital trust.

We’ll look at:

• the challenges from our current trust solutions

• new trust models and standards

• actual digital trust solutions and the values they deliver

• software and infrastructure to support these new trust models

• strategies for implementing digital trust in your organizations and networks

We’ll provide background reference document links so attendees can review concepts ahead of time and be prepared. After the presentations, we’ll post the meeting videos and slides as well for reference.

We are fortunate to have some of the world’s leading experts in the field as presenters:

sessions, materials, use cases, methods, tools, technologies, self assessments for orgs, users 

S1 Digital Trust Over IP in Action with the BC OrgBook

This session looks at the Trust Over IP architecture, how it works and the value it can deliver in a real world solution using the Verifiable Organizations Network (VON).

Trust Over IP defines an architecture for Internet-scale digital trust that combines both cryptographic trust at the machine layer and human trust at the business, legal, and social layers. Where possible, existing standards and architectures are leveraged. The Trust Over IP framework supports identities on blockchains as well as peer to peer relations.

The Verifiable Organizations Network (VON) is a community effort to establish a better way to find, issue, store and share trustworthy data about organizations—locally and around the globe. Community partners are using jointly developed software components to enable the digitization of government-issued public credentials—registrations, permits, and licenses. Currently, VON components are based on Hyperledger Indy distributed ledger technology. VON helps by making:

• applying for credentials faster and less error prone

• issuing (and reissuing) credentials simpler and more secure

• verifying credentials more standard, trustworthy, and transparent, anywhere in the world.

The first production services, OrgBook BC, and Ontario's Verifiable Businesses are publicly accessible, open-source, and show what future business permits and licenses could look like. The Global Legal Entity Identifier Foundation has also built a successful identity management prototype using this platform.

S2 Self Sovereign Identity and Decentralized Identity Documents

Trust Over IP and the Verifiable Organizations Network are built on the foundations of Self Sovereign Identity ( SSI ) and Decentralized Identity Documents ( DID ) that define identities and verifiable credentials.

What is a Self Sovereign Identity ( SSI )? We’ve looked at some use cases earlier. Here we’ll cover a few more and look at how the standards for Self Sovereign Identity are defined. We’ll examine how the DID standards implement support for SSI. We’ll also cover more concepts on trust relationships and governance within example domains.

A Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolveable with high availability, and cryptographically verifiable. DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. DIDs are useful for any application that benefits from self-administered, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and identifiers for Internet of Things scenarios. For example, current commercial deployments of W3C Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees.

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies.

The Decentralized Identifiers (DIDs) defined in this specification are a new type of globally unique identifier designed to enable individuals and organizations to generate our own identifiers using systems we trust, and to prove control of those identifiers (authenticate) using cryptographic proofs (for example, digital signatures, privacy-preserving biometric protocols, and so on).

The Sovrin Foundation is a free, public utility that provides Self Sovereign Identities to requesting entities ( people, organizations and “things” ). Anyone can create their own identity on the Sovrin network. You control your identity and it’s permanent. It can’t be taken away. That’s a very important right.

There are also other identity services as well that are based on the DID standards and provide options to create your own identity online.

S3 A Trust Framework: Hyperledger Indy, Aries, Ursa

The Hyperledger project at the Linux Foundation hosts several blockchain-related projects that implement services at Layer 1 and Layer 2 of the Trust Over IP framework.

For Indy, Aries and Ursa, we’ll review the goals for each project, the services provided,

Currently, VON components are based on Hyperledger Indy distributed ledger technology.

Hyperledger Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo. Indy is interoperable with other blockchains or can be used standalone powering the decentralization of identity.

Hyperledger Aries allows trusted online peer-to-peer interactions based on decentralized identities and verifiable credentials. Aries includes a protocol definition, tools, and reference implementations. The Aries protocol supports identities rooted in a variety of distributed ledgers or blockchains. This approach to identity is often called Self Soverign Identity (SSI).

Hyperledger Ursa is a shared cryptographic library. Hyperledger Ursa consists of sub-projects, which are cohesive implementations of cryptographic code or interfaces to cryptographic code.

S4 Engineering Concepts for Digital Trust Solutions

Having covered the Digital Trust Framework, the OrgBook example, details on SSI and DIDs, the Indy – Aries – Ursa frameworks, we’ll look at some useful concepts and considerations for engineering your own digital trust solutions in the context of a few sample use cases. In some cases, we’ll also touch on integration with existing services and identity access management systems.

Our sample use cases include:

Contact tracing which introduces privacy, data correlations, consents and other requirements

Vehicle usage-based insurance that introduces IoT integration, big data, legal considerations

The session will identify options for getting started with Hyperledger frameworks.

S0 Cryptography Fundamentals: Pre-reg to Digital Trust

This session provides an overview of basic cryptographic concepts, related standards ( PKI – Public Key Infrastructure), some related frameworks, key management concepts and some use cases for data-at-rest, data-in-flight and data-in-memory for end-to-end data security. We’ll use the Openssl framework for some examples. Openssl is used in a variety of other cryptographic frameworks ( Ursa, GO Crypto lib etc ). We’ll also look at Putty, another open-source framework for secure data transfers and remote terminal access.

Session 1 - Digital Trust Primer 

Session 2 - Digital Trust Foundations in Hyperledger 

Session 3 - Digital Trust in Action: Verifiable Organizations Network

Session 4 - Digital Trust Interoperability 

Session 5 = Digital Trust Assessment 

Session 6 - Digital Trust Road map 

ISSUER GOVERNANCE REQUIREMENTS GUIDE FOR VERIFIABLE CREDENTIALS - Draft

https://trustoverip.org/blog/2024/04/02/new-issuer-governance-requirements-guide-for-verifiable-credentials-public-comment-needed/

https://trustoverip.org/wp-content/uploads/Issuer-Requirements-Guide-V0.01-2024-01-30.pdf

In a verifiable credential ecosystem, issuers play a crucial role in the issuance and validity of digital
credentials. Verifiable credentials are a type of digital representation of claims or attributes about a
subject, which can be an individual, organization, or thing. These credentials are tamper-evident,
cryptographically secure, and can be verified by relying parties without the need for a central authority.
The responsibilities of an issuer in this ecosystem can be summarized as follows:
1. Issuance of Credentials: The issuer is responsible for creating and issuing verifiable credentials to
subjects based on certain claims or attributes. These credentials are digitally signed by the issuer
using their private key, ensuring the authenticity and integrity of the information.
2. Trust and Reputation: The issuer's reputation and trustworthiness are crucial in the verifiable
credential ecosystem. Relying parties (such as service providers or verifiers) rely on the credentials
issued by reputable and trusted issuers. The credibility of the issuer is established through various
mechanisms, such as being a well-known organization, being part of a recognized authority, or
holding themselves accountable to the requirements of a governing authority.
3. Validation of Claims: Before issuing credentials, the issuer does its due diligence to validate the
claims made in the credential. This validation process ensures that the information presented in the
credential is accurate and can be trusted by relying parties.
4. Verification of Issuer and Holder: Credentials that contain links to the issuer and/or holder must be
built so they can be cryptographically verified.
5. Privacy Considerations: Issuers need to handle personal data responsibly and in compliance with
privacy regulations. They should only collect and use the minimum necessary data required to issue
the credentials and should obtain explicit consent from the subjects.
6. Revocation and Expiry: Issuers must have mechanisms in place to revoke or expire credentials if the
claims become invalid or if the credentials are compromised. This is essential to maintain the
trustworthiness of the digital trust ecosystem.
7. Interoperability: Issuers need to follow standardized formats and protocols to ensure that the
issued credentials are interoperable and can be easily understood and verified by different relying
parties.
8. Auditability and Accountability: Issuers should keep records of issued credentials for audit
purposes, lifecycle maintenance, including updates to claims, or re-issuance for any reason and
revocation. This enables traceability and accountability in case of disputes or issues with the
credentials.
9. Transparency: Public disclosure about how an issuer verifies claims, sources of claims, makes
decisions, how and why it revokes and how it supports validation of authority (as an issuer),
authenticity of the supporting claims and other data is core to establishing trust, including (at some
later evolution) being able to support run-time, on demand proofs.

Potential Value Opportunities

Current Identity and Access Management Challenges 

issues and impacts of identity management now

1. not user centric id
2. not user control over identity and data sharing
3. security risks w cental id mgt
4. fraud in applications
5. data quality
6. consent and compliance challenges
7. data sharing and reuse issues
8. regulatory support - AML, FATCA, more

Blockchain Identity Management Value Opportunities 

#benefits

1. Accurate identity management
2. Improved security
3. Real-time authentication
4. Data control and selective disclosure for principals
5. Simple compliance and audits
6. Data privacy protection including PII data
7. Transaction integrity
8. Automated credentials management
9. Automated Trust relationships
10. Improved consent management
11. Reduced risks on data correlations
12. Legacy systems integration with OIDC authentication

Potential Challenges

Candidate Solutions

Rhode Island Digital Identity and Credentials Solutions

Liz Tanner Overview of Digital Technology Solutions for Government

Liz Tanner Showcase Video.mp4

Liz Tanner Hyperledger Global Forum Session:  Digital Government in Rhode Island presentation

Liz Tanner POC Video:  Digital Identity and Credentials in RI Business Environment Explainer Video

Sybal Proof of Governance as a Service Concepts 

Sybal Web site

https://sybal.io/

Sybal Proof of Governance Explainer Video  - What is POGS?  How does it work?

https://skywebteam.atlassian.net/wiki/download/attachments/2053668882/Sybal%20Video-Explainer.mp4?version=1&modificationDate=1644596263517&cacheVersion=1&api=v2

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles