<-Conformance Testing      Go to ToC

(Informative)

The End‑to‑End Examples illustrate how PTF components—data types, Verification Pipeline, policies, DEM—work together in realistic scenarios.
Each example walks through:

  • Who is involved (PIs, Verifier, Policy Authority, Data Producer/Consumer)
  • What they exchange (CII, credentials, evidence, TrustMessages, DEM)
  • How trust is established and data is governed

1 Trust Establishment and Data Exchange

This example illustrates a complete trust establishment flow between two Process Instances (PIs) using the PTF Trust Framework, followed by a governed data exchange using Data Exchange Metadata (DEM).
It demonstrates how PTF data types, the Verification Pipeline, policies, and Zero‑Trust principles work together.

1.1 Actors

  • PI‑A — Data Producer
  • PI‑B — Data Consumer
  • Verifier — Executes the Verification Pipeline
  • Policy Authority — Issues PolicyBinding and VerificationProfile

1.2 Preconditions

Before the interaction begins:

1.2.1 PI‑B possesses:

  • A valid Cryptographic Instance Identity (CII)
  • A valid InstanceCredential
  • A valid ProcessLifecycleCredential
  • Fresh AttestationEvidence (e.g., secure execution environment evidence)

1.2.2 Policy Authority has issued:

  • A PolicyBinding specifying conditions for receiving dataset X
  • A VerificationProfile defining required roles, evidence types, and trust anchors

1.2.3 PI‑A has data to send

  • Dataset X
  • A DEM template for dataset X

1.3 Message Flow

Step 1 — PI‑A → Verifier: TrustRequest

PI‑A sends a TrustRequest asking whether PI‑B is trusted to receive dataset X.

TrustRequest (conceptual structure):

{
  "MessageType": "TrustRequest",
  "RequesterID": "PI-A",
  "TargetID": "PI-B",
  "RequestedOperation": "ReceiveDatasetX",
  "Timestamp": "..."
}

1.4 Verification Pipeline Execution

The Verifier processes the TrustRequest using the mandatory pipeline steps.

1.4.1 Identity Verification

  • Verifies PI‑B’s CII signature using SAT
  • Checks that PI‑B’s declared roles match the Cryptographic Instance Role Taxonomy
  • Ensures PI‑B has the role required for receiving dataset X (e.g., AIF-CII-ROLE-DATA-CONSUMER)

Outcome: Success

1.4.2 Credential Verification

  • Verifies signatures on InstanceCredential and PLC
  • Checks validity intervals
  • Confirms issuer trust via TrustAnchor

Outcome: Success

1.4.3 Evidence Verification

  • Validates evidence type using SET
  • Verifies evidence hash and signature
  • Checks freshness (e.g., evidence must be < 5 minutes old)

Outcome: Success

1.4.4 Policy Evaluation

  • Loads PolicyBinding for dataset X
  • Loads VerificationProfile
  • Evaluates rules such as:
    • PI‑B must have role AIF-CII-ROLE-DATA-CONSUMER
    • PI‑B must run in a secure execution environment
    • Evidence freshness < 5 minutes

Outcome: Success

1.4.5 Decision Logic

All checks succeeded → trust is established.

1.4.6 TrustResponse

The Verifier returns:

{
  "MessageType": "TrustResponse",
  "Status": "Success",
  "Reason": null,
  "TargetID": "PI-B",
  "Timestamp": "...",
  "Signature": "..."
}

A TrustOperation entry is logged for each verification step.

1.5 PI‑A Receives TrustResponse

PI‑A now considers PI‑B trusted for the specific operation “ReceiveDatasetX”.

Zero‑Trust principle:
PI‑A trusts PI‑B only for this operation, only at this time, and only under the evaluated policy.

1.6 PI‑A → PI‑B: Data Exchange with DEM

PI‑A sends dataset X to PI‑B, accompanied by a DEM object.

DEM (conceptual structure):

{
  "DataID": "DatasetX",
  "Source": "PI-A",
  "AuthorisedConsumer": "PI-B",
  "Purpose": "Analytics",
  "Legality": {
    "NoOnwardSharing": true,
    "RetentionLimit": "30 days"
  },
  "Security": {
    "Confidentiality": "High",
    "Integrity": "Required"
  },
  "Provenance": {
    "CreatedBy": "PI-A",
    "Timestamp": "..."
  }
}

PI‑B must enforce all DEM constraints.

1.7 Outcome

  • Trust was established through the Verification Pipeline
  • PI‑B was validated using CII, credentials, evidence, and policies
  • PI‑A received a signed TrustResponse
  • Data was exchanged with DEM governing:
    • authorisation
    • legality
    • security
    • provenance

This example demonstrates a complete, compliant, Zero‑Trust‑aligned PTF workflow.

2 Trust Failure Due to Stale Evidence

This example illustrates a complete trust establishment attempt that fails because the target PI provides attestation evidence that is too old according to the VerificationProfile.
It demonstrates how the Verification Pipeline enforces freshness and how PTF prevents trust when evidence cannot be relied upon.

2.1 Actors

  • PI‑A — Data Producer
  • PI‑B — Intended Data Consumer
  • Verifier — Executes the Verification Pipeline
  • Policy Authority — Issues PolicyBinding and VerificationProfile

2.2 Preconditions

2.2.1 PI‑B possesses:

  • A valid CII
  • A valid InstanceCredential
  • A valid ProcessLifecycleCredential
  • AttestationEvidence, but older than the freshness requirement
    • Example: evidence timestamp = 20 minutes ago
    • VerificationProfile requires evidence < 5 minutes old

2.2.2 Policy Authority has issued:

  • A PolicyBinding for dataset X
  • A VerificationProfile requiring:
    • secure execution environment
    • evidence freshness < 5 minutes
    • role AIF-CII-ROLE-DATA-CONSUMER

2.2.3 PI‑A has data to send

  • Dataset X
  • DEM template for dataset X

2.3 Message Flow

Step 1 — PI‑A → Verifier: TrustRequest

PI‑A asks whether PI‑B can be trusted to receive dataset X.

{
  "MessageType": "TrustRequest",
  "RequesterID": "PI-A",
  "TargetID": "PI-B",
  "RequestedOperation": "ReceiveDatasetX",
  "Timestamp": "..."
}

2.4 Verification Pipeline Execution

The Verifier processes the TrustRequest.

2.4.1 Identity Verification

  • CII signature verified
  • Roles validated against Cryptographic Instance Role Taxonomy
  • PI‑B has the required role AIF-CII-ROLE-DATA-CONSUMER

Outcome: Success

2.4.2 Credential Verification

  • InstanceCredential signature valid
  • PLC signature valid
  • Validity intervals OK
  • Issuer trusted

Outcome: Success

2.4.3 Evidence Verification

This is where the failure occurs.

Verifier checks:

  • Evidence type is valid (SET) → OK
  • Evidence hash and signature valid → OK
  • Evidence timestamp → NOT OK

VerificationProfile requirement:

  • Evidence freshness < 5 minutes

PI‑B’s evidence:

  • Timestamp = 20 minutes ago

Result:

  • Evidence is stale
  • Evidence cannot be trusted
  • Zero‑Trust principle: stale evidence = no trust

Outcome: Failure

The Verifier logs:

TrustOperation: EvidenceVerificationFailed
Reason: Evidence freshness requirement not met

2.4.4 Policy Evaluation

Skipped because the pipeline stops at the first failure.2.

2.4.5 Decision Logic

Aggregates results:

  • Identity: OK
  • Credentials: OK
  • Evidence: FAILED
  • Policy: Not evaluated

Decision = Failure

2.4.6 TrustResponse

The Verifier returns a signed failure response:

{
  "MessageType": "TrustResponse",
  "Status": "Failure",
  "Reason": "StaleEvidence",
  "TargetID": "PI-B",
  "Timestamp": "...",
  "Signature": "..."
}

A TrustOperation entry is created for each completed step.

2.5 PI‑A Receives TrustResponse

PI‑A receives:

  • Status = Failure
  • Reason = StaleEvidence

Zero‑Trust principle:
PI‑A must not trust PI‑B for this operation.

2.6 No Data Exchange Occurs

Because trust was not established:

  • PI‑A does not send dataset X
  • No DEM is generated
  • No data leaves PI‑A
  • PI‑B receives nothing

This demonstrates that evidence freshness is a hard security boundary.

2.7 Outcome

  • Trust establishment fails due to stale evidence
  • PTF prevents data exchange
  • Zero‑Trust is enforced
  • All steps are logged via TrustOperations
  • PI‑B must refresh its attestation evidence before retrying

This example shows how PTF protects against replayed or outdated evidence and ensures that trust is always based on current, verifiable system state.

3 — Policy‑Driven Denial (Insufficient Role)

This example illustrates a trust establishment attempt that fails because the target PI does not satisfy the policy requirements for accessing a sensitive dataset.
Identity, credentials, and evidence are all valid — but policy evaluation denies trust.

3.1 Actors

  • PI‑A — Data Producer
  • PI‑B — Intended Data Consumer
  • Verifier — Executes the Verification Pipeline
  • Policy Authority — Issues PolicyBinding and VerificationProfile

3.2 Preconditions

3.2.1 PI‑B possesses:

  • A valid CII
  • A valid InstanceCredential
  • A valid ProcessLifecycleCredential
  • Fresh AttestationEvidence
  • Role: AIF-CII-ROLE-DATA-CONSUMER

3.2.2 Policy Authority has issued:

A PolicyBinding for dataset Y requiring:

  • Role: AIF-CII-ROLE-HIGH-SENSITIVITY
  • Secure execution environment
  • Evidence freshness < 5 minutes

3.2.3 PI‑A has data to send

  • Dataset Y (more sensitive than dataset X)
  • DEM template for dataset Y

3.3 Message Flow

Step 1 — PI‑A → Verifier: TrustRequest

PI‑A asks whether PI‑B can be trusted to receive dataset Y.

{
  "MessageType": "TrustRequest",
  "RequesterID": "PI-A",
  "TargetID": "PI-B",
  "RequestedOperation": "ReceiveDatasetY",
  "Timestamp": "..."
}

3.4 Verification Pipeline Execution

The Verifier processes the TrustRequest.

3.4.1 Identity Verification

  • CII signature valid
  • Roles validated
  • PI‑B has role: AIF-CII-ROLE-DATA-CONSUMER

Outcome: Success

3.4.2 Credential Verification

  • InstanceCredential signature valid
  • PLC signature valid
  • Validity intervals OK
  • Issuer trusted

Outcome: Success

3.4.3 Evidence Verification

  • Evidence type valid (SET)
  • Hash and signature valid
  • Freshness < 5 minutes

Outcome: Success

3.4.4 Policy Evaluation

This is where the failure occurs.

VerificationProfile requirement for dataset Y:

  • Required role: AIF-CII-ROLE-HIGH-SENSITIVITY

PI‑B’s actual role:

  • AIF-CII-ROLE-DATA-CONSUMER

PolicyBinding rule:

If dataset = Y:
    RequiredRole = AIF-CII-ROLE-HIGH-SENSITIVITY

Result:

  • PI‑B does not have the required role
  • Policy evaluation fails

The Verifier logs:

TrustOperation: PolicyEvaluationFailed
Reason: InsufficientRole

Outcome: Failure

3.4.5 Decision Logic

Aggregates results:

  • Identity: OK
  • Credentials: OK
  • Evidence: OK
  • Policy: FAILED

Decision = Failure

3.4.6 TrustResponse

The Verifier returns a signed failure response:

{
  "MessageType": "TrustResponse",
  "Status": "Failure",
  "Reason": "InsufficientRole",
  "TargetID": "PI-B",
  "Timestamp": "...",
  "Signature": "..."
}

TrustOperations record the failure.

3.5 PI‑A Receives TrustResponse

PI‑A receives:

  • Status = Failure
  • Reason = InsufficientRole

Zero‑Trust principle:
PI‑A must not trust PI‑B for this operation.

3.6 No Data Exchange Occurs

Because trust was not established:

  • PI‑A does not send dataset Y
  • No DEM is generated
  • No data leaves PI‑A
  • PI‑B receives nothing

This demonstrates that policy is the final arbiter of trust.

3.7 Outcome

  • Trust establishment fails due to insufficient role
  • PTF enforces policy requirements strictly
  • Identity, credentials, and evidence are not enough without policy compliance
  • Zero‑Trust is upheld
  • All steps are logged via TrustOperations

4 — Credential Chain Validation

This example illustrates a trust establishment flow where the target PI’s credentials are not issued directly by a TrustAnchor, but instead by an intermediate authority.
The Verifier must validate the entire credential chain up to a trusted root before trust can be established.

This demonstrates how PTF supports hierarchical trust infrastructures.

4.1 Actors

  • PI‑A — Data Producer
  • PI‑B — Intended Data Consumer
  • Verifier — Executes the Verification Pipeline
  • Intermediate Authority (IA) — Issues PI‑B’s InstanceCredential
  • TrustAnchor (TA) — Root authority trusted by the Verifier
  • Policy Authority — Issues PolicyBinding and VerificationProfile

4.2 Preconditions

4.2.1 PI‑B possesses:

  • A valid CII
  • An InstanceCredential issued by IA, not by the TrustAnchor
  • A ProcessLifecycleCredential issued by IA
  • Fresh AttestationEvidence

4.2.2 Intermediate Authority possesses:

  • A valid CredentialIssuerCredential issued by the TrustAnchor
  • This credential binds IA’s public key to its role as a credential issuer

4.2.3 TrustAnchor possesses:

  • A root key trusted by the Verifier
  • Issues credentials to IA

4.2.4 Policy Authority has issued:

  • A PolicyBinding for dataset Z
  • A VerificationProfile requiring:
    • secure execution environment
    • evidence freshness < 5 minutes
    • role AIF-CII-ROLE-DATA-CONSUMER

4.2.5 PI‑A has data to send

  • Dataset Z
  • DEM template for dataset Z

4.3 Message Flow

Step 1 — PI‑A → Verifier: TrustRequest

{
  "MessageType": "TrustRequest",
  "RequesterID": "PI-A",
  "TargetID": "PI-B",
  "RequestedOperation": "ReceiveDatasetZ",
  "Timestamp": "..."
}

4.4 Verification Pipeline Execution

The Verifier processes the TrustRequest.

4.4.1 Identity Verification

  • CII signature valid
  • Roles validated
  • PI‑B has required role AIF-CII-ROLE-DATA-CONSUMER

Outcome: Success

4.4.2 Credential Verification (with chain validation)

This is the key part of the example.

4.4.2.1 Step 1 — Validate PI‑B’s InstanceCredential

  • Signature valid
  • Validity interval OK
  • Issuer = Intermediate Authority (IA)

4.4.2.2 Step 2 — Validate IA’s CredentialIssuerCredential

  • IA’s credential is signed by TrustAnchor
  • Validity interval OK
  • IA is authorized to issue InstanceCredentials

4.4.2.3 Step 3 — Validate TrustAnchor

  • TrustAnchor is known and trusted by the Verifier
  • TrustAnchor key matches expected root key

4.4.2.4 Chain validation result

PI-B InstanceCredential
    ← signed by IA
IA CredentialIssuerCredential
    ← signed by TrustAnchor
TrustAnchor
    ← trusted root

Outcome: Success

4.4.3 Evidence Verification

  • Evidence type valid (SET)
  • Hash and signature valid
  • Freshness < 5 minutes

Outcome: Success

4.4.4 Policy Evaluation

  • PolicyBinding loaded
  • VerificationProfile loaded
  • All rules satisfied

Outcome: Success

4.4.5 Decision Logic

All checks succeeded → trust is established.

4.4.6 TrustResponse

{
  "MessageType": "TrustResponse",
  "Status": "Success",
  "Reason": null,
  "TargetID": "PI-B",
  "Timestamp": "...",
  "Signature": "..."
}

TrustOperations log each step, including chain validation.

4.5 PI‑A Receives TrustResponse

PI‑A now trusts PI‑B for the specific operation “ReceiveDatasetZ”.

4.6 PI‑A → PI‑B: Data Exchange with DEM

PI‑A sends dataset Z with DEM:

{
  "DataID": "DatasetZ",
  "Source": "PI-A",
  "AuthorisedConsumer": "PI-B",
  "Purpose": "ModelTraining",
  "Legality": {
    "NoOnwardSharing": true,
    "RetentionLimit": "7 days"
  },
  "Security": {
    "Confidentiality": "High",
    "Integrity": "Required"
  },
  "Provenance": {
    "CreatedBy": "PI-A",
    "Timestamp": "..."
  }
}

4.7 Outcome

  • Trust established through full credential chain validation
  • PI‑B’s credentials validated through IA → TrustAnchor
  • Evidence validated and fresh
  • Policy requirements satisfied
  • Data exchanged with DEM governing usage
  • All steps logged via TrustOperations

This example demonstrates how PTF supports hierarchical trust infrastructures, intermediate authorities, and root‑of‑trust validation.

<-Conformance Testing      Go to ToC