A Corda Compatibility Zone is a collection of nodes with a vetted, unique identity that share a common “root of trust” upon which all certificates and signatures are ultimately chained back to. The tooling that enables this infrastructure is provided by the Enterprise Network Manager suite of tools, specifically the Identity Manager component.
As part of their boot-strapping process nodes submit their identity (public key and x500 name) to the Identity Manager of the compatibility zone they wish to join. From there a number of things happen:
The request is recorded in the global store of identities
A new request is created via the workflow engine of choice to facilitate the verification of the submitters legal identity. The extent to which this is conducted is left to the discretion of the operator of the network but should be consistent with their existing policies on such things.Alternatively, the service can be configured to automatically accept signature requests. However, this is not the recommended deployment model outside of a testing setup.
Once accepted the requests have a certificate signed by the PKI infrastructure that governs the compatibility zone.Signing is performed by a separately deployed process called “The Signing Service”. It is important to realise how this service should be deployed (for more details on this see the Signing Service documentation), in brief, it is the intention that, unlike the Identity Manager, the signer is completely isolated from external communication. It only addresses a data source it shares with the Identity Manager. This ensure no hostile entity can penetrate the system and force the signing of a certificate. See Signing Service
The signed certificates are recognised by the Identity Manager and returned to the requesting node (Nodes poll the Identity Manager periodically to see if their signature request has been fulfilled).
At the end of this process a node will have successfully registered the legal identity of the entity it is operating on behalf of with the Zone. However, that node now needs to join one of the sub zones that make up the compatibility zone as a whole.
Sub Zones are currently categorised in relation to the mechanism a zone operator has in place for the process of setting the network parameters for it.
- Public Sub Zones where the entirety of the Network Parameters are under the sole control of the Zone Operator
- Segregated Sub Zones where one or more of the Network Parameters have been delegated to the authority of some third party.
Note, in either circumstance the operation of the Network Map in question is still under the perview by the Zone Operator, with a suitable out-of-band process established with the party to communicate the deferred parameter entity.
The merging of sub-zones will be supported in a future release.
For more information, see Sub Zones
Operating a Sub Zone
From the perspective of a mature ENM deployment, operating a sub zone post ENM 0.3 is the same as operating a single compatibility zone under the old paradigm where there was only the one zone.
Each Network Map that represents a SubZone is configured separately from the others as a distinct entity unaware of one another
Each Network Map requires
- A configuration file
- A starting set of network parameters
- One or more notaries for inclusion in the whitelist
- A signing service configured to sign the network map and network parameters