Skip to main content

Intergovernmental Collaboration on Digital Trust and Credentials

CANdy Network Technical Policies

The CANdy Network Technical Policies will adhere to Hyperledger Indy best practices, except where explicitly stated otherwise, and will be further developed by the Technical Policies working group.

More information can be found here: https://wiki.hyperledger.org/display/indy.

CANdy Network Technical Summary​

The CANdy Network is designed to comply with the following standards and protocols:

ItemDetails
Technical Protocol• HyperLedgerIndy v1.13.2[-rc3] (or higher)
• W3C DID Core v1.0
DID Methoddid:indy:candy: v1.13.x
Trust Network SupportersAnyone using the published did:indy:candy universal resolver can resolve a did:indy:candy DIDDoc
Verifiable Credential
Supporters		AnonCreds 1 (Current State) (JSON)
AnonCreds 2 (Future State) (JSON)
W3C Verifiable Credentials JSON-LD (Future State)
Supported Revocation
Protocol		INDY Revocation specification as per documentation
Interoperability Profiles• did:indy:candy DIF Universal Resolver
• did:indy
Identity Primitives• BLS-Signature
• X25519
• ED25519

General Node Requirements​

The Intergovernmental Collaboration on Digital Trust and Credentials (ICDTC) Governing Board recognizes that, currently, the performance of Indy Nodes begins to degrade once the number of nodes exceeds 25.

  • The CANdy Network requires a minimum of four nodes to be operational
  • Maximum number of nodes is 25 nodes (as per above)
  • The addition of nodes SHOULD be controlled at a network level as to satisfy minimum/maximum node instances
  • Maintain accurate and easily accessible contact information in the CANdy Network Contact List.

The CANdy Network Node Operator Technical Policies will adhere to Hyperledger Indy and Sovrin Network best practices, except where explicitly stated otherwise, and will be further developed by the Technical Policies working group.

A Steward Node:

  1. MUST be available to run as a Validator Node or Observer Node (Future State) on any of the formal ledgers that comprise the CANdy Network.
  2. MUST run a release of the CANdy Open Source Code as approved and designated by the ICDTC Governing Board.
  3. MUST facilitate an upgrade to a new version of the CANdy Source Code that has been:
    a) recommended by the CANdy Network operations teams; and
    b) accepted by the ICDTC Governing Board. Board decisions are reached through consensus among all Members.
  4. MUST register all Node configuration data required by the Pool Ledger in a timely manner, keeping information up to date within three business days of changes.
  5. MUST have at least two (2) IT-qualified persons assigned to administer the node, and at least one other person who has adequate access and training to administer the Node in an emergency (e.g., the CANdy Network being unable to reach consensus or being under attack).
  6. MUST supply contact information for all administrators to the ICDTC Steering Committee: Contact List, whose accuracy is tested at least quarterly (e.g., by sending an email and/or text that doesn’t bounce).
  7. MUST maintain a system backup, snapshot, or image, such that recovering the system from failure could be expected to take one hour or less.

CANdy Network Node Technical Policies​

The following requirements apply to Steward Nodes on the CANdy Production Network. Nodes on any other CANdy Test Network SHOULD be similar to these, but requirements may be downgraded from MUST to SHOULD.

  1. To onboard an additional Node to the CANdy Network, the Member MUST present it to the ICDTC Governing Board. The addition of Nodes to the network MUST be approved by the Board.
  2. To offboard a Node from the CANdy Network, the Member MUST present it to the ICDTC Governing Board. The removal of Nodes from the network MUST be approved by the Board.
  3. When offboarding a Node from the CANdy Network, the ICDTC Steering Committee MUST confirm that the Steward or Node(s) are not the sole record(s) of the CANdy Network's Genesis files.
  4. MUST run on robust server-class hardware.
  5. If a Node is run on a VM, the Steward: a) MUST run on a mainstream hypervisor that receives timely patches from its vendor or community. b) SHOULD apply hypervisor patches on a regular basis.
  6. The Node MUST run in an OS that is dedicated to the validator (i.e., a single-purpose physical or virtual machine that MUST run CANdy Open Source Code); MAY run other software approved by the Steering Committee or a delegated technical group; And MUST NOT run any other software. Software required to support the node, such as monitoring, backup and configuration management software, are approved as a general category. However, Stewards are advised to discuss with the Steering Committee or a designated technical group regarding any software packages that transmit between the Steward Node and the outside.
  7. MUST run a server with compatible versions of the operating systems supported by the Hyperledger Indy Node requirements as documented in the release notes.
  8. MUST have minimum compute power (as of mid-2022, two (2) or more cores is considered adequate).
  9. MUST have adequate RAM (as of mid-2022, 8 GB of RAM is considered adequate).
  10. MUST have at least 250 GB, with the ability to grow to 1 TB, of reliable (e.g., RAIDed) disk space, with an adequately sized boot partition.
  11. MUST have a high-speed connection to the Internet with highly available, redundant pipes (as of mid-2022, 1 Gbps was considered adequate).
  12. MUST have at least two dedicated NICs for CANdy Validator Node consensus traffic, and a different NIC to process external requests. Each NIC must have a stable, static, world-routable IP address.
  13. MUST have a system clock that is demonstrably in sync with well-known NTP servers.
  14. SHOULD have a power supply consistent with high availability systems.

CANdy Network Node Security Policies​

A Steward:

  1. MUST maintain Steward keys on a separate system from the system that runs their node. This system, called the “CLI (Command Line Interface) system”, uses Steward keys to authorize the Node to participate in the pool, and is thus the basis for trust for the node and the Steward’s identity on the network. The CLI system is not required to have high-end hardware, but in terms of IT best practices for security, it must meet or exceed the standards for the Node (see following items). This system may be containerized, and only needs to be available to the Steward on an as needed basis.
  2. MUST provide certification that their Node runs in a locked datacenter with appropriate levels of security, including the specifications that they target (e.g., SSAE 16 type II compliance; other standards may also be acceptable).
  3. MUST assert that their Node is isolated from internal systems of a Steward (because the Validator Node is publicly visible and thus an inappropriate candidate for access to privileged internal networks).
  4. MUST assert that their Node, and its underlying systems, uses state-of-the-art authentication for remote access (at least SSH with key plus password plus source IP firewall rule, and two-factor authentication wherever possible).
  5. MUST NOT allow access (remote or local) to the Node or CLI systems by anyone other than assigned adminstrators.
  6. SHOULD apply the latest security patches within one (1) week or less (24 hours or less is recommended).
  7. MUST attest that the Node runs on a server protected by a firewall that, at minimum: Disallows public ingress except on ports used by the Node software (different machines may choose to expose ledger features on different ports, so no standard port setup is required); Optionally enables SSH, Remote Desktop, and similar remote access tools but constrains ingress for these tools in some way that excludes the public but allows access for adminstrators; Locks down egress ports to limit the ability to jump from Node to some other location.
  8. MUST run the Steward security check tool as requested, and MUST obtain approval from the Steering Committee or a designated technical group regarding the results before being authorized to engage in consensus.
  9. MUST run the Steward security check tool from time to time as requested by the Steering Committee and provide the test results report to the Steering Committee within three (3) business days.
  10. The node MUST be regularly scanned with security and threat protection tools.

A Network Monitor:

  1. MUST keep privileged node information confidential and only use that information to assist Stewards in ensuring the health and availability of the network.

CANdy Network Node Operating Requirements​

A Steward:

  1. MUST equip at least two (2) technical points of contact responsible for administering the Steward Node with a real-time capable device for alerting.
  2. SHOULD aim to achieve at least 99.9% (three nines) uptime for their Node (this amounts to about 1.4 minutes of downtime per day or nine (9) hours per year). This excludes downtime for upgrades and maintenance.
  3. SHOULD coordinate downtime with other Stewards in advance via a mechanism as determined from time to time established by mutual agreement between the Steering Committee and any other relevant ICDTC Governing Body.

CANdy Network Technical and Organizational Measures​

The CANdy Network MUST maintain Technical and Organizational Measures that Members operating CANdy nodes MUST implement in order to promote secure processing, avoid data breaches, and facilitate compliance with relevant data protection obligations.

The following Technical and Organizational Measures MUST be adhered to by Members operating CANdy nodes:

  • Contact information for technical resources
  • Process for ensuring technical contacts remain up to date.
  • Offboarding technical resources.
  • Onboarding new technical resources.
  • Monitoring services.
  • Incident and outage notifications and alerts
  • Incident Escalation - including outside the team (Trustees, Steering Committee, Governing Board)
  • Assigned responsibilities in times of crisis.
  • Communications strategy for incidents and outages
  • Incident meeting protocols
  • Blameless post-incident reviews
  • Runbook of actions to resolve potential incidents