Skip to content

Home

Jump to bottom
Adrian Gropper edited this page May 23, 2021 · 12 revisions

Welcome to the Trustee-Community wiki!

Quantized Face Health Card - to be used for resource server and verifiable credential demonstration

The first phase of the foundation demos GNAP control over a trivial health record consisting of just a biometric health card.

Essential tools include:

  • Spruce didkit to create the VCs for patient, verifier, and the biometric health card
  • FastAPI as the app platforms to make it easy to document the GNAP flows (separate domains for the GNAP AS and RS)
  • CouchDB as the app platform storage for patient policies (not encrypted yet in phase 1)
  • HTML Forms to JSON libraries to present requests to the GNAP authorization server
  • JWT libraries for the GNAP access tokens
  • Stripe API demos a web key management service of sorts

Older, more general discussion follows - this is not directly representative of the repo at this time.

Although a trusted agent framing is general, we use healthcare as a PoC because most people can relate to healthcare.

9 roles are driven by Separation of Concerns:

  • A subject (patient) is a self-sovereign natural person that MAY also control decentralized identifiers and self-sovereign agent technology. A subject should not need a DID and may not need VCs either. A subject does need an interface to manage the policies of their agents.
  • A guardian (doctor) is a natural person and licensed fiduciary that acts as the agent of the subject by signing in a non-repudiable / accountable way.
  • A community is a self-sovereign root of trust chosen and substitutable by the subject or guardian.
  • A processor is a service that has access to information about the subject but SHOULD not have control in order to avoid privacy liability, lock-in and other conflicts of interest.
  • A controller is a service that directs processors and SHOULD not have access to the subject's information to reduce security liability and avoid conflict of interest. An agent is a special case of a controller and may be self-sovereign technology or a fiduciary entity. A broker is another special case of controller.
  • An encrypted data vault is a special case of a processor that has no access to subject information.
  • A repository is signed code analogous to a smart contract that, when hosted and exposed as a service, becomes a controller.
  • A host is a special case of a processor that exposes a repository as a service.
  • An auditor is an entity that keeps guardians, processors, controllers, repositories and hosts accountable. The auditor respects self-sovereign natural persons and their self-sovereign technology.

We hope to show all nine of the roles. The sequence diagram has only 6 lanes because the various auditor roles (1. Endorser 2. Registrar 3. Witness 4. Notary) are not broken out.

Also, Community of Agents in the diagram combines the repository, host, and controller roles into one. It's very important, however, to expect the repository and the host to be separately accountable as legal entities by one or more auditors in order to expose a breach of controller trust by either the repository or the host.

It is also important that the controller code is standards-based as much as possible to avoid lock-in of the subject to a community. This includes the ability for a subject to self-host their controller as self-sovereign technology and avoid trusting any communities or fiduciaries.

Allied projects and libraries will hopefully contribute code to the HIE of One Trustee project for our trusted agent demo.

Foundation Sequence Diagram

Clone this wiki locally