diff --git a/agent/.coveragerc b/.coveragerc similarity index 100% rename from agent/.coveragerc rename to .coveragerc diff --git a/agent/.dockerignore b/.dockerignore similarity index 100% rename from agent/.dockerignore rename to .dockerignore diff --git a/README.md b/README.md index 8d673173a2..fbf975e9e6 100644 --- a/README.md +++ b/README.md @@ -1,184 +1,117 @@ -# Hyperledger Indy Catalyst +# Hyperledger Indy Catalyst Agent + +[![CircleCI](https://circleci.com/gh/bcgov/indy-catalyst.svg?style=shield)](https://circleci.com/gh/bcgov/indy-catalyst) +[![codecov](https://codecov.io/gh/bcgov/indy-catalyst/branch/master/graph/badge.svg)](https://codecov.io/gh/bcgov/indy-catalyst) +[![Known Vulnerabilities](https://snyk.io/test/github/bcgov/indy-catalyst/badge.svg?targetFile=agent%2Frequirements.txt)](https://snyk.io/test/github/bcgov/indy-catalyst?targetFile=agent%2Frequirements.txt) ![logo](/docs/assets/indy-catalyst-logo-bw.png) # Table of Contents -- [Introduction](#introduction) -- [Decentralized Identity / Self-Sovereign Identity](#decentralized-identity--self-sovereign-identity) - - [Open Standards](#open-standards) - - [Decentralized Identifiers (DID)](#decentralized-identifiers-did) - - [Verifiable Credentials](#verifiable-credentials) - - [Links to Emerging DID and Verifiable Credentials Standards](#links-to-emerging-did-and-verifiable-credentials-standards) - - [DID Standards](#did-standards) - - [Verifiable Credentials Standards](#verifiable-credentials-standards) - - [General Model](#general-model) - - [Technology](#technology) - - [Distributed Ledger Technology / Blockchain](#distributed-ledger-technology--blockchain) - - [Decentralized Key Management Systems](#decentralized-key-management-systems) - - [Zero Knowledge Proofs](#zero-knowledge-proofs) - - [Summary: Decentralized Identity / Self-Sovereign Identity Architecture](#summary-decentralized-identity--self-sovereign-identity-architecture) -- [Hyperledger Indy](#hyperledger-indy) - - [Overview](#overview) - - [Technical information for Hyperledger Indy](#technical-information-for-hyperledger-indy) -- [Hyperledger Indy Catalyst](#hyperledger-indy-catalyst) - - [Motivation](#motivation) - - [Who is Indy Catalyst For](#who-is-indy-catalyst-for) - - [Key Technical Elements](#key-technical-elements) - - [Credential Registry](#credential-registry) - - [Agent](#agent) - - [Agent Driver](#agent-driver) - - [Starter Kits](#starter-kits) - - [Credential Registry Holder-Prover](#credential-registry-holder-prover) - - [Agent Issuer-Verifier](#agent-issuer-verifier) -- [Endnotes](#endnotes) +- [Introduction](#Introduction) +- [Installing](#Installing) +- [Running](#Running) +- [Developing](#Developing) + - [Prerequisites](#Prerequisites) + - [Running Locally](#Running_Locally) + - [Caveats](#Caveats) + - [Running Tests](#Running_Tests) + - [Development Workflow](#Development_Workflow) # Introduction -**Hyperledger Indy Catalyst** is a set of application level software components designed to accelerate the adoption of trustworthy entity to entity[1](#f1) communications based on Decentralized Identity / Self-Sovereign Identity technology and architecture. Indy Catalyst is builds upon globally available open standards and open source software. At present, Indy Catalyst builds upon [Hyperledger Indy](https://www.hyperledger.org/projects), common enterprise open source software, frameworks and patterns such as PostgreSQL, Python, Angular and RESTful APIs. Efforts will be taken to design the software to facilitate the incorporation of evolving open standards and technology. The impetus for Indy Catalyst came from the Verifiable Organizations Network (VON) project. More information about VON can be found at [vonx.io](https://vonx.io) - -In order to understand the goals and context of Hyperledger Indy Catalyst, it is advisable to become familiar with the model of decentralized identity or self-sovereign identity which enables trustworthy entity to entity communications. The open standards and technologies enabling this new this model are presented below and annotated with references. - -# Decentralized Identity / Self-Sovereign Identity - -Self-Sovereign Identity is a term coined by [Christoper Allen in 2016](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html) to describe a new generation of digital identity systems. One which "requires that users be the rulers of their own identity." In order to truly understand the intent of this statement, which at first may sound rather radical, it is important to reflect upon the design of current identity systems and contrast that to the emerging design of decentralized identity systems. - -The excellent paper, ["Self-sovereign Identity: A position paper on blockchain enabled identity and the road ahead"](https://www.bundesblock.de/wp-content/uploads/2018/10/ssi-paper.pdf), published in October 2018 by the [German Blockchain Association](https://www.bundesblock.de) highlights the key differentiators between current digital identity systems and emerging self-sovereign identity systems. - -The key differentiator pertains to the means by which current centralized identity systems keep track of individual entities in their databases. Centralized identity systems create and assign an identifer for each individual entity and associate data about that individual entity to that identifier. This is a familiar idea to most of us. In the analog world these identifiers have names such as drivers licence number, credit card number, bank account number, social insurance number, etc. The identity system owner creates and is in control of the _identifiers_ and associated data for individual entities and not the individual entities themselves. Identity system operators have the ability to unilaterally make changes to these identifiers are associated data. - -In contrast, the design of a decentralized or "self-sovereign" identity system is to put individual entities in control of the _identifiers_ used to keep track of them as well as the holding and disclosure of the data associated to these new identifiers. These new identifiers, described below, are called ["Decentralized Identifiers" (DID)](#decentralized-identifiers-did). The data associated to these identifiers is encoded into a new format called a [Verifiable Credential](#verifiable-credentials). These Verifiable Credentials are issued to and held by individual entities. - -Using this new approach to identity systems design means a person would be in full control of data issued to them by third parties. People would be in control of disclosing of their personally identifiable data as issued by themselves (e.g. personal preferences, messages, etc) or issued to them by third parties. These third parties may include authoritative issuers such as governments (e.g. identity documents, licences) or they could be issuers such as a local sports club (e.g. membership). Critically, "self-sovereign" is not intended to suggest a "digital self-declaration" of ones identity in opposition to or as a substitute for authoritative and officially issued identity attributes from a government. Rather, that one is both "in control" of the relationship (the decentralized identifier) and the data (verifiable credential) issued to them. Therefore, once one is holding this officially issued data, one can choose when and what one would like to disclose to third parties. The details of how this can be technically achieved are described briefly in the following sections along with appropriate references for further study. - -It is important to note that while these emerging standards and technologies are being designed to tackle the very difficult challenges of secure and privacy respecting digital identity for people, they are not limited to the narrow context of personal identity. This new model can be applied to a broader set of use cases beyond those involving personally identifiable information. The model offers a generalized capability enabling highly secure entity to entity communications and it is this generalized capability that has led to the creation of Hyperledger Indy Catalyst. Indy Catalyst components enable enterprises to issue, hold and verify data about entities. - -## Open Standards - -There are two emerging open standards aimed at enabling interoperable secure and privacy respecting entity to entity data exchange. - -### Decentralized Identifiers (DID) - -A DID is a globally unique and resolvable identifier created by a entity. A entity could be any sort of real world actor such as an individual person, a legal entity, a government authority, a thing. DIDs are created and issued by software under the control of a entity. DIDs are bound with the necessary information to allow a entity to demonstrate cryptographic control over the DID and to enable secure communications with that entity. With these basic primitives, secure and privacy respecting entity to entity data exchange becomes possible. DIDs do not require any centralized issuing or resolution authority. - -### Verifiable Credentials - -A verifiable credential is data issued to, and held by an entity. Verifiable indicates the credential is rendered tamper-evident and in a manner whereby the issuer can be cryptographically verified.[2](#f2) Data contained in a verifiable credential is organized into individual claims. Claims within a credential can be about different subjects (e.g entities) and may be verifiable individually. - -### Links to Emerging DID and Verifiable Credentials Standards - -The DID and Verifiable Credential emerging open standards are being incubated within the [W3C Credentials Community Group](https://www.w3.org/community/credentials/) - -#### DID Standards - -- [W3C DID Primer](https://w3c-ccg.github.io/did-primer/) -- [W3C DID Spec](https://w3c-ccg.github.io/did-spec/) - -#### Verifiable Credentials Standards - -- [W3C Verifiable Claims Working Group](https://www.w3.org/2017/vc/WG/) -- [W3C Verifiable Credentials Data Model 1.0](https://w3c.github.io/vc-data-model/) - -## General Model - -Stemming from the work in the Verifiable Credentials is a general model for describing the roles of the main actors in a Decentralized Identity / Self-Sovereign Identity ecosystem. - -The roles and information flows are described in the [W3C Verifiable Credentials Data Model 1.0](https://w3c.github.io/vc-data-model/#dfn-verifiable-data-registries). The roles are: - -1. Issuer -2. Holder (also known as the Prover at verification time) -3. Verifier -4. A [Verifiable Data Registry](https://w3c.github.io/vc-data-model/#dfn-verifiable-data-registries) - commonly a decentralized ledger which serves as a system "mediating the creation and verification of issuer identifiers, keys and other relevant data like verifiable credential schemas and revocation registries". - -![verifiable credential general model](/docs/assets/verifiable-credential-model-ForWhiteBK.png) - -These roles can be fulfilled by a number of "real world" actors including people, legal entities,or things. - -## Technology - -The technologies described in this document provide the core functionality required to implement and complement the emerging open standards described above. Together this suite of open standards and technologies create a fundamentally new approach for privacy respecting and secure entity to entity communication. - -### Distributed Ledger Technology / Blockchain - -The high integrity and global availability of a public blockchain combined with the concept of a DID creates a new decentralized root of trust capability. This new capability tackles a long standing problem with centralized identity systems, in particular those based on Public Key Infrastructure (PKI) models. The following sections provide links to in-depth explorations of these new approaches. +Indy Catalyst Agent is a configurable instance of a "Cloud Agent". -### Decentralized Key Management Systems +# Installing -As stated in a the [Decentralized Key Management Systems](https://github.com/hyperledger/indy-sdk/blob/677a0439487a1b7ce64c2e62671ed3e0079cc11f/doc/design/005-dkms/DKMS%20Design%20and%20Architecture%20V3.md) research paper for the Department of Homeland Security. +Instructions forthcoming. `indy_catalyst_agent` will be made available in the future as a python package at [pypi.org](https://pypi.org). -> `"DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely that public key certificates will be issued by centralized or federated certificate authorities (CAs)."` (DKMS = Decentralized Key Management System) +# Running -This paper provides an in-depth on the benefits of DMKS and its design. +After installing the package, `icatagent` should be available in your PATH. -### Zero Knowledge Proofs +Find out more about the available command line parameters by running: -A [Zero Knowledge Proof](https://medium.com/coinmonks/introduction-to-zero-knowledge-proof-the-protocol-of-next-generation-blockchain-305b2fc7f8e5) protocol is an optional but useful complimentary capability for decentralized identity systems. +```bash +icatagent --help +``` -Hyperledger Indy does include an implementation of zero knowledge proofs. The implementation is described in this GitHub repository -> [indy-anoncreds](https://github.com/hyperledger/indy-anoncreds) +Currently you must specify at least one _inbound_ and one _outbound_ transport. -Zero Knowledge Proofs allow the holder to prove that some or all of the data in a set of claims is true without revealing any additional information, including the identity of the holder. During these interactions the holder is referred to as a "Prover" as they are offering a proof of knowledge rather than transfering the claim directly to the verifier. This is a powerful capability enabling the holder to selectively disclose (e.g. prove "I am over 25" or "I am holding a valid drivers licence") without revealing to the verifier any other facts about themselves. +For example: -## Summary: Decentralized Identity / Self-Sovereign Identity Architecture +```bash +icatagent --inbound-transport http 0.0.0.0 8000 \ + --inbound-transport http 0.0.0.0 8001 \ + --inbound-transport ws 0.0.0.0 8002 \ + --outbound-transport ws \ + --outbound-transport http +``` -Decentralized Identity / Self-Sovereign Identity systems make use of DIDs, Verifiable Credentials, and a Verifiable Data Registry (Decentralized Key Management System). Such an architecture is one where the holder of verifiable credentials (a set of verifiable claims) is in complete control of their identifier, where their verifiable credentials are stored, and how they are used. +Currently, Indy Catalyst Agent ships with both inbound and outbound transport drivers for `http` and `websockets`. More information on how to develop your own drivers will be coming soon. -# Hyperledger Indy +# Developing -{to be completed} -Based on [indy-node](https://github.com/hyperledger/indy-node) providing the root of trust for [Decentralized Identifiers (DID)](https://w3c-ccg.github.io/did-spec/) and other artifacts to enable a decentralized (or self-sovereign) identity network. +## Prerequisites -## Overview +[Docker](https://www.docker.com) must be installed to run software locally and to run the test suite. -[Hyperledger Indy](https://www.hyperledger.org/projects) is open source software providing: +## Running Locally -> `"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."` +To run the locally, we recommend using the provided Docker images to run the software. -More broadly, Hyperledger Indy based networks create the technical conditions for highly secure entity to entity data exchange without the involvement of a central authority. The techniques made available by Hyperledger Indy mitigate the security and privacy problems stemming from current approaches to data exchange over the Internet. These problems are particularily evident when it comes to the exchange of highly senstive forms of data such as personally identifiable information (e.g. identity attributes). +``` +./scripts/run_docker +``` -The technical means by which this is accomplished include a number of new open emerging standards and technologies. +``` +./scripts/run_docker --inbound-transport http 0.0.0.0 10000 --outbound-transport http --debug --log-level DEBUG +``` -## Technical information for Hyperledger Indy +To enable the [ptvsd](https://github.com/Microsoft/ptvsd) Python debugger for Visual Studio/VSCode use the `debug` flag -- [Technical information for Hyperledger Indy](https://indy.readthedocs.io/en/latest/) +For any ports you will be using, you can publish these ports from the docker container using the PORTS environment variable. For example: -# Hyperledger Indy Catalyst +``` +PORTS="5000:5000 8000:8000 1000:1000" ./scripts/run_docker --inbound-transport http 0.0.0.0 10000 --outbound-transport http --debug --log-level DEBUG +``` -{to be completed} +Refer to [the previous section](#Running) for instructions on how to run the software. -## Motivation +## Running Tests -Indy Catalyst components are designed for several enterprise scenarios: +To run the test suite, use the following script: -1. join an existing Hyperledger Indy based network as a entity that can engage in entity to entity communication -2. establish a credential registry +```sh +./scripts/run_tests +``` -Networks require a strategy to get them started. This is due to the challenge of creating network effects. There are several excellent resources describing what network effect are, why they are important, and techniques to go about creating them. Several excellent summaries describing techniques for creating network effects can be found in this [Andreessen Horowitz article](https://a16z.com/2016/03/07/all-about-network-effects/)and in this [NfX article](https://www.nfx.com/post/network-effects-manual). Sometimes this problem is referred to as the ["Chicken and Egg Bootstraping problem"](https://blog.creandum.com/the-chicken-and-the-egg-bootstrapping-a-network-b1165b3a5c47). +To run the test including [Indy SDK](https://github.com/hyperledger/indy-sdk) and related dependencies, run the script: -## Who is Indy Catalyst For +```sh +./scripts/run_tests_indy +``` -Indy Catalyst components: +## Development Workflow -- use standard enterprise and Internet technologies; -- implement common integration patterns to minimize effort to adopt; and, -- minimize the learning needed to get started. +We use [Flake8](http://flake8.pycqa.org/en/latest/) to enforce a coding style guide. -## Key Technical Elements +We use [Black](https://black.readthedocs.io/en/stable/) to automatically format code. -### Credential Registry +Please write tests for the work that you submit. -### Agent +Tests should reside in a directory named `tests` alongside the code under test. Generally, there is one test file for each file module under test. Test files _must_ have a name starting with `test_` to be automatically picked up the test runner. -### Agent Driver +There are some good examples of various test scenarios for you to work from including mocking external imports and working with async code so take a look around! -### Starter Kits +The test suite also displays the current code coverage after each run so you can see how much of your work is covered by tests. Use your best judgement for how much coverage is sufficient. -#### Credential Registry Holder-Prover +Please also refer to the [contributing guidelines](/CONTRIBUTING.md) and [code of conduct](/CODE_OF_CONDUCT.md). -#### Agent Issuer-Verifier +## Dynamic Injection of Services -# Endnotes +The Agent employs a dynamic injection system whereby providers of base classes are registered with the `RequestContext` instance, currently within `conductor.py`. Message handlers and services request an instance of the selected implementation using `await context.inject(BaseClass)`; for instance the wallet instance may be injected using `wallet = await context.inject(BaseWallet)`. The `inject` method normally throws an exception if no implementation of the base class is provided, but can be called with `required=False` for optional dependencies (in which case a value of `None` may be returned). -1: A thing with distinct and independent existence such as a person, organization, concept, or device. Source: [Verifiable Claims Data Model and Representations 1.0](https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/#dfn-entity). [↩](#a1) +Providers are registered with either `context.injector.bind_instance(BaseClass, instance)` for previously-constructed (singleton) object instances, or `context.injector.bind_provider(BaseClass, provider)` for dynamic providers. In some cases it may be desirable to write a custom provider which switches implementations based on configuration settings, such as the wallet provider. -2: A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Source: [W3C -Verifiable Credentials Data Model 1.0](https://w3c.github.io/vc-data-model/#dfn-credential) [↩](#a2) +The `BaseProvider` classes in the `config.provider` module include `ClassProvider`, which can perform dynamic module inclusion when given the combined module and class name as a string (for instance `indy_catalyst_agent.wallet.indy.IndyWallet`). `ClassProvider` accepts additional positional and keyword arguments to be passed into the class constructor. Any of these arguments may be an instance of `ClassProvider.Inject(BaseClass)`, allowing dynamic injection of dependencies when the class instance is instantiated. diff --git a/agent-driver/README.md b/agent-driver/README.md deleted file mode 100644 index de126b712c..0000000000 --- a/agent-driver/README.md +++ /dev/null @@ -1,11 +0,0 @@ - -# Hyperledger Indy Catalyst Agent Driver - -![logo](/docs/assets/indy-catalyst-logo-bw.png) - -# Table of Contents -- [Introduction](#introduction) - -# Introduction - -Placeholder README for forthcoming Indy Catalyst Agent Driver software. diff --git a/agent/.gitignore b/agent/.gitignore deleted file mode 100644 index a5dc7698fb..0000000000 --- a/agent/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -.idea -test-reports/ diff --git a/agent/README.md b/agent/README.md deleted file mode 100644 index fbf975e9e6..0000000000 --- a/agent/README.md +++ /dev/null @@ -1,117 +0,0 @@ -# Hyperledger Indy Catalyst Agent - -[![CircleCI](https://circleci.com/gh/bcgov/indy-catalyst.svg?style=shield)](https://circleci.com/gh/bcgov/indy-catalyst) -[![codecov](https://codecov.io/gh/bcgov/indy-catalyst/branch/master/graph/badge.svg)](https://codecov.io/gh/bcgov/indy-catalyst) -[![Known Vulnerabilities](https://snyk.io/test/github/bcgov/indy-catalyst/badge.svg?targetFile=agent%2Frequirements.txt)](https://snyk.io/test/github/bcgov/indy-catalyst?targetFile=agent%2Frequirements.txt) - -![logo](/docs/assets/indy-catalyst-logo-bw.png) - -# Table of Contents - -- [Introduction](#Introduction) -- [Installing](#Installing) -- [Running](#Running) -- [Developing](#Developing) - - [Prerequisites](#Prerequisites) - - [Running Locally](#Running_Locally) - - [Caveats](#Caveats) - - [Running Tests](#Running_Tests) - - [Development Workflow](#Development_Workflow) - -# Introduction - -Indy Catalyst Agent is a configurable instance of a "Cloud Agent". - -# Installing - -Instructions forthcoming. `indy_catalyst_agent` will be made available in the future as a python package at [pypi.org](https://pypi.org). - -# Running - -After installing the package, `icatagent` should be available in your PATH. - -Find out more about the available command line parameters by running: - -```bash -icatagent --help -``` - -Currently you must specify at least one _inbound_ and one _outbound_ transport. - -For example: - -```bash -icatagent --inbound-transport http 0.0.0.0 8000 \ - --inbound-transport http 0.0.0.0 8001 \ - --inbound-transport ws 0.0.0.0 8002 \ - --outbound-transport ws \ - --outbound-transport http -``` - -Currently, Indy Catalyst Agent ships with both inbound and outbound transport drivers for `http` and `websockets`. More information on how to develop your own drivers will be coming soon. - -# Developing - -## Prerequisites - -[Docker](https://www.docker.com) must be installed to run software locally and to run the test suite. - -## Running Locally - -To run the locally, we recommend using the provided Docker images to run the software. - -``` -./scripts/run_docker -``` - -``` -./scripts/run_docker --inbound-transport http 0.0.0.0 10000 --outbound-transport http --debug --log-level DEBUG -``` - -To enable the [ptvsd](https://github.com/Microsoft/ptvsd) Python debugger for Visual Studio/VSCode use the `debug` flag - -For any ports you will be using, you can publish these ports from the docker container using the PORTS environment variable. For example: - -``` -PORTS="5000:5000 8000:8000 1000:1000" ./scripts/run_docker --inbound-transport http 0.0.0.0 10000 --outbound-transport http --debug --log-level DEBUG -``` - -Refer to [the previous section](#Running) for instructions on how to run the software. - -## Running Tests - -To run the test suite, use the following script: - -```sh -./scripts/run_tests -``` - -To run the test including [Indy SDK](https://github.com/hyperledger/indy-sdk) and related dependencies, run the script: - -```sh -./scripts/run_tests_indy -``` - -## Development Workflow - -We use [Flake8](http://flake8.pycqa.org/en/latest/) to enforce a coding style guide. - -We use [Black](https://black.readthedocs.io/en/stable/) to automatically format code. - -Please write tests for the work that you submit. - -Tests should reside in a directory named `tests` alongside the code under test. Generally, there is one test file for each file module under test. Test files _must_ have a name starting with `test_` to be automatically picked up the test runner. - -There are some good examples of various test scenarios for you to work from including mocking external imports and working with async code so take a look around! - -The test suite also displays the current code coverage after each run so you can see how much of your work is covered by tests. Use your best judgement for how much coverage is sufficient. - -Please also refer to the [contributing guidelines](/CONTRIBUTING.md) and [code of conduct](/CODE_OF_CONDUCT.md). - -## Dynamic Injection of Services - -The Agent employs a dynamic injection system whereby providers of base classes are registered with the `RequestContext` instance, currently within `conductor.py`. Message handlers and services request an instance of the selected implementation using `await context.inject(BaseClass)`; for instance the wallet instance may be injected using `wallet = await context.inject(BaseWallet)`. The `inject` method normally throws an exception if no implementation of the base class is provided, but can be called with `required=False` for optional dependencies (in which case a value of `None` may be returned). - -Providers are registered with either `context.injector.bind_instance(BaseClass, instance)` for previously-constructed (singleton) object instances, or `context.injector.bind_provider(BaseClass, provider)` for dynamic providers. In some cases it may be desirable to write a custom provider which switches implementations based on configuration settings, such as the wallet provider. - -The `BaseProvider` classes in the `config.provider` module include `ClassProvider`, which can perform dynamic module inclusion when given the combined module and class name as a string (for instance `indy_catalyst_agent.wallet.indy.IndyWallet`). `ClassProvider` accepts additional positional and keyword arguments to be passed into the class constructor. Any of these arguments may be an instance of `ClassProvider.Inject(BaseClass)`, allowing dynamic injection of dependencies when the class instance is instantiated. diff --git a/credential-registry/README.md b/credential-registry/README.md deleted file mode 100644 index 39e56ca9e5..0000000000 --- a/credential-registry/README.md +++ /dev/null @@ -1,13 +0,0 @@ - -# Hyperledger Indy Catalyst Credential Registry - -![logo](/docs/assets/indy-catalyst-logo-bw.png) - -# Table of Contents -- [Introduction](#introduction) - -# Introduction - -Hyperledger Indy Catalyst Credential Registry is a software component that will be derived from the [Verifiable Organizations Network](https://vonx.io) "OrgBook". - -The current code can be found in [TheOrgBook](https://github.com/bcgov/TheOrgBook) repo in the Province of British Columbia's GitHub organization. \ No newline at end of file diff --git a/credential-registry/client/tob-web/.editorconfig b/credential-registry/client/tob-web/.editorconfig deleted file mode 100644 index 6e87a003da..0000000000 --- a/credential-registry/client/tob-web/.editorconfig +++ /dev/null @@ -1,13 +0,0 @@ -# Editor configuration, see http://editorconfig.org -root = true - -[*] -charset = utf-8 -indent_style = space -indent_size = 2 -insert_final_newline = true -trim_trailing_whitespace = true - -[*.md] -max_line_length = off -trim_trailing_whitespace = false diff --git a/credential-registry/client/tob-web/.gitignore b/credential-registry/client/tob-web/.gitignore deleted file mode 100644 index e06ad6ebbc..0000000000 --- a/credential-registry/client/tob-web/.gitignore +++ /dev/null @@ -1,49 +0,0 @@ -# See http://help.github.com/ignore-files/ for more about ignoring files. - -# local config -.env -# precompiled theme -/src/themes/_active/ - -# compiled output -/dist -/tmp -/out-tsc - -# dependencies -/node_modules - -# IDEs and editors -/.idea -.project -.classpath -.c9/ -*.launch -.settings/ -*.sublime-workspace - -# IDE - VSCode -.vscode/* -!.vscode/settings.json -!.vscode/tasks.json -!.vscode/launch.json -!.vscode/extensions.json - -# misc -/.sass-cache -/connect.lock -/coverage -/libpeerconnection.log -package-lock.json -npm-debug.log -.npm -testem.log -/typings - -# e2e -/e2e/*.js -/e2e/*.map - -# System Files -.DS_Store -Thumbs.db diff --git a/credential-registry/client/tob-web/.s2i/bin/save-artifacts b/credential-registry/client/tob-web/.s2i/bin/save-artifacts deleted file mode 100644 index 28ab6ab062..0000000000 --- a/credential-registry/client/tob-web/.s2i/bin/save-artifacts +++ /dev/null @@ -1,5 +0,0 @@ -#!/bin/bash - -if [ "${DEV_MODE}" == "false" ] && [ "$(ls ${HOME}/node_modules 2>/dev/null)" ]; then - tar -C ${HOME} -cf - node_modules -fi diff --git a/credential-registry/client/tob-web/.s2iignore b/credential-registry/client/tob-web/.s2iignore deleted file mode 100644 index af98bce5f9..0000000000 --- a/credential-registry/client/tob-web/.s2iignore +++ /dev/null @@ -1,4 +0,0 @@ -.npm -dist/ -node_modules/ -src/themes/_active/ diff --git a/credential-registry/client/tob-web/ACCESSIBILITY.md b/credential-registry/client/tob-web/ACCESSIBILITY.md deleted file mode 100644 index 8f136b64e5..0000000000 --- a/credential-registry/client/tob-web/ACCESSIBILITY.md +++ /dev/null @@ -1,76 +0,0 @@ -# Accessibility - -This applications aims to meet or exceed the [World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/). - -## Tested Assistive Technologies - -The following technologies are recommended to be tested with this application, chosen because of their popularity and coverage using data from http://webaim.org/projects/screenreadersurvey6/: - -1. JAWS IE 11 on Windows 10 -2. NVDA Firefox (evergreen) on Windows 10 -3. VoiceOver on Mac OS (should get iOS coverage) -4. Colour Constrast Checker from https://webaim.org/resources/contrastchecker/ - -## General Advice - -1. Use native HTML5 elements/attributes where possible, e.g., `