<-Conformance Go to ToC Examples ->
1 General
The MPAI-AIF Reference Software is an implementation of MPAI-AIF V3.0. It is not normative: it shows one implementation that conforms with the standard, and where the standard leaves a choice it states the choice made. It implements a User Agent, a Controller with the Controller API, Communication, Storage, AIM Metadata, Execution, Zero Trust over MPAI-PTF, the execution of AIMs apart from the Controller, and the MPAI Store with its Service and an App for Implementers. AIMs of several MPAI Standards run on it. The Reference Software of MPAI-MAS – the Thalia Service and its clients – is built on it.
The software is written in C# for .NET 10. The Controller and the Store Service run on Windows and Linux; the browser client runs in any current browser; the desktop clients and the Store App run on Windows.
2 How the parties are realised
Each party of the Reference Model is a program or a library with its own interface, so that a party can run on its own machine:
- the User Agent is a library with clients (desktop, browser). It acquires and presents data through its Physical Layer, interprets a Workflow, and reaches the Controller only through the Controller API, in the same process or over HTTP with a bearer token. It contains no AIM, and a test keeps it so;
- the Controller builds one Module from its AIM Instance Metadata, verifies it, places its AIMs where their Relation says, establishes the Channels and runs the Module by exchange or continuously;
- an AIM executes with the Controller, in its process, or apart from it, as its Relation states; what executes it apart is a program the Controller reaches over a link that it can open with the Trust Protocol;
- the MPAI Store is a service with a REST API over HTTPS, a core library, and an App with which an Implementer submits.
3 Components
Table 1 – Components of the Reference Software
| Component | What it contains |
| AIF/Controller | The Module loader, the life cycle (placement, start, pause, resume, stop at every depth), the executor for the exchange and continuous execution (one executor), status and degradation (ALIVE, DEGRADED, DEAD; OnDegraded and RestartLimit), the time base and the Trace, the record of the boundary, the AIM repository, the check of the AIM Licence, and the verification of Implementations and models. |
| AIF/ControllerApi | The Controller API, as the User Agent depends on it, with and without waiting. |
| AIF/Communication | Channels with the InProcess, Remote and External transports; Port behaviour (Depth, Overflow); payloads by reference within a Controller and inlined at its boundary; Storage: Private Storage of an AIM and of a Module, Shared Storage under rules, the record of the boundary. |
| AIF/Metadata | The reader and checker of AIM Metadata and AIM Instance Metadata: validation against the AIM Metadata Schema and the instance-of check against the AIM Metadata a Header names. |
| AIF/PortData | The codecs of the Data Types that cross a boundary or a link, checked against their schemas. |
| AIF/AimHost | The program that executes AIMs apart from the Controller: it takes them from its Controller, runs them, and proves which Implementation it runs. |
| AIF/Trust, AIF/RootOfTrust | MPAI-PTF: canonical form, signatures, identities, credentials, evidence, the Trust Protocol, the Verification Pipeline, the Trace; a simulated TPM 2.0 as the root of trust of a Controller and of an AIM that executes apart from it. |
| AIF/UserAgent | The Workflow reader and interpreter, the Physical Layer, the device registry, the Controller API client (local and remote), and the clients. |
| Store | The MPAI Store: the core (the catalogue of AIM Instance Metadata, the resolution of Topologies, fingerprints), the Service (REST API) and the App (the form of an Implementer). |
| AIMs, Apps, MAS | The AIMs of the Standards with their AIM Instance Metadata; the Applications, each a Module and a Workflow; the MAS API Service. |
| schemas, Test | The JSON Schemas of the Data Types and of the Metadata; the automated tests. |
4 What is implemented
Table 2 – Implementation of MPAI-AIF V3.0
| Chapter | Implemented |
| User Agent | Workflow interpretation; the Physical Layer on the desktop and in the browser, acquiring by Qualifier; the Controller API client, local and over HTTP; record and playback; sessions. |
| AI Modules | Basic and Composite AIMs to any depth; Ports by Data Type and Port Number; execution of Sub-AIMs apart from the Controller; reports and status. |
| Controller | One Controller, one Module; start, pause, resume and stop at every depth; OnDegraded and RestartLimit; trust authority over MPAI-PTF; the Controller keeps, after a Module stops, the Implementations it built. |
| Communication | Channels with the InProcess, Remote and External transports; Port behaviour; payloads by reference within a Controller, inlined at its boundary; one time base. |
| Storage | Private Storage of an AIM and of a Module, Shared Storage, rules with a central control, the record of the boundary. |
| Metadata | AIM Metadata and AIM Instance Metadata read, validated, and checked for the instance-of relation. |
| Execution | The exchange and continuous execution on one executor; Period, Deadline and MaxAge. |
| MPAI Store | Submission, versions, findings, fingerprints and verification of Implementations and models; the check of an Implementer ID; the authentication of the submitter; the AIM Licence, issued by the Store library. Section 5. |
| Zero Trust | Identities and credentials of AIM Instances; code and models verified before they run; trust between a Controller and an AIM that executes apart from it; attestation over a simulated root of trust; the Trace. |
5 The MPAI Store and the workflow
Table 3 follows the workflow of the MPAI Store page, Section 7, and says what the Reference Software does at each step.
Table 3 – The workflow in the Reference Software
| # | Step | In the Reference Software |
| 1 | The Implementer registers | The Store Service serves a page, /MPAI/Store/Register. It gives the Implementer an Implementer ID and a registration code, shown once. ID 1 is MPAI’s own. |
| 2 | The Implementer submits | The Store App (or any HTTPS client) posts the AIM Instance Metadata to POST /MPAI/Store/L3, with the Implementer ID in its Identifier and the Implementer’s signature in the header MPAI-Signature. |
| 3 | The Store approves | The Service refuses an Implementer ID it has not assigned or MPAI has not approved, and a submission that is unsigned, signed by another key or changed after it was signed. It validates the whole AIM Instance Metadata against the AIM Metadata Schema, resolves its Topology, looks for the Sub-AIMs, and checks it against the AIM Metadata its Header names. It looks for the package at the location stated, records the SHA-256 of the Implementation (for a package in its packages folder), and publishes the AIM Instance Metadata as a new version with its findings. It keeps every version and the record of who submitted it. |
| 4, 5 | The User Agent initialises the Controller and starts the Module | The Controller API, in the process or over HTTP. |
| 6 | The Controller loads the Metadata | The Controller reads the AIM Instance Metadata of the Module and of its Sub-AIMs from a folder it keeps; a client of the Store (GET /MPAI/Store/L3) fills it, and a copy kept is used when the Store cannot be reached. |
| 7 | The Controller obtains the Implementations | The Controller reads the AIMLicence offer, if the AIM Metadata has one, and obtains the AIM Licence from the Store (MPAI_AIFS_GetLicence, POST /MPAI/Store/Licence). It then obtains the Implementations from the location the AIM Instance Metadata states (a file or an https address) into its AIM repository, which it consults before it asks again. |
| 8 | The Controller verifies | The Controller measures what it obtained and sends the fingerprint to the Store (POST /MPAI/Store/L3/{id}/verify), which answers Same, Different or NotRecorded; it never gives the fingerprint out. What executes an AIM apart from the Controller measures and reports what it measured; the Controller asks the Store. The Controller refuses the Module with NOT_TRUSTED unless the answer is Same. |
| 9 | The Controller builds and runs the Module | It resolves the Topology into connections of AIM, Data Type and Port Number, places each AIM where its Relation says, admits it through the Trust interface, establishes the Channels and binds the handles. |
| 10, 11, 12 | Use, stop, destroy | The Controller API. |
What the Store App writes on the Implementer’s machine. In the folder of the App, %LOCALAPPDATA%\MPAI\StoreApp, the Implementer ID (implementer-id.txt) and the Implementer’s private key (implementer-<ID>.key), which never leaves the computer. The key is the Reference Software’s way of authenticating the submitter (WKF-2); another Store may authenticate in another way.
6 Not implemented
Not implemented are, among others: the PointToPoint and Bus transports; Grants per Channel end; a Deployment Controller; a Controller managing Controllers; a hardware root of trust; the measurement by the Store of packages outside its own packages folder; a signed answer of the Store to a verification.
7 Verification
The Reference Software is verified by automated tests, among them:
- every AIM Instance Metadata loaded, validated and checked against its AIM Metadata;
- Modules run by exchange and continuously, with loops, degradation and restarts;
- Sub-AIMs executing apart from the Controller, in another process, under the one Controller;
- Storage under rules, the record of a boundary and its playback;
- the Store Service on a local port: registration, approval, signed submission, refusal of what is unsigned, altered or from an unknown Implementer, recording and verification of fingerprints;
- the AIM Licence over HTTPS: issued by the Store Service under the Implementer’s offer at the price with the Store’s mark-up, the same one when it is asked again, its status and its revocation, and a Controller that builds from it;
- an Implementer, the Store and a Controller each on its own, the Controller obtaining over HTTP and verifying through the Store, and refusing an Implementation changed after it was approved;
- the Applications of MPAI-MAS run end to end, by several clients at once.
8 Access to the code
Please send an email to the MPAI Secretariat to access the code.
