The ARF highlights interoperability as a design principle, and therefore protocol specifications are assigned to all relevant interfaces. But... If we want real interoperability it is not enough to write down that OID4VCI and OID4VP shall be supported. Instead, we have to exactly clarify how those standards should be supported (what to do with optional elements of the messages and alternative usages) and what the value list of parameters would be (nomenclature). (Such things have been made earlier - between 2016 and 2023 - for eIDAS 1.0 ecosystem: exact SAML message description and a minimum list of identified natural person and legal person attributes have been defined. see: https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eIDAS+eID+Profile) If eIDAS 2.0 technical specifications are not as precise as eIDAS 1.0 technical specifications, different - country-specific - solutions will be developed as (Q)EAA providers and therefore - built upon them - country-specific EUDI Wallet instances will be developed, as well.
And not just the interface of (Q)EAA and their authentic sources but also their stored attribute set shall not be country-specific. This means that (Q)EAA providers and their authentic sources shall have a common - minimum required - value set in order to apply the same logic when an EUDIWallet or an RP/SP evaluates the results. This common, EU-level attribute set was also defined by eIDAS 1.0 technical specifications and eIDAS 2.0 ARF also mentions some attributes ("provides a PID containing the correct family name and date of birth"). But beyond this attribute set, we also have a wider attribute set - for at least legal persons - because of EU-level company register, the Business Registers Interconnection System (BRIS). BTW, BRIS is still listed as one of the 13 sector-specific digital service infrastructures (DSI) of EU CEF (Connecting Europe Facility). Probably, beyond EU-level company register (BRIS) similar authentic source would be needed for self-employed persons, NGOs, chambers and other legal persons. As I see, at BRIS the common attribute set of the authorised representative natural person covers current family name, current given name, date of birth - with no unambiguous unique identifier - and also type/level of representation. These attributes are important inputs for evaulation logic which has to find correlation between legal person and natural person. In order to get attestation from legal person (Q)EAA provider a user authentication shall be performed and natural person attributes shall be retrieved in order to perform such correlation evaluation. As there is no statement for common user authentication methods it is hard to develop a general legal person EUDIWallet instance as well. This is one of the reasons why I have put a question earlier (see Issue 276: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/276) about using existing eIDAS 1.0 ecosystem and gain benefit of that: in that case eIDAS nodes provide a transparent interface for EUDIWallet instance developers and hide what country-specific user authentication methods are supported (based on national eID cards, other SW or HW tokens or even EUDIWallet embedded credentials) and how they are used.
So, it seems to me, that exact interface specifications and common nomenclature lists are still missing in order to go on with EUDIWallet development.
The ARF highlights interoperability as a design principle, and therefore protocol specifications are assigned to all relevant interfaces. But... If we want real interoperability it is not enough to write down that OID4VCI and OID4VP shall be supported. Instead, we have to exactly clarify how those standards should be supported (what to do with optional elements of the messages and alternative usages) and what the value list of parameters would be (nomenclature). (Such things have been made earlier - between 2016 and 2023 - for eIDAS 1.0 ecosystem: exact SAML message description and a minimum list of identified natural person and legal person attributes have been defined. see: https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eIDAS+eID+Profile) If eIDAS 2.0 technical specifications are not as precise as eIDAS 1.0 technical specifications, different - country-specific - solutions will be developed as (Q)EAA providers and therefore - built upon them - country-specific EUDI Wallet instances will be developed, as well.
And not just the interface of (Q)EAA and their authentic sources but also their stored attribute set shall not be country-specific. This means that (Q)EAA providers and their authentic sources shall have a common - minimum required - value set in order to apply the same logic when an EUDIWallet or an RP/SP evaluates the results. This common, EU-level attribute set was also defined by eIDAS 1.0 technical specifications and eIDAS 2.0 ARF also mentions some attributes ("provides a PID containing the correct family name and date of birth"). But beyond this attribute set, we also have a wider attribute set - for at least legal persons - because of EU-level company register, the Business Registers Interconnection System (BRIS). BTW, BRIS is still listed as one of the 13 sector-specific digital service infrastructures (DSI) of EU CEF (Connecting Europe Facility). Probably, beyond EU-level company register (BRIS) similar authentic source would be needed for self-employed persons, NGOs, chambers and other legal persons. As I see, at BRIS the common attribute set of the authorised representative natural person covers current family name, current given name, date of birth - with no unambiguous unique identifier - and also type/level of representation. These attributes are important inputs for evaulation logic which has to find correlation between legal person and natural person. In order to get attestation from legal person (Q)EAA provider a user authentication shall be performed and natural person attributes shall be retrieved in order to perform such correlation evaluation. As there is no statement for common user authentication methods it is hard to develop a general legal person EUDIWallet instance as well. This is one of the reasons why I have put a question earlier (see Issue 276: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/276) about using existing eIDAS 1.0 ecosystem and gain benefit of that: in that case eIDAS nodes provide a transparent interface for EUDIWallet instance developers and hide what country-specific user authentication methods are supported (based on national eID cards, other SW or HW tokens or even EUDIWallet embedded credentials) and how they are used.
So, it seems to me, that exact interface specifications and common nomenclature lists are still missing in order to go on with EUDIWallet development.