<-Trust Establishment Protocol      Go to ToC    End‑to‑End Examples->

1. Requirements

1.1 Overview

This chapter defines the requirements for conformance to the MPAI‑PTF Trust Framework.
A conforming implementation shall:

  • correctly process all mandatory PTF data types
  • correctly execute the Verification Pipeline
  • correctly enforce Zero‑Trust requirements
  • correctly apply security and policy constraints
  • correctly generate and validate Trust Messages
  • correctly handle post‑trust Data Exchange Metadata (DEM)

Conformance applies to implementations, components, and PTF objects.

1.2 Conformance Classes

PTF defines four conformance classes:

1.2.1 Verifier

An implementation that performs the Verification Pipeline and produces TrustResponses.

A conforming Verifier shall:

  • implement all mandatory verification steps
  • validate all PTF data types
  • enforce policies and profiles
  • generate TrustOperations
  • sign TrustResponses

1.2.2 Process Instance (PI)

An implementation that participates in trust establishment and data exchange.

A conforming PI shall:

  • generate valid CII
  • provide valid credentials and evidence
  • respond to TrustRequests
  • enforce DEM authorisations and legality constraints

1.2.3 Policy Authority

An implementation that issues policies and trust anchors.

A conforming Policy Authority shall:

  • generate valid PolicyBinding objects
  • sign policies using SAT algorithms
  • maintain trust anchors

1.2.4 Data Producer / Consumer

An implementation that exchanges data after trust is established.

A conforming Data Producer/Consumer shall:

  • generate valid DEM
  • enforce DEM authorisations
  • preserve provenance and annotations

1.3 Data Type Conformance

A conforming implementation shall:

1.3.1 General

  • accept all mandatory fields
  • reject undeclared fields
  • validate all signatures using SAT
  • validate all timestamps and validity intervals
  • validate all identifiers and taxonomies

1.3.2 Specific Data Types

Data Type Conformance Requirements
CII Must be signed; must include valid roles; must use SAT algorithms
InstanceCredential Must be signed; must bind to a valid CII; must include validity interval
ProcessLifecycleCredential Must reflect correct lifecycle state; must be signed
AttestationEvidence Must use SET types; must include hash + signature; must include freshness indicators
PolicyBinding Must be signed; must bind to correct target; must reference valid profiles
VerificationProfile Must define deterministic rules; must reference valid taxonomies
TrustMessage Must be signed; must include MessageType; must include Request or Response
TrustOperation Must be generated for each verification step; must be signed
DataExchangeMetadata (DEM) Must include DataID and Source; must include authorisations; must include legality/security metadata

1.4 Verification Pipeline Conformance

A conforming Verifier shall implement all of the following steps:

  1. Request Intake
  2. Identity Verification
  3. Credential Verification
  4. Evidence Verification
  5. Policy Evaluation
  6. Decision Logic
  7. TrustResponse Generation
  8. TrustOperation Logging

Each step shall:

  • validate all required data types
  • reject malformed or unverifiable objects
  • produce a TrustOperation entry

A conforming Verifier shall not skip or reorder mandatory steps.

1.5 Security Conformance

A conforming implementation shall:

1.5.1 Cryptography

  • use only SAT‑approved algorithms
  • reject deprecated or weak algorithms
  • validate all signatures and hashes

1.5.2 Freshness

  • validate timestamps
  • validate validity intervals
  • reject stale evidence or credentials

1.5.3 Non‑repudiation

  • sign TrustResponses
  • sign TrustOperations

1.5.4 Zero‑Trust Enforcement

  • assume no PI, credential, or message is trusted by default
  • require explicit verification for all trust decisions

1.6 Policy Conformance

A conforming implementation shall:

  • authenticate PolicyBinding objects
  • enforce VerificationProfile rules deterministically
  • reject trust establishment if any policy fails
  • ensure policy evaluation cannot be bypassed

1.7 Trust Protocol Conformance

A conforming implementation shall:

  • generate valid TrustRequests
  • generate valid TrustResponses
  • sign all TrustMessages
  • include timestamps to prevent replay
  • reject unsigned or tampered messages

1.8 Data Exchange Conformance (Post‑Trust)

A conforming implementation shall:

  • generate valid DEM for all exchanged data
  • enforce DEM authorisations
  • enforce legality constraints
  • enforce security metadata
  • preserve provenance and annotations

1.9 Interoperability Conformance

A conforming implementation shall:

  • accept any valid PTF object from any conforming implementation
  • produce PTF objects that other conforming implementations can process
  • use only normative taxonomies and schemas

1.10 Conformance Testing

A conforming implementation shall pass:

  • structural validation of all PTF data types
  • cryptographic validation tests
  • pipeline execution tests
  • policy enforcement tests
  • DEM enforcement tests
  • interoperability tests

A Conformance Test Suite outline is provided in the next chapter.

Here are the three deliverables you requested — all clean, structured, and ready to drop into your Conformance chapter.

1.11. Conformance Summary Table

This table gives a one‑page overview of everything a conforming implementation must satisfy.

PTF Conformance Summary

Conformance Area Requirements Applies To
Data Types Validate structure, reject undeclared fields, verify signatures, timestamps, validity intervals Verifier, PI
Verification Pipeline Implement all 8 mandatory steps; produce TrustOperations; deterministic evaluation Verifier
Security Use SAT algorithms; enforce freshness; sign TrustResponses and TrustOperations Verifier, PI
Zero‑Trust Assume no trust by default; require explicit verification Verifier
Policies Authenticate PolicyBinding; enforce VerificationProfile rules; prevent bypass Verifier
Trust Protocol Generate valid TrustRequests/Responses; sign all messages; prevent replay Verifier, PI
Data Exchange (DEM) Generate valid DEM; enforce authorisations, legality, security metadata PI, Data Producer/Consumer
Interoperability Accept valid PTF objects; produce interoperable objects; use normative schemas All implementations
Auditability Produce signed TrustOperations for each verification step Verifier

2. Conformance Flow Diagram

This diagram shows the full conformance lifecycle from object validation to interoperability.

3.Conformance Testing

3.1. Conventions

  • SUT: System Under Test (Verifier, PI‑A, PI‑B).
  • TR: TrustRequest.
  • TResp: TrustResponse.
  • Status: "Success" or "Failure".
  • Reason: failure reason string as per Reference Pseudocode.

All tests assume a single Verifier, one PI‑A, one PI‑B, and a Policy Authority unless stated otherwise.

3.2. Identity Verification Tests (ID‑xx)

ID‑01 — Valid Identity

  • Purpose: Verify success when CII and roles are valid.
  • Preconditions:
    • CII for PI‑B is valid, signed by trusted anchor.
    • Role PTF-CII-ROLE-DATA-CONSUMER is present and required for operation ReceiveDatasetX.
  • Inputs:
    • TR: TargetID = PI‑B, Operation = ReceiveDatasetX.
    • Valid CII, credentials, evidence, policy, profile.
  • Execution:
    • PI‑A sends TR to Verifier.
    • Verifier runs full pipeline.
  • Expected Results:
    • Identity step: pass.
    • Final TResp: Status = Success, Reason = null.
    • PI‑A sends Data + DEM.

ID‑02 — Invalid CII Signature

  • Purpose: Verifier rejects invalid CII signature.
  • Preconditions:
    • CII for PI‑B has tampered signature.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
    • CII with invalid signature.
  • Execution:
    • PI‑A sends TR.
    • Verifier processes.
  • Expected Results:
    • Identity step fails with InvalidCIISignature.
    • TResp: Status = Failure, Reason = "InvalidCIISignature".
    • No further steps executed.
    • PI‑A sends no data.

ID‑03 — Missing Required Role

  • Purpose: Verifier enforces required role for operation.
  • Preconditions:
    • CII valid but PI‑B lacks required role for ReceiveDatasetX.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
    • CII without required role.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity step fails with MissingRequiredRole.
    • TResp: Status = Failure, Reason = "MissingRequiredRole".
    • No data sent.

ID‑04 — Unknown Role Taxonomy

  • Purpose: Verifier rejects roles outside taxonomy.
  • Preconditions:
    • CII includes role not in Cryptographic Instance Role Taxonomy.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
    • CII with unknown role.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity step fails with UnknownRole.
    • TResp: Status = Failure, Reason = "UnknownRole".
    • No data sent.

3.3. Credential Verification Tests (CR‑xx)

3.3.1 CR‑01 — Valid Credentials

  • Purpose: Verify success when credentials are valid.
  • Preconditions:
    • CII valid.
    • InstanceCredential and PLC valid, signed, not expired.
    • Issuer trusted.
  • Inputs:
    • TR as in ID‑01.
    • Valid credentials, evidence, policy, profile.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity and credential steps pass.
    • Final TResp: Status = Success.
    • Data + DEM sent.

3.3.2 CR‑02 — Missing InstanceCredential

  • Purpose: Verifier rejects missing InstanceCredential.
  • Preconditions:
    • No InstanceCredential for PI‑B.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Credential step fails with MissingInstanceCredential.
    • TResp: Status = Failure, Reason = "MissingInstanceCredential".
    • No data sent.

3.3.3 CR‑03 — Expired InstanceCredential

  • Purpose: Verifier rejects expired credential.
  • Preconditions:
    • InstanceCredential validity interval ended before TR timestamp.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
    • Expired InstanceCredential.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Credential step fails with ExpiredInstanceCredential.
    • TResp: Status = Failure.
    • No data sent.

4.4.4 CR‑04 — Invalid InstanceCredential Signature

  • Purpose: Verifier rejects tampered credential.
  • Preconditions:
    • InstanceCredential signature invalid.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Credential step fails with InvalidInstanceCredentialSignature.
    • No data sent.

3.3.5 CR‑05 — Invalid PLC Lifecycle State

  • Purpose: Verifier enforces PLC state.
  • Preconditions:
    • PLC state ≠ "Running" (e.g., "Stopped").
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Credential step fails with InvalidLifecycleState.
    • No data sent.

3.3.6 CR‑06 — Untrusted Credential Issuer

  • Purpose: Verifier rejects untrusted issuer.
  • Preconditions:
    • InstanceCredential issuer not in TrustAnchors and no valid chain.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Credential step fails with UntrustedCredentialIssuer.
    • No data sent.

3.3.7 CR‑07 — Credential Chain Validation (Example 4)

  • Purpose: Verifier validates chain IA → TrustAnchor.
  • Preconditions:
    • InstanceCredential issued by Intermediate Authority.
    • IA has CredentialIssuerCredential signed by TrustAnchor.
    • TrustAnchor trusted.
    • All other inputs valid.
  • Inputs:
    • TR: Operation = ReceiveDatasetZ.
    • Chain: PI‑B cred ← IA cred ← TrustAnchor.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Credential step passes via chain.
    • TResp: Status = Success.
    • Data + DEM sent.

3.4. Evidence Verification Tests (EV‑xx)

3.4.1 EV‑01 — Valid Evidence

  • Purpose: Verify success with valid, fresh evidence.
  • Preconditions:
    • Evidence type supported.
    • Signature and hash valid.
    • Freshness within profile limit.
  • Inputs:
    • TR as in ID‑01.
    • Valid evidence.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Evidence step passes.
    • TResp: Status = Success.
    • Data + DEM sent.

3.4.2 EV‑02 — Missing Evidence

  • Purpose: Verifier rejects missing evidence.
  • Preconditions:
    • No evidence object for PI‑B.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Evidence step fails with MissingEvidence.
    • No data sent.

3.4.3 EV‑03 — Unsupported Evidence Type

  • Purpose: Verifier enforces required evidence types.
  • Preconditions:
    • Evidence type not in VerificationProfile.RequiredEvidenceTypes.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Evidence step fails with UnsupportedEvidenceType.
    • No data sent.

3.4.4 EV‑04 — Invalid Evidence Signature

  • Purpose: Verifier rejects tampered evidence.
  • Preconditions:
    • Evidence signature invalid.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Evidence step fails with InvalidEvidenceSignature.
    • No data sent.

3.4.5 EV‑05 — Invalid Evidence Hash

  • Purpose: Verifier rejects mismatched hash.
  • Preconditions:
    • Evidence hash does not match expected measurement.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Evidence step fails with InvalidEvidenceHash.
    • No data sent.

3.4.6 EV‑06 — Stale Evidence (Example 2)

  • Purpose: Enforce freshness constraint.
  • Preconditions:
    • Evidence timestamp older than EvidenceFreshnessMax.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
    • Evidence older than allowed.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Evidence step fails with StaleEvidence.
    • Policy step not executed.
    • No data sent.

3.5. Policy Evaluation Tests (PL‑xx)

3.5.1 L‑01 — Valid Policy and Profile

  • Purpose: Verify success when policy and profile are valid and satisfied.
  • Preconditions:
    • PolicyBinding valid and signed.
    • VerificationProfile valid.
    • All rules satisfied.
  • Inputs:
    • TR as in ID‑01.
    • Valid policy and profile.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Policy step passes.
    • TResp: Status = Success.
    • Data + DEM sent.

3.5.2 PL‑02 — Invalid PolicyBinding Signature

  • Purpose: Verifier rejects invalid PolicyBinding.
  • Preconditions:
    • PolicyBinding signature invalid.
    • All other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Policy step fails with InvalidPolicyBinding.
    • No data sent.

3.5.3 PL‑03 — Missing VerificationProfile

  • Purpose: Verifier requires profile.
  • Preconditions:
    • No VerificationProfile for operation.
    • PolicyBinding present.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Policy step fails with InvalidVerificationProfile.
    • No data sent.

3.5.4 PL‑04 — Policy Rule Violation (Example 3)

  • Purpose: Verifier enforces policy rules (e.g., required role).
  • Preconditions:
    • PolicyBinding for dataset Y requires role PTF-CII-ROLE-HIGH-SENSITIVITY.
    • PI‑B only has PTF-CII-ROLE-DATA-CONSUMER.
    • All other inputs valid.
  • Inputs:
    • TR: Operation = ReceiveDatasetY.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Policy step fails with PolicyViolation:RequiredRole (or equivalent).
    • TResp: Status = Failure.
    • No data sent.

3.6. Decision Logic Tests (DL‑xx)

3.6.1 DL‑01 — All Steps Succeed (Example 1)

  • Purpose: Verify full success path.
  • Preconditions:
    • Identity, credentials, evidence, policy all valid and satisfied.
  • Inputs:
    • TR: Operation = ReceiveDatasetX.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • All steps pass.
    • TResp: Status = Success, Reason = null.
    • Data + DEM sent.

3.6.2 DL‑02 — Early Termination on Identity Failure

  • Purpose: Ensure pipeline stops after identity failure.
  • Preconditions:
    • Invalid CII signature.
    • Other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity fails.
    • Credential, evidence, policy steps not executed (no logs).
    • TResp: Status = Failure, Reason = "InvalidCIISignature".

3.6.3 DL‑03 — Early Termination on Credential Failure

  • Purpose: Ensure pipeline stops after credential failure.
  • Preconditions:
    • Expired InstanceCredential.
    • Other inputs valid.
  • Inputs:
    • TR as in ID‑01.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity passes, credential fails.
    • Evidence and policy not executed.
    • TResp: Status = Failure, Reason = "ExpiredInstanceCredential".

3.6.4 DL‑04 — Early Termination on Evidence Failure

  • Purpose: Ensure pipeline stops after evidence failure.
  • Preconditions:
    • Stale evidence.
    • Other inputs valid.
  • Inputs:
    • TR as in EV‑06.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity and credential pass, evidence fails.
    • Policy not executed.
    • TResp: Status = Failure, Reason = "StaleEvidence".

3.6.5 DL‑05 — Early Termination on Policy Failure

  • Purpose: Ensure pipeline stops after policy failure.
  • Preconditions:
    • Policy rule violation.
    • Other inputs valid.
  • Inputs:
    • TR as in PL‑04.
  • Execution:
    • PI‑A sends TR.
  • Expected Results:
    • Identity, credential, evidence pass; policy fails.
    • TResp: Status = Failure, Reason = "PolicyViolation:RequiredRole".

3.7. Data Exchange & DEM Enforcement Tests (DX‑xx)

3.7.1 DX‑01 — Data Sent Only on Success

  • Purpose: PI‑A must send data only when TResp = Success.
  • Preconditions:
    • Verifier returns Success for TR.
    • PI‑A implements OnTrustResponse logic.
  • Inputs:
    • TR as in DL‑01.
  • Execution:
    • Run full pipeline.
    • Observe PI‑A behavior.
  • Expected Results:
    • TResp: Status = Success.
    • PI‑A sends Data + DEM to PI‑B.
    • Logs show transfer occurred.

3.7.2 DX‑02 — No Data on Failure

  • Purpose: PI‑A must not send data when TResp = Failure.
  • Preconditions:
    • Any failing scenario (e.g., EV‑06).
    • PI‑A implements OnTrustResponse logic.
  • Inputs:
    • TR causing failure.
  • Execution:
    • Run pipeline.
    • Observe PI‑A.
  • Expected Results:
    • TResp: Status = Failure.
    • No data or DEM sent.
    • Logs show no transfer.

3.7.3 DX‑03 — DEM Retention Enforcement

  • Purpose: PI‑B enforces retention limit.
  • Preconditions:
    • DEM includes RetentionLimit = P7D.
    • TResp = Success.
    • PI‑B has storage and deletion logs.
  • Inputs:
    • Data + DEM from PI‑A.
  • Execution:
    • Deliver data to PI‑B.
    • Observe behavior over retention period.
  • Expected Results:
    • Data stored initially.
    • Data deleted at or before retention limit.
    • Logs show deletion event.

3.7.4 DX‑04 — DEM No‑Onward‑Sharing Enforcement

  • Purpose: PI‑B must not share data onward when forbidden.
  • Preconditions:
    • DEM sets NoOnwardSharing = true.
    • TResp = Success.
  • Inputs:
    • Data + DEM.
  • Execution:
    • Attempt to trigger onward sharing (e.g., via PI‑B API).
  • Expected Results:
    • Onward sharing blocked.
    • Logs show enforcement decision.

3.7.5 DX‑05 — DEM Security Enforcement

  • Purpose: PI‑B enforces confidentiality and integrity.
  • Preconditions:
    • DEM: Confidentiality = High, Integrity = Required.
    • TResp = Success.
  • Inputs:
    • Data + DEM.
  • Execution:
    • Deliver data to PI‑B.
    • Inspect configuration and logs.
  • Expected Results:
    • Data stored with high‑confidentiality controls (e.g., encryption, access control).
    • Integrity mechanisms applied (e.g., checksums, signatures).
    • Logs show enforcement.

3.8. Pass/Fail Criteria

An implementation is conformant if:

  • All mandatory tests above pass for the relevant conformance class (V, P, A).
  • All expected Status/Reason pairs match exactly.
  • No data is sent when TResp = Failure.
  • DEM is enforced when TResp = Success.
  • All signatures and timestamps are valid where required.

4 JSON Schema

https://schemas.mpai.community/PTF/V1.0/data/CTFConformanceTesting.json

<-Trust Establishment Protocol      Go to ToC    End‑to‑End Examples->