Chain of Trust heading-link-icon

Corda’s chain of trust is configured when a Network Operator installs a new CPI Corda Package Installer. A signed ZIP/JAR combination of a CPB and a Group Policy File that defines not only the application code that a virtual node will run, but also the details of the MGM with which to register, and the details of network PKI requirements. . At this point, the code-signing certificates of the CPI, CPB Corda Package Bundle. A signed ZIP/JAR collection of CPKs that forms a complete application suite and contains all the code that a virtual node must operate, minus the specific network details. , and CPK Corda Package. A signed ZIP/JAR library of Java code packaged to be portable with all of its dependencies and version information contained within it. publishers are validated and their Certificate Authority ( CA Certificate Authority. The holders of a PKI trust root that can issue certificates to customers. ) trust roots are checked. These code-signing trust roots may be self-signed publisher certificates, or they may be well-known public CAs. Either way, the trust roots establish the standard of proof that the CorDapp Corda Distributed Application. A Java (or any JVM targeting language) application built using the Corda build toolchain and CorDapp API to solve some problem that is best solved in a decentralized manner. code (and any future upgrades) has come from the expected publisher. The Network Operator must establish that they trust the code-signing trust roots and upload them to the cluster to proceed with CPI installation. In choosing to install and trust the CPI, the Network Operator is crucially accepting the network details presented by the CPI and, in particular, the network credentials of the MGM Membership Group Manager. May also be referred to as the Network Manager. It is a virtual node and Corda identity that acts as a central registrar for group membership. , which subsequently act as authentication and a distribution root for the entire network.

The MGM trust root information is defined statically in the GroupPolicy.json file of the CPI. Corda updates this when virtual nodes are upgraded to a more recent CPI from the publisher. This allows for gradual rotation and replacement of the trust roots. More dynamically, the MGM publishes a GroupParameters data structure, which is signed with its key and contains global network facts and configurations. For example, the declaration of allowed notaries, or application-specific information such as issuer keys/member names.

Virtual nodes must abide by the policy rules of the MGM. For example, the MGM defines suitable TLS trust roots and the type of TLS used. The Network Operator must lobby the MGM to accept their membership details before they can join the network or make a change to their details. The session initiation keys The key for a virtual node, which is published in the `MemberInfo`, and used by Link Managers to authenticate and establish secure messaging sessions between network members. , ledger keys A key which can be used to sign for transactions. This key may be held confidentially and signatures may be used as evidence of authority to sign transactions. Alternatively, it may be published in the virtual nodes's MemberInfo to act as a published fact to prove the identity of the virtual node on the ledger. , and other data included in the membership application become the published identity facts of the virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. available to peers, presented with signatures from both MGM and virtual node private keys. Under its signature, the MGM also includes data that only it controls, such as membership active/suspended flags. This shared authenticated data is exposed to flows Communication between participants in an application network is peer-to-peer using flows. as the MemberInfo Information about peer group members as distributed securely by the MGM. Contains information about session and ledger identity, connectivity details, and software version details. data structure. MemberInfo is often used to locate peer keys to validate against, to advertise specific peer roles, or to control flow behaviour.

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.