BDI Framework Principles

The Basic Data Infrastructure (BDI) framework provides a foundational set of principles, patterns, and protocols for secure, sovereign data exchange between organizations. This document serves as the reference for the seven core BDI principles and how they guide architecture decisions.

Purpose and Scope

Purpose: Define the BDI framework principles that govern all BDI-compliant implementations

Scope:

• Applies to all BDI implementations, including CTN
• Defines architectural constraints and requirements
• Provides guidance for design decisions
• Establishes baseline for compliance evaluation

Relationship to CTN: The Connected Trade Network (CTN) is a specific implementation of the BDI framework tailored for container transport. While CTN adheres to these principles, it may adapt or extend them based on specific requirements. All such adaptations will be documented in Architecture Decision Records (ADRs).

The Seven Core BDI Principles

Principle 1: Connecting Physical and Digital Processes

Definition: Digital data flows and representations must accurately mirror and support physical operational processes.

Rationale:

• Ensures digital systems reflect real-world operations
• Maintains consistency between physical and digital states
• Enables reliable decision-making based on digital data

Requirements:

1. Digital identity must map to physical entities (organizations, vehicles, containers)
2. Data updates must reflect actual operational state changes
3. Digital processes must support (not constrain) physical operations
4. Timing of digital events must align with physical milestones

CTN Implementation (2026):

• Association Register: Links legal entities to digital identities (VAD tokens).
• Endpoint Registration: Maps registered API endpoints to the data products a provider exposes.
• Local authorisation at the data provider: each provider verifies the VAD and applies its own policy before releasing operational data.

Verification:

• Digital identities verified against official registries (National Chamber(s) of Commerce, LEI, VIES)
• Transport relationships validated before digital access granted
• Real-time synchronization between operational state and digital records

---

Principle 2: Event-Driven Architecture

Definition: Systems communicate through asynchronous events representing state changes rather than direct API calls.

Rationale:

• Loose coupling between components
• Scalability through publish-subscribe patterns
• Real-time notifications of relevant changes
• Audit trail through event history

Requirements:

1. State changes must trigger events
2. Events must be published to interested subscribers
3. Event format must follow standard specifications (CloudEvents)
4. Event ordering and delivery must be reliable

CTN Implementation (2026):

• Event broker: Reference implementation uses a cloud-managed event broker (Azure Event Grid as reference; AWS EventBridge, Apache Pulsar or Kafka as equally valid alternatives — see Solution Strategy). The 2026 delivery does not require a CTN-wide event bus: providers expose their own webhooks and consumers subscribe at the source.
• Event Categories:
  • Participation events (participant.joined, participant.verified, participant.suspended)
  • Endpoint events (endpoint.registered, endpoint.suspended, endpoint.retired)
  • Data-product events (per provider — provider-defined types such as milestone.reached, status.changed)
• Subscribers: data consumers subscribe to the provider’s events directly.
• Event Sourcing: complete audit trail of all state changes inside the ASR.

Event Schema Example:

{
  "specversion": "1.0",
  "type": "ctn.participant.verified",
  "source": "association-register",
  "id": "A234-1234-1234",
  "time": "2026-05-29T14:30:00Z",
  "datacontenttype": "application/json",
  "data": {
    "participant_id": "ORG-789012",
    "verification_source": "KvK",
    "verified_at": "2026-05-29T14:29:55Z"
  }
}

---

Principle 3: Zero Trust

Definition: No implicit trust exists between parties. Every interaction requires explicit verification and authorization.

Rationale:

• Enhanced security through continuous verification
• Protection against compromised credentials
• Clear accountability for all actions
• Reduced impact of security breaches

Requirements:

1. Every request must be authenticated
2. Every request must be authorized
3. Trust relationships must be explicitly established
4. Verification must occur at every boundary
5. Least privilege access principles

CTN Implementation (2026):

• No Implicit Trust: every request from a consumer carries a VAD that the provider re-validates.
• VAD-based authorisation: the VAD proves participation and trustworthiness. The data provider decides locally what that participation entitles the consumer to.
• Policy-Based Decisions: the data provider evaluates whether the request can be authorised.
• Audit Trail: complete logging of authentication and authorisation decisions.

Zero Trust Flow (2026):

1. Network Trust (is the request from an allowed network?)
2. Authentication (the OAuth client credential is verified by the IdP)
3. Business Assurance (the VAD signature, claims and expiry are validated against the ASR’s JWKS)
4. Data Appropriateness (does this consumer’s tier / participation status allow this data product?)
5. Final Decision (combine all factors for the access decision)

---

Principle 4: Dynamic Data

Definition: Data represents current operational state and is accessed in real-time rather than through static copies.

Rationale:

• Ensures decisions based on latest information
• Eliminates data synchronization issues
• Supports time-sensitive operations
• Reduces storage and maintenance overhead

Requirements:

1. Data must reflect current operational state
2. Stale data must be detectable (timestamps, versions)
3. Updates must propagate to interested parties
4. Cache invalidation strategies must exist
5. Real-time access patterns must be supported

CTN Implementation (2026):

• Real-Time Authorisation: the data provider makes decisions based on the freshly-validated VAD and its own current policy.
• Cache with TTL: providers cache the ASR’s JWKS with a short TTL; participation status is re-checked at token-refresh time.
• Event Notifications: changes propagate immediately via the provider’s webhooks.
• API Design: RESTful endpoints return current state, not snapshots.
• Temporal Data: all records include timestamps for freshness verification.

---

Principle 5: Data at the Source

Definition: Data remains with its owner/custodian and is accessed through controlled interfaces rather than being centrally replicated.

Rationale:

• Data sovereignty maintained by data owners
• Single source of truth
• Reduced data governance complexity
• Clear liability and responsibility
• GDPR compliance through data minimization

Requirements:

1. Data must remain with custodians
2. Access must be controlled by data custodians
3. No mandatory central data repositories
4. APIs must provide controlled access
5. Data ownership must be clear

CTN Implementation (2026):

• Distributed Architecture: one shared register (the ASR) for identity and discovery; data stays with the providers.
  • Association Register: controls participation data.
  • Data Owner / Provider Systems: control operational data and policy.
• No Central Data Lake: data never leaves the provider’s systems.
• API-Based Access: standardised interfaces for data retrieval; OpenAPI for every registered endpoint.
• Policy Enforcement: providers control access policies; CTN does not run a central PDP in 2026.
• Selective Disclosure: providers can vary the data shape they release per requester tier, per data product, per jurisdiction.

The exact access-tier model is policy-owned by each data provider in 2026; CTN does not impose a single FULL/LIMITED/BASIC scheme on the network.

---

Principle 6: Local Decision-Making

Definition: Organizations maintain autonomy over their own authorization policies and business rules without central control.

Rationale:

• Business sovereignty
• Flexibility for organizational requirements
• Reduced coordination overhead
• Resilient architecture (no central point of failure)
• Faster decision-making

Requirements:

1. Organizations control their own policies
2. No mandatory central policy authority
3. Interoperability through standards, not central control
4. Local policy enforcement
5. Transparent decision-making

CTN Implementation (2026):

• Single shared register: the ASR controls participation and discovery; everything else is local.
• Local Authorisation: each data provider runs its own access-control logic on validated VAD claims.
  • Policies defined by the provider.
  • No central policy repository.
• Federation, Not Centralisation:
  • Standards enable interoperability.
  • Each organisation makes its own access decisions.
  • Voluntary participation.

Example: Custodian Autonomy:

Terminal A Policy:
- Verified participants get real-time ETA updates
- Non-participants get hourly updates
- Weather data only for verified participants

Terminal B Policy:
- All parties get real-time updates
- Premium-tier participants get predictive ETAs
- Free tier has rate limits

Both valid CTN implementations with different business rules

---

Principle 7: Coherent Security

Definition: Security measures must work together across all layers to provide comprehensive protection without gaps or conflicts.

Rationale:

• Defense in depth
• No single point of failure
• Comprehensive audit trail
• Regulatory compliance
• Risk mitigation

Requirements:

1. Security must span all architectural layers
2. Security measures must not conflict
3. Complete audit trails must exist
4. Compliance must be demonstrable
5. Security must not compromise usability

CTN Implementation:

Network Layer:

• Private endpoints for databases
• Network Security Groups (NSGs)
• Web Application Firewall (WAF)
• DDoS protection

Identity Layer:

• Keycloak (self-hosted) as the single IdP, with outward federation (Entra ID / eHerkenning / local) per ADR-00008.
• Managed identities for cloud-provider integrations.
• OAuth 2.0 / OIDC for API access (client credentials for M2M).
• MFA enforced on admin surfaces.

Application Layer:

• VAD-based authorisation (signed JWT)
• Provider-side policy-based access control
• Rate limiting and throttling
• Input validation

Data Layer:

• Encryption at rest (AES-256)
• Encryption in transit (TLS 1.3)
• Column-level encryption for PII
• Key rotation policies

Monitoring Layer:

• Azure Sentinel for threat detection
• Log Analytics for audit trails
• Real-time alerting
• Security Information and Event Management (SIEM)

Coherence Through:

Trust Chain (2026):
1. Network verification (allowed sources)
2. Identity verification (OAuth authentication via the IdP)
3. Business assurance (VAD signature + claims validated against JWKS)
4. Policy evaluation (provider's local policy)
5. Data access (shaped response)
6. Audit logging (complete trail)

All layers work together, no gaps.

BDI Compliance Criteria

An implementation is BDI-compliant when:

1. ✅ Physical-Digital Connection: Digital state reflects physical operations
2. ✅ Event-Driven: State changes propagate via events
3. ✅ Zero Trust: Every interaction explicitly verified
4. ✅ Dynamic Data: Current state accessible in real-time
5. ✅ Data at Source: Data stays with custodians
6. ✅ Local Decisions: Autonomous policy control
7. ✅ Coherent Security: Defense in depth across all layers

Deviation Guidelines

When an implementation needs to deviate from BDI principles:

1. Document the Deviation: Create ADR explaining why
2. Classify the Type:
   • BDI-Extended: Adds capabilities (usually acceptable)
   • BDI-Adapted: Modifies approach (requires justification)
   • Non-BDI: Violates principles (rarely acceptable)
3. Assess Impact: How does it affect interoperability?
4. Provide Justification: Domain-specific requirements that necessitate deviation
5. Get Approval: Architecture review must approve deviations

Relationship to Standards

BDI principles align with and extend:

• GDPR: Data sovereignty and minimization
• Zero Trust Architecture: NIST 800-207
• Event-Driven Architecture: CloudEvents specification
• API Design: OpenAPI, RESTful principles
• Data Governance: ISO 27001, SOC 2

References

• BDI Framework Official Documentation: https://bdi.gitbook.io/public

---