MPAI-GME V2.1 Ecosystem

<-Documents    Go to ToC->

Introduction

Players

Operation

Data

1. Introduction

The MPAI Ecosystem is specified based on its three components:

1. Players having a role in the Ecosystem.
2. Operation of the Ecosystem
3. Data used in the Ecosystem.

2. Ecosystem Players

The MPAI Ecosystem composed of the following cooperating entities:

1. MPAI
   1. Acts as the root of trust of the MPAI Ecosystem.
   2. Defines the rules of Governance.
   3. Develops the 4 components of an MPAI Standard.
   4. Assigns the Ecosystem activities of the MPAI Store to a specific company.
   5. Appoints Performance Assessors.
2. MPAI Store
   1. Manages the Implementer ID Registration Authority (IIDRA).
   2. Establishes distribution agreements with Implementers.
   3. Tests implementations submitted by implementers for:
      1. Security Validation.
      2. Conformance with MPAI-AIF.
      3. Conformance with an Application-Oriented Technical Specification.
      4. Conformance with an Accessory Specification (if applicable).
   4. May receive and publish notifications from Performance Assessors.
   5. The MPAI Store may record results obtained through a publicly described methodology provided by external experts regarding Performance and post them alongside the metadata of an Implementation.
   6. Labels Implementations as:
      1. Level 1, if 3.1 and 3.2 tests have been passed.
      2. Level 2, if 3.3 tests have been passed.
      3. Level 3, if a Performance Assessor has notified that the Implementation has a Grade above the minimum level.
   7. Posts software Implementations for download.
   8. Manages a reputation system where the MPAI Store publishes reports of their user experience of an Implementation. Moderation is performed when necessary.
   9. The MPAI Store is a not-for-profit commercial organisation according to a mandate received from MPAI.
   10. However, the MPAI Store recovers the costs (e.g., ICT infrastructure, personnel, consultants) deriving from MPAI-related activities from Implementers, Service Providers and Users.

3. Implementers
   1. Obtain an Implementer ID (IID).
   2. Make implementations.
   3. Submit implementations to the MPAI Store.
   4. May submit Implementations to Performance Assessors.
4. Performance Assessors
   1. Are appointed for a particular domain and Performance category.
   2. Assess the Performance of an Implementation.
   3. May be implementers or qualified companies.
   4. May not Assess the Performance of their Implementations if Implementers.
   5. Appointments are permanent but MPAI may revoke the appointment.
   6. May charge Implementers, Service Providers, and Users for their services.
   7. Maintain confidentiality during Performance Assessment, unless Implementors and Assessors decide otherwise.

Table 1 gives the operations of the actors enabling the MPAI ecosystem to operate.

Table 1 – The players of the MPAI ecosystem

Player	Role
MPAI Store	1.     Is an independent commercial not-for-profit entity mandated by MPAI. 2.     Assigns ImplementerID’s to Implementers as ImplementerID Registration Authority. 3.     Charges Implementers, Service Providers and Users on a cost recovery basis. 4.     Receives Implementations from Implementers. 5.     Tests Implementations submitted by Implementers for security and Conformance. 6.     Receives results of Performance Assessment of Implementations from Performance Assessors. 7.     Distributes AIWs and AIMs suitable for execution in AIFs. They may be implementations of MPAI standards or independently developed. 8.     Assigns AIWs and AIMs to security experts for testing (either employees or consultants). 9.     Receives commercial distribution licences of AIFs, AIWs and AIMs Implementations from Implementers. 10.  Distributes to Service Providers and Users Implementations that are approved by security experts and Tested for Conformance after assigning: 1. A Level 1 label to non-MPAI-specified AIWs and AIMs. 2. A Level 2 label to AIWs and AIMs Conforming to an MPAI Application Standard. 3. Assign a Level 3 label to AIWs and AIMs Conforming to an MPAI Application Standard and whose Performance has been Assessed. 11.  Makes Implementations available through high availability ICT infrastructure.
Standard developer	An expert contributing to the development of MPAI Standards.
Implementer	An entity providing Implementations of AIFs, AIWs and AIMs.
Performance Assessor	An entity certified by MPAI to determine whether an AIW or AIM: 1.     Conforms with one or more MPAI standards. 2.     Offers a Performance Grade.
Security expert	An entity authorised by MPAI to develop tests establishing whether an AIF or an AIW or an AIM presents security issues.
Service Provider	An entity running AIWs e.g., a private or public cloud. A Service Provider does not acquire the right to redistribute Implementations.
End User	The ultimate beneficiary of the execution of AIWs. They may execute AIWs and AIMs in a local environment.

3. Ecosystem Operation

This is the sequence of operation that enable an Implementer to obtain an Implementer ID, submit an implementation to the MPAI Store, and an End User to select a Module and to have it executed by a Controller.

1 – Implementer requests registration and creation of an Implementer Account on MPAI Store and receives Implementer ID.

2  – Implementer submits an AIM bundle (AIM Metadata containing implementation package URLs, and fingerprints) to the MPAI Store for conformance validation and subsequent publication.

3 – The MPAI Store test the conformance of the code downloaded from the URL declared in the submitted AIM Metadata. If the test is successful, the AIM is approved for distribution.

4 – Remote Client consults the MPAI Store to Select an AIM for their needs.

5  – Remote Client application sends a Create Controller request to the MAS API Service.

6  – MAS API Service creates the new Controller Instance and notifies the Remote Client Application of its ID.

7  – Remote Client application issues a Start Module request to the MAS API Service for the AIM selected in point 4.

8  – MAS API Service forwards the Start Module request to the identified Service Controller Instance.

9  – The Service Controller Instance requests the list of matching AIMs from the MPAI Store.

10  – The Service Controller Instance retrieves the selected AIM Metadata from the MPAI Store.

11  – The Service Controller Instance creates deployment description template and management structures for the resources required for the AIM launch.

12  – The Service Controller Instance initiates provisioning and Life Cycle management of the resources required for the AIM through the Cloud Management Service.

13 – The Deployment Service provisions the resources for the AIM and accompanies installation, configuration and through to operation.

14  – The installation and configuration procedures of the provisioned resources retrieve the required Package(s) from Implementer’s repository.

15  – The Received Packages are checked for Validity, submitting the calculated fingerprint to the MPAI Store, prior to their ultimate activation.

At this point the Requested Module is running and ready to exchange messages.

16 – Remote Client application issues an Input Port Message request to the MAS API Service providing the Data Object for delivery to the indicated Port of the identified Module of the specified Controller.

17 – The MAS API Service resolves the Controller and corresponding Module and request delivery of the Data Object to the corresponding Input Port of the deployed Module.

18 – Remote Client application issues an Output Port Message request to the MAS API Service for retrieval of the Data Object from the indicated Port of the identified Module of the specified Controller.

19 – The MAS API Service resolves the Controller and corresponding Module and requests retrieval of the Data Object from the corresponding Output Port of the deployed Module.

20 – The MAS API Service returns the  received Output Data Object to the requesting Remote Client Application.

The exchange of messages may continue as required to satisfy the needs of the Remote Client Application.

21 – The Remote Client Application issues a Stop Module Request to the MAS API Server.

22 – MAS API Service forwards the Stop Module request to the identified Service Controller Instance.

23 – The Service Controller Instance requests termination of the resources provisioned for the AIM through the Cloud Management Service.

24 – The Remote Client Application issues a Terminate Controller Request to the MAS API Server.

25 – MAS API Service terminates the indicated Service Controller Instance.

Figure 1 depicts the operation of the MPAI ecosystem including Performance Assessment.

Legend	OK	Passed
	$	Transaction

Figure 1 – Operation of the MPAI Ecosystem

4. Ecosystem data

Table 2 gives the data types proper of the MPAI ecosystem:

Table 2 – The data types of the MPAI ecosystem

Data type	Definition
Conformance data	Data developed by MPAI to test the Conformance of an Implementation. It is defined and its version is controlled by MPAI and freely accessible from the MPAI Store.
Performance data	Data developed or specified by MPAI to assess the Performance of an Implementation. It is version-controlled by MPAI and may be accessible from a qualified third party (e.g., a Performance Assessor).
Implementations	Software implementing AIF, AIWs and AIMs submitted by Implementers and 1.     Verified for security issues by MPAI security experts. 2.     Tested for Conformance by the MPAI Store. 3.     Assessed for Performance upon request of the Implementer. Implementations available on the MPAI Store can be commercial or non-commercial.
Licence	A token describing the rights of a User to an Implementation.

<-Documents    Go to ToC->