CTN Association Onboarding Process
CTN Implementation of BDI Onboarding
The CTN onboarding process establishes a trusted, verified environment for all participants, ensuring secure and interoperable data exchange. This process leverages the BDI framework principles while applying them specifically to the container transport domain.
The onboarding process is started when a participant organisation wants to become Member (voting rights) or User (non-voting) of an Association. The onboarding process in the Association is defined by the Association itself.
The description that follows provides guidance on a basic onboarding process to the Association.
1. Registration & Verification
Section titled “1. Registration & Verification”New members or users register with the Association of their choice. The registered data is submitted to the Association Registry (ASR):
- CTN Connector endpoints — the (URI) network addresses of their connectors (option: automated protocol between Connector and ASR).
- Service type attributes — if a Connector provides Orchestration Data Services, this is recorded as a special attribute of that Connector.
- CTN Connector endpoint details — including URI, method of authentication, and type of TLS certificate.
- Legal entity details — official name, domain, and legal registration numbers.
- Ownership information — identification of owners (such as Ultimate Beneficial Owner (UBO)), verified according to compliance requirements.
- Compliance Information - such as
- Criminal convictions (for corruption, fraud, terrorism, money laundering, child labor, human trafficking, etc.)
- Payment of taxes & social security contributions (must be up to date)
- Insolvency or bankruptcy (not in liquidation or subject to winding-up procedures)
- Professional misconduct (serious misrepresentation, grave professional errors, collusion, etc.)
The Association Administrator validates the information, performs UBO compliance checks, and records the verified (meta-)data in the ASR.
2. Authentication Enrollment
Section titled “2. Authentication Enrollment”The CTN Connectors need to be able to set up an encrypted peer-to-peer communication channel, and authenticate themselves to each other.
The CTN connector acting as a server must have a TLS certificate, preferably issued by public Certificate Authorities (CAs) such as Let’s Encrypt. The server authenticates to the client using the TLS-protocol.
The CTN Connector acting as a client can authenticate with the OAuth Client Credentials flow, using the ASR of choice as Authentication Server. The connector needs to be enrolled first, receiving a ClientID+Secret from the ASR.
The alternative to the client authenticating with OAuth is the client also authenticating with TLS: both the server and the client use the mTLS-protocol.
3. X.509 CTN Signing Certificate
Section titled “3. X.509 CTN Signing Certificate”A CTN connector may need to use a signing certificate to sign JWT tokens or other data. The ASR of its Association can act as a CTN “localized Certificate Authority”, similar to the SPIFFE “Workload Endpoint”.
The ASR can verify the ownership of the public key of an asymmetric key-pair that the CTN connector generates internally, using the ACME protocol. The CTN connector generates a Certificate Signing Request to the ASR and receives a CTN X.509 formatted signing certificate.
This certificate and the tokens/content signed with the private key are only recognized and useful within the CTN ecosystem.
The security requirements for the storage of the private key may be lower than standard signing certificates as issued by CA’s. The rotation speed of the private key can be relatively high because the ACME protocol with the ASR allows automated rotation, compensating partly for the lower security of the private key storage.
4. Production Activation
Section titled “4. Production Activation”Once validated, the member’s/users CTN Connector endpoints and certificates are marked active in the ASR.
From this point, the Connector can participate in live CTN data exchanges according to registered capabilities and policies.
Related BDI Framework
Section titled “Related BDI Framework”This onboarding process implements the BDI (Basic Data Infrastructure) framework principles:
- Trust Establishment: Through association membership and verification
- Decentralized Authentication: Using connector-based authentication
- Certificate Management: Localized CA functionality
- Compliance Integration: Built-in regulatory checks
The CTN applies these BDI principles specifically to container transport operations, ensuring compatibility with the broader BDI ecosystem while addressing industry-specific requirements.
In samenwerking met
