<- Profiles Go to ToC Examples->

1       General

An AIF Implementation conforming to the Basic Profile shall operate under the assumption that the execution environment is Zero‑Trust, i.e., that no component, network, device, service, AIM, or communication path is inherently trustworthy. This reflects the explicit requirement that the AIF Basic Profile supports execution in local and distributed Zero‑Trust architectures.

Accordingly, each AIM and each AIF Component shall verify, for each interaction, the identity, authorization, integrity, freshness, and confidentiality of all data exchanges and component behaviours, consistent with the Zero‑Trust principles of “continuous verification” and “assume breach” models established in widely adopted Zero‑Trust frameworks [1, 2].

2       Identity Verification Requirements

  1. Each AIM participating in an AIM‑to‑AIM communication shall possess a verifiable identity.
  2. An AIM receiving data shall verify the identity of the AIM that generated the data before accepting it for processing.
  3. Identity verification shall not rely on network location, infrastructure placement, or any assumption of implicit trust.

3       Authentication Requirements

  1. Each AIM shall authenticate the identity of the AIM with which it communicates for every data exchange.
  2. Authentication shall occur on a per‑interaction basis and shall not rely on prior authenticated sessions or persistent trust.
  3. Authentication mechanisms shall be independent of the trustworthiness of the communication environment, consistent with the “never trust, always verify” principle [1, 2].

4       Authorisation Requirements

  1. An AIM shall verify that another AIM is authorized to perform each specific action, including the transmission or reception of Data Exchange Metadata or AIW data proper.
  2. Authorization decisions shall be enforced at the time of each request and shall not rely on any assumptions about the behaviour or location of the AIM of a previous session.
  3. No AIM shall access, transmit, or process data unless explicitly authorised to do so.

5       Integrity Requirements

  1. Any data transmitted between AIMs shall include verifiable means for the receiving AIM to determine whether the data has been modified during transit.
  2. A receiving AIM shall detect any alteration of Data Exchange Metadata or AIW data proper, accidental or malicious.
  3. Integrity verification shall be independent of the communication network’s correctness or security.

6       Confidentiality Requirements

  1. Data transmitted between AIMs shall be protected such that only the designated receiving AIM is capable of accessing the content.
  2. No AIM, component, or process other than the intended receiving AIM shall be capable of recovering or interpreting transmitted data.
  3. Confidentiality protection shall apply regardless of whether the AIF operates in local, remote, or distributed Zero‑Trust environments, as permitted by the Basic Profile.

7       Freshness and Replay‑Protection Requirements

  1. An AIM shall provide the receiving AIM with sufficient information to determine that received data is new and not a replay of previously transmitted data.
  2. A receiving AIM shall reject data that cannot be verified as fresh.
  3. Freshness assurance shall not rely on the trustworthiness of any portion of the communication environment.

8       Continuous Verification Requirements

  1. Each AIM shall continuously verify the security properties of AIM‑to‑AIM interaction, including identity, authorisation, integrity, confidentiality, and freshness.
  2. Verification shall occur at every interaction or at regular times in case interaction is based on streamed data, independent of previous verifications and without assumption of persistent trust.
  3. These requirements reflect Zero‑Trust mandates for continuous authentication and continuous risk evaluation as articulated in widely adopted Zero‑Trust frameworks [1, 2].

9       Environment and Infrastructure Independence

  1. An AIF Implementation shall not rely on the trustworthiness of the underlying operating system, hardware, communication paths, or deployment infrastructure.
  2. No assumption shall be made that co‑location, network topology, or infrastructure proximity indicate trustworthiness.
  3. All security properties shall be enforced in environments explicitly recognised as potentially compromised, consistent with Zero‑Trust models.

10   Auditability Requirements

  1. An AIF Implementation shall support the generation of auditable information allowing verification of AIM‑to‑AIM interactions, consistent with Zero‑Trust’s requirement for continuous monitoring and analysis. [3]
  2. Audit data shall be tamper‑evident.
  3. AIMs shall not rely on external infrastructure for the correctness or completeness of audit information.

11       Zero‑Trust Enforcement Functions

  1. Continuous Verification

This function ensures that every AIM-to-AIM interaction revalidates all security properties:

  • identity
  • authentication
  • authorization
  • integrity
  • confidentiality
  • freshness

This corresponds to clause 8, enforcing the Zero‑Trust principles of assume breach and never trust, always verify.
There is no caching of trust and no session persistence.

  1. Identity Verification & Authentication

This function ensures that:

  • the AIM generating data has a verifiable identity (clause 2.1)
  • the receiving AIM verifies that identity before accepting the data (clause 2.2)
  • every data exchange includes per‑interaction authentication (clause 3)

Identity verification confirms who the sender is. Authentication confirms that the sender is really that identity at this moment.

This is where technologies such as DID, X.509, mTLS, and signed authentication tokens are validated.

  1. Authorisation & Auditability

This function ensures:

  • the sending AIM is authorized for the specific action (clause 4.1)
  • the receiving AIM checks authorization at every request (clause 4.2)
  • audit records are produced and are tamper‑evident (clause 10)

Authorization guarantees what an AIM is allowed to do.
Auditability guarantees proof that it did it.

These two belong together because authorization without audit (or audit without authorization context) is meaningless in Zero Trust.

  1. Integrity & Freshness

This function enforces:

  • verifiable integrity for DEM and AIW data (clause 5)
  • guarantees that data is new, not replayed (clause 7)

Integrity ensures the data was not altered.
Freshness ensures the data is not a replay of old, previously valid messages.

These two functions are logically related because a message may be unmodified but still invalid (e.g., replayed).

  1. Confidentiality

This function enforces:

  • encryption for all data-in-transit (clause 6.1)
  • exclusive recoverability by the intended AIM (clause 6.2)

Confidentiality ensures that:

  • interception does not expose data
  • co‑located or adjacent AIMs cannot read data
  • infrastructure compromise does not expose payloads

This function aligns with the end-to-end confidentiality principle of Zero Trust.

  1. Environment and Infrastructure Independence

This function ensures:

  • no trust in underlying OS, VM, hardware, network, or deployment (clause 1.9)
  • no trust derived from colocation, topology, IP range, etc.
  • all security properties must be validated even in compromised environments

This corresponds directly to clause 9.

In Zero Trust:

“The environment provides zero implicit trust.”

Therefore:

  • even trusted hardware (TPM, TEE) must always prove its trustworthiness
  • even local communications must be authenticated and verified
  • even internal networks must be treated as untrusted

 

Threat analysis and modelling

<- Profiles Go to ToC Examples->