Trustchain: project scope

# Trustchain: project scope Author: Tim Hobson ## Purpose This scoping document attempts to break down the [Trustchain proposal](https://hackmd.io/vRlozTlZSyGgnWhCMqa-mA?view) into a set of activities leading to the production of a working prototype. The work will involve two distinct phases: 1. standards & protocol development 2. prototype software development in addition to a preliminary phase focussed on identifying & clarifying requirements and use cases. ## Phase 0: Requirements and use cases This preliminary phase will involve identifying a set of use cases to be supported by the system, both at the prototype stage and in the longer term. ### Activities - Review the use cases described in W3C standards for [Decentralised Identifiers](https://www.w3.org/TR/did-use-cases/) and [Verifiable Credentials](https://www.w3.org/TR/vc-use-cases/). - Sanity check the use cases described in the [Trustchain proposal](https://hackmd.io/vRlozTlZSyGgnWhCMqa-mA?view). - Consider the issue of transferability (of credentials) & privacy on a per-use case basis, and the potential for incorporating PETs. - Select primary use cases to be included in a first working prototype (developed in Phase II). - Select secondary use cases to be supported by the protocol. - Establish design goals, considering the eight requirements stated in the Goodell & Aste paper: [*A Decentralized Digital Identity Architecture*](https://discovery.ucl.ac.uk/id/eprint/10074541/7/fbloc-02-00017.pdf). - Sanity check the Trustchain proposal itself (taking the form of a Q&A discussion and technical notes). - Scope and de-risk phases I & II. - Review the list of Technical improvements to the Web PKI from the IETF memo entitled [Problems with the Public Key Infrastructure (PKI) for the World Wide Web](https://datatracker.ietf.org/doc/html/draft-iab-web-pki-problems-01.txt). For each suggested improvement, evaluate the extent to which Trustchain would/could contribute to the desired outcome if it were applied in that context. - Brief literature review including: [Tewari (2019)](https://www.researchgate.net/publication/339838338_Blockchain_Research_Beyond_Cryptocurrencies), [Horsfall et al. (2021)](https://www.researchgate.net/publication/352373277_Identifying_and_Supporting_Financially_Vulnerable_Consumers_in_a_Privacy-Preserving_Manner_A_Use_Case_Using_Decentralised_Identifiers_and_Verifiable_Credentials) ### Outputs - Documented use cases, primary and secondary. All primary use cases will have a use case diagram. - Single page of design goals. - Short document analysing known issues with the existing Web PKI from the Trustchain perspective. - Brief literature review. ### Time and resource estimate REG time amounting to 4 weeks FTE. ## Phase I: Standards & protocol development This phase involves identifying the extent to which the semantics of the Trustchain protocol can be expressed using existing standards, and if necessary developing specific extensions to those standards. Two W3C standards are particularly relevant: - [Decentralised Identifiers (DIDs)](https://www.w3.org/TR/did-core/) - [Verifiable Credentials (VCs)](https://www.w3.org/TR/vc-data-model/). The proposal is to build on top of [ION](https://identity.foundation/ion/), which is compliant with the DID standard. It enables public keys (and other identifying information such as domains and API endpoints) to be shared via a *verifiable data registry*, which is realised as a combination of the Bitcoin blockchain and IPFS. What is missing from that standard is a mechanism for linking together DIDs to create a chain of trusted entities. This is where the Verifiable Credentials standard comes in. The two standards are already intimately connected because the proof mechanism, by which a VC is verified, involves performing the *verification method* specified in a DID document, using *verification material* contained in the same document. For instance, the verification material may be a public key, in which case the method is to use the key to verify a digital signature contained in the credential. Our aim is to construct downstream DIDs (dDIDs) which can themselves be verified by confirming that they are signed by an entity represented in an upstream DID (uDID), which is itself already part of a chain of trusted DIDs. In other words, we want to **combine the two standards to create DIDs which are themselves verifiable credentials**. ### Protocol semantics The following properties must be expressible in the extended standard for downstream DIDs: 1. Identity of the upstream entity 2. Revocation mechanism 3. Proof of ownership 4. Permissions granted to the dDID subject. The first two of these can be expressed in the existing DID standard. **Property 1: Identity of the upstream entity.** The identity of the upstream entity is expressible by means of the DID [`controller`](https://www.w3.org/TR/did-core/#did-controller) property (i.e. its value will be identical to the DID [`subject`](https://www.w3.org/TR/did-core/#did-subject) property in an upstream DID). In the existing standard, the DID controller is "an entity that is authorized to make changes to a DID document". Our purpose is different: we want to be able to verify the (downstream) DID itself *in addition to* verifying any subsequent changes that are made to it. However the same `controller` data field appears to be fit for both purposes (with the extension described in Property 3 below). We would also like to be able to specify a set of upstream entities as joint controllers of the downstream DID. This too is [already supported](https://www.w3.org/TR/did-core/#did-controller): > The controller property is OPTIONAL. If present, the value MUST be a string or a set of strings that conform to the rules in § 3.1 DID Syntax. > > When a controller property is present in a DID document, its value expresses one or more DIDs. **Property 2: Revocation mechanism.** This is already part of both the DID & VC standards. However, we shall need to ensure that permission to revoke a dDID is transitive, so that an upstream entity can revoke *any* DID that is downstream of their own (regardless of how many links in the chain separate the two DIDs). Properties 3 & 4 will require extending the standard, and in particular the DID data model. **Property 3: Proof of ownership.** In addition to containing the *identity* of the upstream entity (Property 1), the dDID must also include a *proof* of ownership by that entity. Typically this will be a digital signature, as described in the [VC standard](https://www.w3.org/TR/vc-data-model/#proofs-signatures). This is therefore a natural extension to the DID standard whereby an additional property, that conforms to the existing VC standard, is added to the DID data model. **Property 4: Permissions granted to the dDID subject.** When an upstream entity creates a downstream DID there are different types of permission that they may wish to bestow upon the downstream entities. Support for the following **levels of permission** is required: - Level *0*. Simple attestation of the trustworthyness of the public key(s) in the dDID (granting no downstream permission) - Level *1*. Delegation of permission (to the entities in the dDID) to publish attestation dDIDs. - Level *n* (for *n > 1*). Delegation of permission to publish dDIDs which themselves delegate permission up to level *n-1*. This property is more complicated than the others and does not have any obvious "off-the-shelf" support in the existing standards. It is therefore likely to represent the majority of the development effort in Phase I. It may be appropriate to include Properties 1-3 in a single extension to the DID standard and Property 4 in a separate, further extension. ### Activities - Gain intimate knowledge of the [DID standard](https://www.w3.org/TR/did-core/), a working knowledge of the [VC standard](https://www.w3.org/TR/vc-data-model/) and an understanding of the [did:web method specification](https://w3c-ccg.github.io/did-method-web/). - Review the Trustchain proposal, establish the adequacy of the properties listed above (for the use cases identified in Phase 0) and include additional properties where necessary/desirable. - Understand the mechanism for extending the DID data model, consider the two types of extensibility & determine whether it is possible to take the route of maximum interoperability. - Write an extension to the DID standard along the lines set out above. - Specify precisely how each of the features described in the Trustchain [technical notes](https://hackmd.io/@thobson/SyDELA579) (dDIDs, constrained dDIDs, rebasing, etc.) are to be implemented. - Construct a sample uDID/dDID pair as JSON objects. - Install [ION](https://identity.foundation/ion/install-guide/) and test DID resolution & creation capabilities. Document any features necessary for expressing the Trustchain protocol not currently supported by ION. - [If necessary] Communicate with W3C to begin the process of formally proposing the extension. ### Outputs The main deliverable from Phase I is a fully specified extension to the DID standard incorporating the semantic elements of the Trustchain protocol (described above), and meeting the requirements set out in the [extensibility guidelines](https://www.w3.org/TR/did-core/#extensibility) for that standard. ### Time and resource estimate REG time amounting to 3 months FTE. ## Phase II: Prototype software development A full working prototype will require the development of three distinct software applications: - a **desktop full client** capable of root DID and downstream DID creation, publication, resolution & verification. - a **mobile light client** for users, capable of dDID resolution & verification, and storage & presentation of VCs. - a **mobile client for verifiers**, capable of dDID resolution & verification, and VC verification. Where possible these should share a common codebase, in particular for cryptographic operations. An additional piece of software is needed to demonstrate some of our use cases, namely: - a **VC issuance client** capable of VC generation & issuance (i.e. sharing with the Trustchain mobile client). Since the operation of VC issuance is independent of the Trustchain system, this functionality is likely to come from third party software. Any application that conforms to the W3C standard for Verifiable Credentials should be compatible. **NOTE:** the IETF memo [reviewed in Phase 0](https://hackmd.io/2PkP1XddTTOSi_HKw7iVDg?both) suggests automation of certain processes as a way to improve security. This consideration should inform the functional specification (below) for the full client. For instance, it should include a reference implementation of the challenge-response protocol for verifying possession of private keys. ### Scope of Phase II Phase II is the initial phase of software development and will be limited to development of **core functionality** in a **command-line desktop client**. Further development (graphical desktop interface, mobile clients, verifiable credentials) will take place in a later phase. ### Activities - Select a technology stack for building the three prototype software applications. - Refine and finalise the app specifications (drafted below). - Design a common software architecture to underpin all three applications. - Develop the core library following a test-driven approach. - Develop an initial version of the full client application, based on the core library and with a command-line user interface. - Demonstrate root DID and dDID creation, publication, resolution and verification using the full client. ### Other Activities out of Phase II scope - Add challenge-response functionality for more realistic dDID creation - Extend the full client functionality to support advanced use cases (such as rebasing and interoperability dDIDs) - Develop an initial version of the light client mobile application. - Test dDID resolution and verification using the light client. - Add functionality for VC storage and presention in the light client mobile app. - Develop an initial version of the mobile client for verifiers. - Test VC verification in the mobile client for verifiers. - Test all primary use cases. ### Outputs A working prototype desktop software application supporting the primary core functionality of dDID creation, publication, resolution and verification. A video will be produced to demonstrate the software. ### Software specification (Full client) Architecture: - wraps an ION node and makes calls to its [API](https://github.com/decentralized-identity/ion-tools), which itself wraps a full Bitcoin node. Functionality: Core: (all full nodes) - read parameters from a configuration file - securely generate and manage public-private key pairs - resolve a DID document, given a DID - verify a downstream DID by validating the chain of signatures to the root transaction - verify the timestamp on the root DID transaction - [Out of Phase II scope] prove possession of private keys corresponding to entity's own public keys (i.e. successfully perform challenge-response) --- **NOTE (30/11/2022): Phase II is due for completion by the end of December 2022. The following phases are currently being scoped.** ## Phase III: Academic & popular writing Much of the material needed for an academic paper has been produced in the preceding phases. The proposed timeline for writing up a formal article is Jan-Feb 2023, with internal review during March and submission by end of March. During the first half of 2023 a series of blog posts will be written and published (topics selected from the list below). ### Outputs: - Journal article on the Trustchain concept and prototype software - Series of blog posts selected from the following topics: - Decentralisation in digital ID systems - Selective disclosure and VC use cases - Decentralised Public Key Infrastructure (as a Digital Public Good) - Verifiable timestamping via Proof of Work - Trustchain as a mechanism for realising DPKI ### Time and resource estimate Total: 3 months FTE (REG) ## Phase IV: MVP software development ### Scope of Phase IV Phase IV is the second phase of software development and picks up where Phase II left off. The scope is limited to those functional elements of the system that constitute **an MVP for the pilot deployment(s) in Phase V**. The resource estimates given below are based on the assumption that the Trustchain mobile app will be built as a fork of the [Credible](https://github.com/spruceid/credible) mobile VC wallet (which already provides some of the required functionality). A feasibility assessment will be conducted during December 2022 to test this assumption. Credible supports [standard protocols](https://github.com/spruceid/credible#supported-protocols) for i) receiving a Verifiable Credential and ii) responding to a Verifiable Presentation request. Both protocols assume that both parties in the interaction (the holder and issuer in the first case, and the holder and verifier in the second case) are online. The Trustchain mobile app will *also* support a simple offline protocol for sharing Verifiable Presentations directly between holder & verifier mobile devices, including lossless compression of credentials as demonstrated in the TinyVC feasibility study.  In addition to the VC wallet functionality, the Trustchain mobile app will contain a Bitcoin SPV node (i.e. a light blockchain client that only stores the chain of block *headers*, thereby dramatically reducing storage demands while still enabling transactions to be validated & timestamped by a process known as Simplified Payment Verification). This functionality will be incorporated via one of the existing open source light clients for Bitcoin written in Rust (e.g. [BDK](https://bitcoindevkit.org/) or [Nakamoto](https://github.com/cloudhead/nakamoto)). The Credible, BDK and Nakamoto codebases are available under permissive open source licenses (Apache-2.0 and MIT license, respectively.) ### Summary of Activities - GUI design & development for **mobile and desktop** [~4 months FTE] - Mobile app design & development [~6 months FTE] - Desktop app design & development [~7 months FTE] - HTTP API design & development [~4 months FTE] - Offline mode of operation (TinyVC) [~0.5 months FTE] Precise resouce estimates can be seen in the [Gantt chart](https://hackmd.io/Rex8VsRkSsm3fwAfMMl0gw?view#Gantt-chart) (below). ### Functionality Mobile app functionality in scope for Phase IV: - graphical user interface - online Verifiable Credential receipt and storage [supported by Credible] - online Verifiable Presentation request and response [supported by Credible] - verify Verifiable Presentation/Credential - request DID document and Merkle proof data from HTTP API - downstream DID & timestamp verification - root DID configuration Desktop app functionality in scope for Phase IV: - graphical user interface - expose **HTTP API endpoint** to respond to requests from Trustchain mobile clients - **challenge-response protocol** for downstream DID issuance: - expose HTTP API endpoint to respond to issuance request and challenge-response handshake initiated by the downstream entity - initiate the challenge-response process by the downstream entity, and subsequent response logic - enriched upstream DID document (representing the issuer) to include API endpoint data for challenge-response initiation - **key management and backup** - encrypted backup & reloading of private key data - simplified **installation and configuration** - root DID configuration - install script(s) and/or containerisation - installation guide - **revocation** & key rotation - revoke a downstream DID - update a downstream DID (e.g. for key rotation) ### Outputs - A Trustchain mobile app (likely based on the [Credible](https://github.com/spruceid/credible) mobile VC wallet and the [Nakamoto](https://github.com/cloudhead/nakamoto) Bitcoin SPV node) for VC **holders** and **verifiers** supporting: - Verifiable Credential storage and selective presentation - Verifiable Presentation request and verification - downstream DID & timestamp verification - A Trustchain desktop application (based on the prototype developed in Phase II) for DID **issuers** and **subjects** supporting: - root and downstream DID management (creation, issuance, revocation) - key management - HTTP API server to respond to mobile client requests ### Time and resource estimate Total: 21.5 months FTE (see [Gantt chart](https://hackmd.io/Rex8VsRkSsm3fwAfMMl0gw?view#Gantt-chart) below) ## Phase V: Pilot [DRAFT] TBD. Potential pilots vary in scale & application domain: - **Internal**: Turing workshop, ID role-playing exercise with "red teaming" - **Project Partners**: CMU Africa campus, MOSIP single-country - **Domestic**: Collaborate with one or more UK Government departments & subordinate entities, e.g.: - DfE & universities to share digital degree certificates - DWP/DHSC voucher schemes - **International**: Federated MOSIP ## Trustchain2023 Timeline (Phases III-V) ### Gantt chart ![](https://i.imgur.com/E6G7qSU.png)  ### Definition of done #### Phase IV Mobile | Task | Definition of done | |----------------------------|--------------------| | Integrate TC with Credible | Credible app extended to support Trustchain-issued VC requests and storage. HTTP servers supporting credential offer/issuance and presentation via the [protocols supported by Credible](https://github.com/spruceid/credible#supported-protocols). | | FFI feasibility | Working example of a [Bitcoin Dev Kit](https://bitcoindevkit.org/) function call from Dart via FFI. | | TinyVC integration | Trustchain-issued VC compressed and presented as QR code on mobile device (emulator). Same QR code read by mobile device (emulator) and VC stored, ready for verification, in location distinct from the holder's credential wallet. | | Integrate SPV node | Bitcoin SPV node running on mobile. Integration test demonstrating validation of a Merkle proof. | | TC API request | API call from mobile to server requesting DID verification bundle and storing the result. | | UI & Configuration | Extended Credible user interface allowing users to execute credential verification and visualise the DID chain involved. Configuration page for entering the root date and confirmation code. | | Verify API response | Verification of the API response bundle by checking the Merkle proof against block headers from the SPV node. Integration tests demonstrating both successful verification and rejection of invalid response. | #### Phase IV Desktop | Task | Definition of done | |-----------------------------|--------------------| | API response bundle | Function to collect all data required to fulfil the API request (for a DID) from a mobile client, including Merkle proof & JSON serialisation. | | HTTP API setup | At least one working API endpoint with an integration test demonstrating a request being handled and a response dependent on the request data. | | GUI v1.0 | Simple GUI built in Rust with support for core TC operations. | | HTTP API | Fully functioning HTTP API able to respond to requests for DID data from mobile clients (optionally including a Merkle proof). Updated DID Document creation to include API endpoint for such requests. | | Challenge-response protocol | Flowchart specifying the challenge-response workflow. Updated DID Document creation to include API endpoint for challenge-response messaging. Code implementing initiation, challenge, response, verification. Integration test demonstrating the complete workflow. | | Key management/backup | Extended key management functionality to support exporting an encrypted backup of private keys and subsequent importing from backup. | | Revocation/update | Functionality to i) revoke an existing DID and ii) publish an update in which keys are rotated. | | GUI v2.0 | Desktop GUI based on Flutter/Dart and sharing code with the mobile UI where possible. Support for core functionality (including revocation) plus challenge-response and key management/backup. | | Installation/config | Simplified installation with full documentation. Containerised desktop app. Configuration page in the GUI for specifying the root DID (by date & confirmation code). |

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.