Architecture: BetterFleet OCPP Profile 3 and ISO 15118 PKI¶

TLDR (Solution Summary)¶

• Build a BetterFleet Certificate Control Plane that remains the lifecycle source of truth for charger identity certificates, vehicle VAS identity certificates, ISO 15118 provisioning artifacts, and trust-anchor bundles.
• Add a Certificate Lifecycle API in bf-manage-core that owns inventory, policy, certificate jobs, activation evidence, revocation intent, and audit for every certificate purpose.
• Add an OCPP Security Orchestrator in bf-manage-connect that executes SignCertificate, CertificateSigned, InstallCertificate, GetInstalledCertificateIds, DeleteCertificate, GetCertificateStatus, Get15118EVCertificate, SecurityEventNotification, GetLog, and LogStatusNotification without becoming the lifecycle source of truth.
• Use AWS Private CA for BetterFleet-managed operational certificate issuance and revocation, and use AWS ACM for central-system server certificates where AWS-managed termination is available.
• Add an External Scheme Broker for Hubject, OCPI, OEM, and other Plug and Charge actors so BetterFleet can operate in BetterFleet-managed, BetterFleet-brokered, and externally managed but BetterFleet-tracked modes per certificate purpose.
• Add a Trust Anchor Release Manager that versions, distributes, confirms, and rolls back purpose-specific trust-anchor bundles before dependent leaf certificates are activated.

1. Summary¶

• Problem statement:
  • BetterFleet needs a production architecture for OCPP Profile 3 and ISO 15118 certificate lifecycle management that fits the existing spec and avoids building multiple independent PKI systems.
  • The current spec already fixes several architectural constraints: BetterFleet remains the lifecycle source of truth, local key generation is required for endpoint-owned keys, AWS is the retained platform assumption, and charger, vehicle, ISO 15118, backend, and firmware-signing trust must stay separate.
• Goal and success criteria:
  • Deliver one concrete architecture that can issue, install, activate, renew, revoke, and audit BetterFleet-managed certificates while also tracking or brokering externally governed Plug and Charge certificate flows.
  • Success means one operator-visible inventory, one job and policy model, one OCPP orchestration path, and a clear separation between internal operational PKI and external ISO 15118 scheme actors.
• What will be built in this phase:
  • Certificate Lifecycle API + add certificate-purpose-aware inventory, policy, and job orchestration in bf-manage-core + BetterFleet becomes the operational source of truth for all managed certificate purposes.
  • Operator Certificate Administration View + extend the existing device certificate UI in bf-manage-web to show charger, vehicle, ISO 15118, and trust-anchor records + operations can inspect state, failures, and actions in one surface.
  • OCPP Security Orchestrator + add standards-aligned certificate message handling in bf-manage-connect + chargers execute install, CSR, status, and security-log flows through a controlled control plane.
  • AWS PKI Integration Layer + connect BetterFleet-managed certificate jobs to AWS Private CA and AWS ACM + BetterFleet uses managed AWS issuance without exposing CA private-key control to runtime services.
  • External Scheme Broker + add adapters for Hubject, OCPI, OEM, and other external approval authorities + BetterFleet can track and broker Plug and Charge workflows without pretending to own every certificate purpose.
  • Trust Anchor Release Manager + version and stage purpose-specific CA bundle rollout + root and intermediate updates become controlled rollout events with audit and rollback support.
• Scope (in/out) for this phase:
  • In:
  • Concrete logical and deployment architecture for the BetterFleet lifecycle service, OCPP orchestration, AWS PKI integration, external-scheme brokering, and operator visibility.
  • Concrete ownership boundaries for charger identity, vehicle VAS identity, ISO 15118 provisioning artifacts, trust anchors, and server certificates.
  • Concrete interaction flows for issuance, activation, renewal, revocation, trust-anchor rollout, and Plug and Charge brokering.
  • Out:
  • Detailed database schema design.
  • Final OEM-specific subject naming rules.
  • Firmware-signing PKI beyond trust-domain separation.
  • Exact OCPI payload definitions for each partner.
• Current baseline:
  • As of March 10, 2026, BetterFleet already has an IoT-oriented certificate inventory and operator action pattern in bf-manage-web and bf-manage-core, but not the OCPP 2.0.1 certificate orchestration handlers required for Profile 3 rollout.
  • As of March 10, 2026, bf-manage-connect has local OCPP 2.0.1 schemas but no production certificate orchestration flow.
• Future evolution guardrails:
  • This architecture must keep it easy to add new certificate purposes without creating a new service per purpose.
  • This architecture must keep external-scheme integration separate from the BetterFleet-managed CA path.
  • This architecture must not make firmware-signing trust share a hierarchy or operator workflow with operational identities.

2. Users and Use Cases¶

• Primary personas:
  • Platform engineer
  • OCPP integration engineer
  • Security and PKI engineer
  • Operations team managing rollout and incidents
  • External provisioning integration team
• High-level user stories:
  • As operations, I want one certificate inventory and one trust-anchor inventory so I can govern rollout and incident handling consistently.
  • As a PKI engineer, I want BetterFleet runtime services to request issuance without holding CA private-key control.
  • As an OCPP engineer, I want charger certificate flows to map to OCPP 2.0.1 security messages while BetterFleet remains authoritative for lifecycle state.
  • As a Plug and Charge integration team, I want BetterFleet to broker or track external certificate workflows without forcing all external PKI actors into the BetterFleet-managed model.
• Edge cases and failure modes:
  • Charger generates a CSR, receives a signed certificate, installs it, but never reconnects successfully over mutual TLS.
  • Trust-anchor bundle rollout succeeds on some charger families and fails on others.
  • An external Plug and Charge authority issues or revokes a credential and BetterFleet must reflect the new state without controlling issuance.
  • A device remains on Profile 2 during migration and must keep unique dual-slot AuthorizationKey handling.

3. Conceptual Model Terms and Decisions¶

Key Terms¶

Decision Ledger¶

4. Architecture Overview¶

Logical Component Model¶

flowchart LR
  UI["bf-manage-web\nOperator Certificate Administration View"]
  Core["bf-manage-core\nCertificate Lifecycle API\nPolicy Engine\nInventory\nJob Orchestrator\nAudit"]
  Connect["bf-manage-connect\nOCPP Security Orchestrator\nProtocol Compatibility Adapter\nSecurity Event Ingestor"]
  AwsPca["AWS Private CA\nPurpose-specific issuing CAs"]
  Acm["AWS ACM\nServer certificate management"]
  Broker["External Scheme Broker\nHubject / OCPI / OEM adapters"]
  Anchors["Trust Anchor Release Manager"]
  Charger["Charge Point / EVSE\nLocal key generation\nCSR / install / reconnect"]
  Vehicle["Vehicle / VAS program\nDirect or brokered delivery"]
  Scheme["External PnC PKI / eMSP / OEM"]
  Obs["Audit + Observability\nLogs / metrics / alerts"]

  UI --> Core
  Core --> Connect
  Core --> AwsPca
  Core --> Acm
  Core --> Broker
  Core --> Anchors
  Connect --> Charger
  Broker --> Scheme
  Broker --> Vehicle
  Anchors --> Connect
  Core --> Obs
  Connect --> Obs
  Broker --> Obs

• bf-manage-web
  • Presents the operator views for certificate inventory, trust-anchor bundle inventory, migration cases, provisioning cases, and job history.
  • Reuses the current certificate action pattern and extends it to multiple certificate purposes.
• bf-manage-core
  • Owns certificate records, trust-anchor records, policy evaluation, lifecycle commands, job state, and audit history.
  • Exposes admin and automation APIs for issue, renew, revoke, activate, deactivate, delete, install-trust-anchor, and record-provisioning-outcome actions.
  • Publishes job intents to asynchronous workers and reconciles evidence from OCPP and external integrations.
• bf-manage-connect
  • Owns OCPP 2.0.1 security message handling and the compatibility adapter for Profile 2 and OCPP 1.6J transitional fleets.
  • Converts lifecycle commands from bf-manage-core into OCPP actions and converts charger responses, logs, and events into activation evidence.
• AWS Private CA
  • Hosts the BetterFleet-managed issuing CAs for charger identity and vehicle VAS identity.
  • Is invoked only by a restricted CA integration module in bf-manage-core.
• AWS ACM
  • Manages public or private server certificates for BetterFleet endpoints that terminate on ACM-capable AWS services.
• External Scheme Broker
  • Handles Hubject, OCPI, OEM, or other program-specific Plug and Charge interactions where BetterFleet is not the issuer.
  • Stores external references, provisioning status, fingerprints, expiry, and evidence back into the BetterFleet inventory.
• Trust Anchor Release Manager
  • Packages purpose-specific root and intermediate chains into versioned bundles.
  • Tracks intended, delivered, installed, active, failed, and withdrawn bundle versions by target cohort.

Deployment View¶

flowchart TD
  subgraph AWS_VPC["BetterFleet AWS Account / VPC"]
    Web["bf-manage-web"]
    CoreApi["bf-manage-core API"]
    Workers["Certificate Job Workers"]
    ConnectSvc["bf-manage-connect OCPP service"]
    Queue["Job Queue"]
    Store["Operational data store"]
    Artifact["Certificate / bundle artifact store"]
    Metrics["Observability stack"]
  end

  subgraph AWS_SEC["Restricted PKI Control Plane"]
    PCA["AWS Private CA hierarchy"]
    ACM["AWS ACM"]
    IAM["Restricted IAM roles"]
  end

  subgraph EXT["External actors"]
    Chargers["Chargers / EVSEs"]
    Hubject["Hubject / PnC PKI"]
    OEM["OEM / OCPI / eMSP systems"]
  end

  Web --> CoreApi
  CoreApi --> Queue
  Queue --> Workers
  Workers --> Store
  Workers --> Artifact
  Workers --> PCA
  Workers --> ACM
  CoreApi --> Store
  CoreApi --> Metrics
  ConnectSvc --> Chargers
  Workers --> ConnectSvc
  Workers --> Hubject
  Workers --> OEM
  ConnectSvc --> Metrics
  Workers --> Metrics
  IAM --> PCA
  IAM --> ACM

• Runtime services do not hold CA private keys.
• The CA hierarchy sits behind restricted IAM roles and a dedicated PKI control-plane boundary.
• Long-running certificate work is executed by asynchronous job workers, not by request threads.

5. PKI Realms and Ownership Model¶

Purpose-Specific PKI Realms¶

CA Hierarchy¶

• Concrete recommendation:
  • Start with one operational root and at least two issuing CAs under it only if policy accepts shared root isolation.
  • If customer, compliance, or incident concerns are strong, split charger and vehicle VAS to separate roots early.
  • Keep ISO 15118 external scheme roots outside the BetterFleet-managed issuing hierarchy even when BetterFleet tracks them in inventory.

6. Domain Model and Eventstorming (Concrete)¶

• Bounded contexts:
  • Certificate Lifecycle in bf-manage-core
  • EVSE Security Orchestration in bf-manage-connect
  • External Provisioning Brokerage in the integration layer
  • Operator Administration in bf-manage-web
• Aggregates and entities:
  • ManagedIdentity
  • CertificateRecord
  • TrustAnchorBundle
  • CertificateJob
  • MigrationCase
  • ProvisioningCase
• Domain events:
  • CertificateRequested
  • CSRValidated
  • CertificateIssued
  • CertificateInstallRequested
  • CertificateInstalled
  • CertificateActivated
  • CertificateDeactivated
  • CertificateRenewalStarted
  • CertificateRevoked
  • TrustAnchorReleaseRequested
  • TrustAnchorInstalled
  • ProvisioningOutcomeRecorded
  • MigrationQuarantined

Interaction Flow¶

flowchart LR
  Trigger["Operator / policy / device trigger"] --> Cmd["Lifecycle command"]
  Cmd --> Job["Create CertificateJob"]
  Job --> Route{"Execution path"}
  Route -->|BetterFleet-managed| CA["AWS Private CA issuance"]
  Route -->|OCPP execution| OCPP["bf-manage-connect OCPP actions"]
  Route -->|Brokered| Ext["Hubject / OEM / OCPI broker flow"]
  CA --> Evidence["Evidence returned"]
  OCPP --> Evidence
  Ext --> Evidence
  Evidence --> Policy["Activation / reconciliation policy"]
  Policy --> State["Update CertificateRecord / ProvisioningCase / MigrationCase"]

Event Timeline¶

timeline
  title Charger Identity Certificate Timeline
  CertificateRequested : Renewal or issuance starts
  CSRValidated : CSR accepted against identity policy
  CertificateIssued : AWS Private CA returns signed chain
  CertificateInstalled : Charger confirms install
  CertificateActivated : Successful mutual-TLS reconnect recorded

Event Dictionary¶

• CertificateRequested: BetterFleet decides a certificate action is needed | starts lifecycle work | jobId, managedIdentityId, purpose, reason | triggers execution routing.
• CSRValidated: Submitted CSR matches policy and identity | protects issuance correctness | jobId, csrFingerprint, subjectKeyId | enables CA signing.
• CertificateIssued: Signed chain is available | creates installable artifact | jobId, certificateId, issuingCaId, notBefore, notAfter | triggers install path.
• CertificateInstalled: Endpoint or external actor confirms delivery | creates activation candidate | jobId, certificateId, evidenceType, evidenceRef | enables activation policy.
• CertificateActivated: Required evidence proves the credential is live | moves record to active | certificateId, activatedAt, evidenceRef | retires previous active cert.
• CertificateDeactivated: An active certificate is intentionally removed from service without revocation | moves record to inactive | certificateId, deactivatedAt, reason, actor | clears the active slot for that identity and purpose.
• ProvisioningOutcomeRecorded: External Plug and Charge flow advanced state | keeps brokered paths visible | provisioningCaseId, externalRef, newState | updates case and operator view.
• MigrationQuarantined: Rollout stopped for manual review | prevents unsafe automation | migrationCaseId, reason, chargerFamily, attemptCount | raises operational attention.

7. Interaction and Flow¶

Charger Identity Certificate Flow¶

sequenceDiagram
  participant Policy as Policy Engine
  participant Core as bf-manage-core
  participant PCA as AWS Private CA
  participant Connect as bf-manage-connect
  participant Charger as Charger

  Policy->>Core: Issue or renew charger certificate
  Core->>Connect: Request CSR via OCPP security flow
  Connect->>Charger: SignCertificate / CSR exchange
  Charger-->>Connect: CSR
  Connect-->>Core: CSR + device evidence
  Core->>PCA: Issue certificate from charger issuing CA
  PCA-->>Core: Signed certificate chain
  Core->>Connect: Install certificate + chain
  Connect->>Charger: CertificateSigned / InstallCertificate
  Charger-->>Connect: Install accepted
  Connect-->>Core: Installation evidence
  Charger->>Connect: Reconnect using mutual TLS
  Connect-->>Core: Successful activation evidence
  Core->>Core: Mark certificate active and retire previous leaf

• Activation rule:
  • A charger certificate does not become active on install acknowledgement alone.
  • It becomes active only after successful Profile 3 reconnect or another approved live-use signal.

Trust Anchor Bundle Rollout¶

sequenceDiagram
  participant Ops as Operator / Policy
  participant Core as bf-manage-core
  participant Connect as bf-manage-connect
  participant Charger as Charger

  Ops->>Core: Release trust-anchor bundle to cohort
  Core->>Core: Create bundle version and rollout job
  Core->>Connect: Install trust bundle on target chargers
  Connect->>Charger: InstallCertificate for root/intermediate chain
  Charger-->>Connect: Bundle install status
  Connect-->>Core: Installation evidence by charger
  Core->>Core: Mark bundle intended / installed / active / failed
  Core->>Core: Unblock dependent leaf rollout only after threshold met

Plug and Charge Brokered Flow¶

sequenceDiagram
  participant Core as bf-manage-core
  participant Broker as External Scheme Broker
  participant Scheme as Hubject / OEM / eMSP
  participant UI as bf-manage-web

  Core->>Broker: Start provisioning case
  Broker->>Scheme: Submit request or validation call
  Scheme-->>Broker: External status / approval / certificate reference
  Broker-->>Core: Evidence, fingerprint, expiry, external reference
  Core->>Core: Update ProvisioningCase and certificate-tracking record
  UI-->>Core: View case, status, errors, next actions

Revocation and Incident Flow¶

• BetterFleet-managed certificate revocation:
  • bf-manage-core marks the certificate revoked in local policy first.
  • The CA integration submits revocation to AWS Private CA.
  • bf-manage-connect or related relying-party components are instructed to deny further use even before remote confirmation propagates.
• Brokered or tracked-only revocation:
  • BetterFleet records external revocation evidence and transitions the local record to a blocked or invalid state.
  • Incident routing points operators to the responsible external authority.

8. Requirements and Constraints¶

• Functional requirements:
  • FR-001: bf-manage-core shall remain the lifecycle source of truth for certificate state, policy outcome, and audit for every certificate purpose in scope.
  • FR-002: bf-manage-connect shall execute OCPP Profile 3 certificate operations as transport and evidence collection, not as the lifecycle source of truth.
  • FR-003: BetterFleet-managed charger and vehicle VAS certificates shall be issued through AWS Private CA using CSR-driven issuance.
  • FR-004: BetterFleet shall version and manage trust anchors as separate TrustAnchorBundle records by purpose and target cohort.
  • FR-005: BetterFleet shall support the three operating modes managed, brokered, and tracked-only per certificate purpose.
  • FR-006: Activation of charger identity certificates shall require installation evidence plus successful live-use verification.
  • FR-007: External Plug and Charge integrations shall store external references, fingerprints, expiry, status, and audit evidence even when BetterFleet is not the issuer.
  • FR-008: Runtime services shall request CA actions through restricted integration roles and shall not hold unrestricted root or issuing-CA private-key control.
  • FR-009: The operator UI shall show certificate state, job state, trust-anchor rollout state, migration state, and provisioning state in one administration experience.
  • FR-010: Migration support shall coexist with unique per-device AuthorizationKey lifecycle for cohorts that remain on Profile 2 during transition.
• Non-functional requirements:
  • NFR-001: All certificate and trust-anchor jobs shall be idempotent across retries and reconnects.
  • NFR-002: The system shall preserve auditability of every lifecycle transition, external evidence update, and operator action.
  • NFR-003: The system shall isolate failures by charger family, site cohort, certificate purpose, and external integration path to avoid fleet-wide rollout impact.
  • NFR-004: Certificate policy values such as validity, renewal thresholds, and escalation windows shall be configurable by certificate purpose and cohort.
  • NFR-005: Security observability shall capture issuance failures, install failures, activation failures, trust-anchor mismatch, revocation backlog, and security-event notifications.
• Constraints and assumptions:
  • Charger and vehicle identity remain endpoint-owned keys and therefore CSR-driven.
  • The current design reference for charger certificates is 180-day validity with T-30, T-14, and T-7 thresholds.
  • External Plug and Charge actors may remain the issuer or approval authority for some ISO 15118 certificate purposes.
  • Firmware support for local key generation, trust-anchor install, and mutual-TLS reconnect is a hard rollout dependency.
• Build item coverage mapping:
  • Certificate Lifecycle API -> FR-001, FR-005, FR-008, NFR-002, NFR-004
  • Operator Certificate Administration View -> FR-009, NFR-002, NFR-005
  • OCPP Security Orchestrator -> FR-002, FR-006, FR-010, NFR-001, NFR-003
  • AWS PKI Integration Layer -> FR-003, FR-008, NFR-001
  • External Scheme Broker -> FR-005, FR-007, NFR-002
  • Trust Anchor Release Manager -> FR-004, NFR-003, NFR-005

9. Non-Technical Implementation Approach¶

• Phase 1: control plane foundation
  • Extend the existing BetterFleet certificate inventory model and operator UI to support multiple certificate purposes, trust-anchor bundles, migration cases, and provisioning cases.
  • Add the asynchronous certificate job model and CA integration boundary in bf-manage-core.
• Phase 2: charger path
  • Implement the OCPP security orchestrator in bf-manage-connect.
  • Stand up the charger issuing CA, trust-anchor bundle packaging, and activation-evidence reconciliation.
  • Pilot with one charger family that supports local key generation, trust-anchor install, and mutual-TLS reconnect.
• Phase 3: brokered Plug and Charge path
  • Add Hubject or equivalent external broker adapters.
  • Introduce provisioning-case management and external evidence ingestion for tracked-only and brokered flows.
• Phase 4: vehicle VAS path
  • Add direct and brokered vehicle identity issuance flows with separate policy and trust anchors from charger identity.

• Phase 5: scale-out and policy hardening

  • Add cohort-level rollout controls, exception handling, security dashboards, and automated renewal at fleet scale.

• Key tradeoffs:

  • This architecture prefers one BetterFleet control plane with multiple execution adapters over multiple specialized PKI applications.
  • It buys AWS managed CA operations instead of building a general-purpose enterprise PKI stack.
  • It keeps external Plug and Charge authorities first-class rather than treating them as temporary workarounds.

• Dependencies:

  • Firmware capability on at least one charger family.
  • AWS account design for restricted PKI roles.
  • Hubject or equivalent partner onboarding where Plug and Charge brokering is needed.
  • Operational runbooks for trust-anchor rollout and rollback.

10. Open Questions¶

• Should charger identity and vehicle VAS identity split to separate roots immediately, or start with separate issuing CAs under one operational root?
• Which ISO 15118 certificate purposes will BetterFleet actually issue directly in the first customer program, if any?
• Which external broker interface is first: Hubject direct, OCPI-based brokering, or OEM-specific API?
• What activation evidence beyond successful mutual-TLS reconnect is acceptable for charger families with non-standard behavior?
• What certificate inventory detail is contractually allowed to be stored for externally managed Plug and Charge credentials?

11. Appendices¶

Recommended Initial Service Placement¶

Concrete Initial AWS Shape¶

Concrete Initial Build Order¶

1. Extend bf-manage-core inventory, policy, and async job orchestration.
2. Extend bf-manage-web admin views and actions.
3. Implement bf-manage-connect charger certificate and trust-anchor flows.
4. Stand up AWS Private CA issuing hierarchy and IAM boundaries.
5. Add Hubject or other broker integration for Plug and Charge tracking and brokering.

Cross-Reference to Specification Document¶

• Companion document: spec.md
• Relationship: The specification defines the conceptual lifecycle model, domain events, invariants, standards crosswalk, and business requirements. This architecture document concretizes those into service assignments, AWS infrastructure choices, PKI realm design, deployment topology, and phased build order.

Decision Traceability¶

Requirements Traceability¶

Build Item Traceability¶

Bounded Context Mapping¶

Spec Material Not Yet Concretized in Architecture¶

• The spec's Standards Crosswalk (Section 5) maps OCPP 1.6, OCPP 2.0.1, ISO 15118, and VDV 261 to BetterFleet requirements. The architecture does not repeat this crosswalk but inherits its conclusions.
• The spec's ISO 15118 and VDV Ownership Decision Framework appendix defines a certificate-purpose decision matrix that must be completed per program. The architecture references three operating modes (managed, brokered, tracked-only) but does not reproduce the full matrix.
• The spec's Profile 2 AuthorizationKey Hardening appendix details dual-slot rotation workflow, credential-baseline expectations, and rotation triggers. The architecture references AuthorizationKey lifecycle in FR-010 but defers the detailed rotation design.
• The spec's Renewal and Validity Policy appendix preserves 180-day / T-30 / T-14 / T-7 charger certificate policy values as configurable defaults. The architecture's constraints section references these values but does not expand on policy-field configurability.
• The spec's Delivery Workstreams and Readiness Dependencies appendix maps firmware, backend, platform, PKI, and operations workstreams with concrete milestone definitions. The architecture's phased build order is consistent but less granular.

Event Dictionary Reconciliation¶

• CertificateDeactivated: Now present in both documents.
• CertificateInstallRequested, CertificateRenewalStarted, and TrustAnchorReleaseRequested: Now present in both documents. These events were originally architecture-level concretizations; the spec has adopted them as conceptual events.
• Provisioning event naming remains open: The spec uses Iso15118ProvisioningStateChanged (state-progression focus, ISO 15118-specific) while the architecture uses ProvisioningOutcomeRecorded (evidence-capture focus, domain-neutral). See the spec's cross-reference appendix for a detailed analysis and recommendation. This should be resolved before implementation.