Trustchain use cases
This document describes primary and secondary digital identity use cases that will be supported as by the Trustchain prototype. See #345 for background.
These use cases were chosen following a review of the W3C standards documents for Decentralised Identifiers and Verifiable Credentials, and the Trustchain proposal. They have been chosen to cover a range of situations requiring different levels of complexity, (non-)transferability, and privacy. Primary use cases will have a use case diagram and will be included in the first prototype.
- Proof of age
- Digital degree certificate
- Cross-border verification
- Secondary use cases
This is a simple case of a relatively low risk use case, in which the User must prove to the Verifier that they are over a certain age. For example, in order to purchase alcohol in the UK, a User would have to prove that they are over 18.
Diagram:
Entities involved:
- Upstream entity: "Root" of Trustchain that creates downstream DID (dDID) for the Issuer of a VC
- Issuer: An entity that creates a VC for an end-user (e.g., attests that somebody is over 18 years of age)
- Verifier: An entity that verifies a VC (e.g., a seller that is required to check a buyer is over 18)
- User: A buyer that needs to prove that they are over 18
- Trustchain: The "chain" of DIDs written to the blockchain via ION + documents stored in IPFS.
This use case consists of a situation in which an organisation, such as a university, can issue a digital degree certificate to an individual, which can then be verified by a third party, such as a prospective employer.
Functionally, this is very similar to the proof-of-age use case. Non-transferability is arguably more of an issue here, so some additional thought may be required as to how it can be verified that the person in possession of the VC is the person it was granted to.
See Technical notes for further details on interoperability.
This is a more complex use case.
Cross-border verification involves a citizen of "Country A" verifying their identity in "Country B", which has an interoperable but independent national identity system. There are three stages involved:
- Resident of Country A enrols in digital ID system as normal in country A
- Country A enters into a trust agreement with country B which allows Issuers (or at least the issuer in question) from Country A to be verified (trusted) in country B.
- Resident A has identity verified by Verifier in Country B
Diagram:
See #345 Similar to Slack Access use case, the idea of an "employee" or individual having a dDID signed by their employer, which is essentially their employee ID (represents their digital identity as an employee of the company/org)
To sponsor a visa application, an employee needs to provide the Home Office with:
- Proof of employment (physically signed letter from employer)
- Proof of income (physically printed payslips, stamped and signed by employer)
If the Home Office and employer (and employee) have (d)DIDs, this process could be facilitated by the Trustchain as follows:
- The Home Offiice (Relying Party) verify employee's employment by resolving their dDID and checking that both employee and employer can be verified back to Trustchain root.
- Payslips can be signed by employer, sent securely (encrypted) to employee, who can then verify them and/or encrypt them and send them securely to the Home Office as proof of income. Home Office can decrypt and verify signature came from employer.
It is very common for tenants to have to prove multiple claims when they move home or engage with a letting agent for the first time, such as:
- Proof of Employment
- Proof of Income
- Proof of Identity
- Proof of current/previous address
- etc.
This can be a time-consuming and frustrating process, and can often require third-party screening services. It would be very useful if this could be done efficiently and in a verifiable manner.
Being able to quickly and verifiably prove a qualification, such as being a medical doctor, would be useful in emergency situations. Anecdotally, there have been occasions where doctors had to wait until their credentials could be verified before being allowed to treat a patient in a medical emergency (e.g. while on an airplane)
### Data Protection Training Organisations frequently require their members/employees to complete Data Protection and/or cybersecurity training. This can result in individuals who are associated with multiple organisations spending significant amounts of time repeating very similar training programmes. Verifiable Credentials issued by trusted organisations could prove completion of recognised programmes, and avoid the need to repeat the training multiple times.
Some roles require extensive background checks, which are costly to complete. Trustchain could allow organisations to verify that an individual's background check had already been attested to by a trusted organisation.