digeorgi
commented
3 days ago Thank you for your contribution. For PIDs, qualified EAAs, and PuB-EAAs, interoperability is required (see section 4.1.3) and therefore, the trust model will be implemented using X509 certificates and ‘classical‘ X509-based Certificate Authorities according to [RFC5280] and [RFC3647]. The same is true for non-qualified EAAs complying with ISO/IEC 18013-5. Another reason for preferring this trust model is that the Regulation requires in Article 5a 4 (a) that user must be able to present PIDs and attestations "where appropriate, in offline mode". Depending on implementation details, the architecture you describe may not be able to comply with that requirement.
However, for non-qualified EAAs complying with [SD-JWT VC] or [W3C VC DM v1.0 or 2.0], other trust frameworks may be used, such as Entity Statements and Entities specified in [OpenID Federation]. This will be added to ARF version 1.5.0.
Finally, regarding the number of Relying Parties: please note that an RP will not be placed on any Trusted List. Instead, they will receive an access certificate from a national CA, and those national CAs will be put on the Trusted List. We expect that the number of such CAs will not exceed 100. Regarding the number of issuers of education-related (Q)EAAs: this is to be seen. A priori it seems unlikely to us that every school or educational institution will implement all requirements for an (Q)EAA Provider themselves, as this is rather complex.
In relation to the trust infrastructure needed by QEAA/EAA providers and by Relying Parties, DC4EU is currently focusing on OID Federation and dPKI-based Trust Frameworks to showcase scalable* and feature-rich solutions that emphasize policies and permissions among all stakeholders of the LSP. The main objective of these solutions is to facilitate the onboarding and management of all parties in the ecosystem and to formalize the issuance of X.509 certificates within a trust management context. This is achieved by using more expressive metadata schemes and API-based mechanisms for discovering features and assertions. This is crucial for the governance of an ecosystem that is expected to continuously expand and transform, such as education. While the current ARF version mentions the OpenID Federation as an example, it heavily relies on the Public Key Infrastructure (PKI) concept, which may not be universally suitable. Therefore, it is recommended that the ARF also address interoperability between different types of trust frameworks and consider provisioning frameworks other than PKI.
*It has to be considered regarding the need for scalability, that in education use cases there may be hundreds or thousands of QEAA/EAA issuers. The same applies to RPs, as in individual MSs there could be thousands or tens of thousands of RPs that would need to be managed in the RP-registry.