https://wiki.de4a.eu/api.php?action=feedcontributions&feedformat=atom&user=Ictu+harold.metselaar 2026-04-05T17:10:47Z User contributions MediaWiki 1.35.1 https://wiki.de4a.eu/index.php?title=Second_phase&diff=5869 2023-02-03T09:48:14Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots ([[Doing Business Abroad Pilot|Doing Business Abroad - DBA]], [[Moving Abroad Pilot|Moving Abroad - MA]], and [[Studying Abroad Pilot|Studying Abroad - SA]])<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the [[Use Case &quot;Diploma/Certs/Studies/Professional Recognition&quot; (SA UC3)|SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;)]] service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 7. Partners’ experience with non-functional requirements<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11 &lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]<br /> [[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb|Figure 14. a) Confidentiality]]<br /> [[File:Confidentiality.png|none|thumb|Figure 14. b) Integrity]]<br /> [[File:Availability.png|none|thumb|Figure 14. c) Availability]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb|Figure 15. a). Extent of employing security mechanisms to counter specific cyber-threats]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb|Figure 15. b) Frequency of BBs introducing new vulnerabilities]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb|Figure 16. EAAF Maturity levels]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5868 2023-02-02T14:07:26Z

<p>Ictu harold.metselaar: /* Patterns */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots ([[Doing Business Abroad Pilot|Doing Business Abroad - DBA]], [[Moving Abroad Pilot|Moving Abroad - MA]], and [[Studying Abroad Pilot|Studying Abroad - SA]])<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the [[Use Case &quot;Diploma/Certs/Studies/Professional Recognition&quot; (SA UC3)|SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;)]] service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 7. Partners’ experience with non-functional requirements<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11 &lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]<br /> [[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb|Figure 14. a) Confidentiality]]<br /> [[File:Confidentiality.png|none|thumb|Figure 14. b) Integrity]]<br /> [[File:Availability.png|none|thumb|Figure 14. c) Availability]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb|Figure 15. a). Extent of employing security mechanisms to counter specific cyber-threats]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb|Figure 15. b) Frequency of BBs introducing new vulnerabilities]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb|Figure 16. EAAF Maturity levels]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5867 2023-02-02T14:06:53Z

<p>Ictu harold.metselaar: /* Patterns */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots ([[Doing Business Abroad Pilot|Doing Business Abroad - DBA]], [[Moving Abroad Pilot|Moving Abroad - MA]], and [[Studying Abroad Pilot|Studying Abroad - SA]])<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the [[Use Case &quot;Diploma/Certs/Studies/Professional Recognition&quot; (SA UC3)|SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;)]] service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 7. Partners’ experience with non-functional requirements<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11 &lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]<br /> [[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb|Figure 14. a) Confidentiality]]<br /> [[File:Confidentiality.png|none|thumb|Figure 14. b) Integrity]]<br /> [[File:Availability.png|none|thumb|Figure 14. c) Availability]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb|Figure 15. a). Extent of employing security mechanisms to counter specific cyber-threats]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb|Figure 15. b) Frequency of BBs introducing new vulnerabilities]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb|Figure 16. EAAF Maturity levels]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5866 2023-02-02T14:04:44Z

<p>Ictu harold.metselaar: /* Methodology */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots ([[Doing Business Abroad Pilot|Doing Business Abroad - DBA]], [[Moving Abroad Pilot|Moving Abroad - MA]], and [[Studying Abroad Pilot|Studying Abroad - SA]])<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the [[Use Case &quot;Diploma/Certs/Studies/Professional Recognition&quot; (SA UC3)|SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;)]] service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 7. Partners’ experience with non-functional requirements<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]<br /> [[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb|Figure 14. a) Confidentiality]]<br /> [[File:Confidentiality.png|none|thumb|Figure 14. b) Integrity]]<br /> [[File:Availability.png|none|thumb|Figure 14. c) Availability]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb|Figure 15. a). Extent of employing security mechanisms to counter specific cyber-threats]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb|Figure 15. b) Frequency of BBs introducing new vulnerabilities]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb|Figure 16. EAAF Maturity levels]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5865 2023-02-02T13:56:44Z

<p>Ictu harold.metselaar: /* Trust, Identity, Security, Privacy, Protection */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 7. Partners’ experience with non-functional requirements<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]<br /> [[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb|Figure 14. a) Confidentiality]]<br /> [[File:Confidentiality.png|none|thumb|Figure 14. b) Integrity]]<br /> [[File:Availability.png|none|thumb|Figure 14. c) Availability]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb|Figure 15. a). Extent of employing security mechanisms to counter specific cyber-threats]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb|Figure 15. b) Frequency of BBs introducing new vulnerabilities]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb|Figure 16. EAAF Maturity levels]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5864 2023-02-02T12:43:32Z

<p>Ictu harold.metselaar: /* Meeting pilot requirements */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 7. Partners’ experience with non-functional requirements<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]<br /> [[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb]]<br /> [[File:Confidentiality.png|none|thumb]]<br /> [[File:Availability.png|none|thumb]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5863 2023-02-02T12:38:26Z

<p>Ictu harold.metselaar: /* Meeting pilot requirements */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2.Distribution of received valid feedback per partner type<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 5. Inventory of piloting requirements related to each building block<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> {| class=&quot;wikitable&quot;<br /> |+Table 6. Barriers to BB implementation<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> Table 7. Partners’ experience with non-functional requirements<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb]]<br /> [[File:No. of issues due to the BB use.png|none|thumb]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb]]<br /> [[File:Confidentiality.png|none|thumb]]<br /> [[File:Availability.png|none|thumb]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5862 2023-02-02T12:35:49Z

<p>Ictu harold.metselaar: /* Methodology */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |+Table 4. Recommendations for use and implementation of the BBs<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> Table 7. Partners’ experience with non-functional requirements<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb]]<br /> [[File:No. of issues due to the BB use.png|none|thumb]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb]]<br /> [[File:Confidentiality.png|none|thumb]]<br /> [[File:Availability.png|none|thumb]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5861 2023-02-02T12:33:29Z

<p>Ictu harold.metselaar: /* Methodology */</p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]<br /> [[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]<br /> <br /> Of the new requirements[1], the following were noted:<br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]<br /> [[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]<br /> [[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]<br /> [[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |+Table 3. BB usability traits in the context of DE4A<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> Table 7. Partners’ experience with non-functional requirements<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb]]<br /> [[File:No. of issues due to the BB use.png|none|thumb]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb]]<br /> [[File:Confidentiality.png|none|thumb]]<br /> [[File:Availability.png|none|thumb]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5860 2023-01-31T17:50:30Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb]]<br /> [[File:Potential for contribution of each BB.png|none|thumb]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb]]<br /> <br /> <br /> Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb]]<br /> [[File:Administrative.png|none|thumb]]<br /> [[File:Operational.png|none|thumb]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> Table 7. Partners’ experience with non-functional requirements<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb]]<br /> [[File:No. of issues due to the BB use.png|none|thumb]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb]]<br /> [[File:Confidentiality.png|none|thumb]]<br /> [[File:Availability.png|none|thumb]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).<br /> [[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb]]<br /> [[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb]]<br /> Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.<br /> <br /> = Discussion and comparative analysis =<br /> In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:<br /> <br /> # Standards and Specifications;<br /> # Common code or Components;<br /> # Building Blocks;<br /> # Core Service Platforms;<br /> # Generic Services.<br /> <br /> Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment. <br /> <br /> While the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.<br /> <br /> In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''<br /> [[File:EAAF Maturity levels.png|none|thumb]]<br /> <br /> = Conclusion =<br /> In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.<br /> <br /> During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis. <br /> <br /> On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Frequency_of_BBs_introducing_new_vulnerabilities.png&diff=5859 2023-01-31T17:47:09Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Frequency of BBs introducing new vulnerabilities</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Extent_of_employing_security_mechanisms_to_counter_specific_cyber-threats.png&diff=5858 2023-01-31T17:46:26Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Extent of employing security mechanisms to counter specific cyber-threats</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5857 2023-01-30T15:51:08Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb]]<br /> [[File:Potential for contribution of each BB.png|none|thumb]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb]]<br /> <br /> <br /> Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb]]<br /> [[File:Administrative.png|none|thumb]]<br /> [[File:Operational.png|none|thumb]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> Table 7. Partners’ experience with non-functional requirements<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb]]<br /> <br /> === Trust, Identity, Security, Privacy, Protection ===<br /> There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.<br /> [[File:Security and privacy issues encountered.png|none|thumb]]<br /> [[File:No. of issues due to the BB use.png|none|thumb]]<br /> <br /> <br /> Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting. <br /> <br /> The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.<br /> <br /> In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).<br /> [[File:BB features used to address .png|none|thumb]]<br /> [[File:Confidentiality.png|none|thumb]]<br /> [[File:Availability.png|none|thumb]]<br /> <br /> <br /> More concretely, information confidentiality mechanisms used within the pilots were: eIDAS standard mechanisms, encryption and verification, passwords and security tokens.<br /> <br /> Information integrity mechanisms used within the pilots were: hashing, access control and digital signatures.<br /> <br /> Finally, information availability mechanisms used within the pilots were: cloud server deployment, redundancy, firewalls, and DDoS attacks' prevention.<br /> <br /> In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Availability.png&diff=5856 2023-01-30T15:50:08Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Availability</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Confidentiality.png&diff=5855 2023-01-30T15:49:27Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Confidentiality</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:BB_features_used_to_address_.png&diff=5854 2023-01-30T15:48:22Z

<p>Ictu harold.metselaar: </p> <hr /> <div>BB features used to address</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:No._of_issues_due_to_the_BB_use.png&diff=5853 2023-01-30T15:47:10Z

<p>Ictu harold.metselaar: </p> <hr /> <div>no. of issues due to the BB use</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Security_and_privacy_issues_encountered.png&diff=5852 2023-01-30T15:46:12Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Security and privacy issues encountered</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5851 2023-01-30T15:44:37Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb]]<br /> [[File:Potential for contribution of each BB.png|none|thumb]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb]]<br /> <br /> <br /> Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb]]<br /> [[File:Administrative.png|none|thumb]]<br /> [[File:Operational.png|none|thumb]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.<br /> [[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]<br /> Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.<br /> <br /> Table 7. Partners’ experience with non-functional requirements<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of NFR issue'''<br /> |'''Encountered''' <br /> |'''Foreseen'''<br /> |-<br /> |'''Performance'''<br /> |Response times and uptime for some components;<br /> <br /> <br /> Frequent issues with &quot;external service outage&quot; that would lower availability of services largely.<br /> |Connectors and SMP/SML can become single points of problems if having performance issues in the future when many DEs and DOs join;<br /> <br /> <br /> Hard to say as the number of users may be much higher in production;<br /> <br /> <br /> Possible - the BB should be stress-tested by EU/MS before recommendation.<br /> |-<br /> |'''Availability''' <br /> |Yes, due to software and configuration issues;<br /> <br /> <br /> Several components were not available (regularly);<br /> <br /> <br /> Yes, frequently, IP-changes led to connectivity issues;<br /> <br /> <br /> Yes, some services were unstable, but during piloting the situation improved.<br /> |Yes, including external services<br /> |-<br /> |'''Scalability''' <br /> |Yes. Components not designed for high-availability deployments, nor for flexible escalation.<br /> |Depending on use of components, support and development may depend on a one-man company.<br /> |}<br /> <br /> === Patterns ===<br /> Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot. <br /> As Figure 11&lt;span lang=&quot;EN&quot;&gt;In terms of overall performance of each building block in<br /> the context of DE4A, &lt;/span&gt; shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.<br /> ----This is apprently the deregistration thing?<br /> <br /> S&amp;N and LKP are used in DBA but should also be applicable to non-business context<br /> <br /> [[File:Overall use of DE4A patterns.png|none|thumb]]<br /> <br /> <br /> The use of each of these patterns per building block is shown in Figure 12. <br /> [[File:Use of each pattern by each building block.png|none|thumb]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Use_of_each_pattern_by_each_building_block.png&diff=5850 2023-01-30T15:44:13Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Use of each pattern by each building block</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Overall_use_of_DE4A_patterns.png&diff=5849 2023-01-30T15:43:21Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Overall use of DE4A patterns</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Overall_performance_of_each_building_block_in_the_context_of_DE4A.png&diff=5848 2023-01-30T15:41:20Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Overall performance of each building block in the context of DE4A</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5847 2023-01-27T14:46:28Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> * Member States (MSs)<br /> * WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> * WP5 partners - for specific components<br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb]]<br /> [[File:Potential for contribution of each BB.png|none|thumb]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb]]<br /> <br /> <br /> Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb]]<br /> [[File:Administrative.png|none|thumb]]<br /> [[File:Operational.png|none|thumb]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5846 2023-01-27T14:45:58Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Under construction! ==<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb]]<br /> [[File:Potential for contribution of each BB.png|none|thumb]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb]]<br /> <br /> <br /> Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb]]<br /> [[File:Administrative.png|none|thumb]]<br /> [[File:Operational.png|none|thumb]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.<br /> <br /> Table 3. BB usability traits in the context of DE4A<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Ease of deployment'''<br /> |'''Ease of configuration'''<br /> |'''Ease of integration with other BBs/existing SW'''<br /> |'''Barriers for implementation'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |It is embedded into the Connector;<br /> <br /> Easy<br /> |3/5;<br /> <br /> Tricky (certificates)<br /> |3/5;<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |No<br /> <br /> Easy<br /> |Certificates;<br /> <br /> Support by one-man company<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |No<br /> <br /> Easy<br /> |No;<br /> <br /> Difficult<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Yes<br /> |4/5;<br /> <br /> Yes<br /> |4/5, yes, Transparent to data evaluators<br /> |No<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Fairly easy<br /> |yes<br /> |CompanyEvidence was easy to use with integration with BusReg;<br /> <br /> Fairly easy integration with data evaluator<br /> |No<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |5/5<br /> |3/5<br /> |2/5<br /> |No<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |5/5<br /> |2/5<br /> |2/5<br /> |Yes. Business cards from TOOP were reused, whose data model did not completely meet DE4A needs for the IAL functionality. However, a working solution was provided<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Yes<br /> |Yes<br /> |Yes<br /> |No<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Yes<br /> |yes<br /> |Yes<br /> |No<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |Normal<br /> |Normal<br /> |Normal<br /> |No<br /> |}<br /> As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.<br /> <br /> Table 4. Recommendations for use and implementation of the BBs<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Practical recommendation for use'''<br /> |'''Used in:'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |To make certificate management easier<br /> |Used by multiple Interaction Patterns (IM, USI, S&amp;N, L, DReg?);<br /> <br /> Can be considered common infrastructure<br /> |-<br /> |'''  2'''<br /> |'''SMP/SML'''<br /> |To make certificate management easier<br /> |Part of eDelivery (idem)<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |The concept of a Connector with an integrated AS4 gateway allowed for easier integration of DEs and DOs in the USI pattern. Decoupling the exchange and business layers allows for abstraction and adds flexibility to the exchange model. The DE4A Connector reference implementation helped MS to integrate their data evaluators and data owners and enable connectivity between the states more easily; <br /> <br /> Make certificate management easier.<br /> |Used for easier integration of data evaluators and data owners<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |The DE4A playground with mock DE, mock DO test connectors and shared test SMP proved successful for validating national connectors and SMP installations and easier DE and DO integration.<br /> |Used for easier integration of DEs and DOs<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |N/A<br /> |To fully understand the XSDs; Transparent to pilots<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |Assess fit for use in SDG OOTS;<br /> <br /> Extend with additional attributes/data; <br /> <br /> It was difficult to find a common denominator of higher education evidence from the three MS for applications to higher education and applications for study grants (some data required by one MS might not be obtainable from another MS). This will become even more difficult when doing the same among all MS. Many MS also have difficulties to provide the evidence required for certain procedures, e.g. non-academic evidence for the applications for study grants that can contain privacy sensitive data. The pilot suggested to the DE4A Semantic Interoperability Solutions (WP3) the Europass data model as the basis for the higher education diploma scheme in order to be able to use the same schema for both USI and VC pattern (and thus between SDG OOTS and revised eIDAS regulation).<br /> |Used for canonical evidence exchange<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Documented in the proper guidelines[1] <br /> |Extension of SMP/SML, i.e. business cards<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Documented in the proper guidelines<br /> |Conceptually part of IDK, central component providing routing information<br /> |}<br /> <br /> === Meeting pilot requirements ===<br /> After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.<br /> <br /> Table 5. Inventory of piloting requirements related to each building block<br /> {| class=&quot;wikitable&quot;<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''Piloting requirements that were met'''<br /> |'''Requirements that were not met'''<br /> |-<br /> | '''1'''<br /> |'''eDelivery (data exchange)'''<br /> |Message exchange; <br /> <br /> All<br /> |None<br /> |-<br /> | '''2'''<br /> |'''SMP/SML'''<br /> |All<br /> |None<br /> |-<br /> | '''3'''<br /> |'''DE4A Connector'''<br /> |Met (4.75 on a 1-5 scale; see D4.3); All<br /> |None<br /> |-<br /> | '''4'''<br /> |'''DE4A Playground'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''5'''<br /> |'''Information Exchange Model'''<br /> |Include the information to request and send evidence, even multiple evidence; <br /> <br /> All; <br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''6'''<br /> |'''Canonical Data Models'''<br /> |All;<br /> <br /> Met (4.5 on a 1-5 scale; see D4.3)<br /> |None; <br /> <br /> Missing element was added to the diploma scheme for the final phase<br /> |-<br /> | '''7'''<br /> |'''ESL (implemented as part of SMP/SML)'''<br /> |Identify the DO’s evidence service<br /> |None<br /> |-<br /> | '''8'''<br /> |'''IAL'''<br /> |Identify the evidence DO provider<br /> |The data model of the IAL does not support all the information on Administrative Territorial Units designed by WP3<br /> |-<br /> | '''9'''<br /> |'''MOR'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''10'''<br /> |'''SEMPER'''<br /> |N/A<br /> |N/A<br /> |-<br /> | '''11'''<br /> |'''SSI Authority agent'''<br /> |Met (4 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''12'''<br /> |'''SSI User agent (mobile)'''<br /> |Met (4.5 on a 1-5 scale; see D4.3)<br /> |None<br /> |-<br /> | '''13'''<br /> |'''EBSI-ESSIF (CEF Blockchain)'''<br /> |N/A<br /> |N/A<br /> |}<br /> As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered. <br /> <br /> Table 6. Barriers to BB implementation<br /> {| class=&quot;wikitable&quot;<br /> |'''Type of barrier'''<br /> |'''Description of barrier'''<br /> |-<br /> |'''Legal'''<br /> |All MSs need to accept DLT; <br /> <br /> How to authorize a DE to request a canonical evidence type about a specific subject.<br /> |-<br /> |'''Organizational'''<br /> |Hire/Engage internal staff; <br /> <br /> The collection of signed information from partners to create the first PKI with Telesec, which took a lot of time and was very burdensome; <br /> <br /> Manual trust management, horizontal trust model<br /> |-<br /> |'''Technical'''<br /> |Invest in EBSI infrastructure;<br /> <br /> Allow federated until 2027; <br /> <br /> The need of knowing different external technologies and protocols in a very short time, such as eDelivery; maintainability<br /> |-<br /> |'''Semantic''' <br /> |Terms get antiquated need synonym hoover text; No major issues; <br /> <br /> Lack of canonical models at semantic level, lack of official pairings from local models to canonical models so translation can be done for each pair of MS<br /> |-<br /> |'''Business''' <br /> |Allow for private service providers to improve Usability UI; <br /> <br /> No major issues related to BBs.<br /> |-<br /> |'''Political''' <br /> |AI and ML in reuse of the Data; <br /> <br /> The obligation of using RegRep.; <br /> <br /> Following global standards<br /> |-<br /> |'''Human factor'''<br /> |Too little resources to SW dev; <br /> <br /> The availability of the personnel assigned to DE4A, which more often than not has not been the expected one. <br /> <br /> Additionally, the withdrawal of some partners (such as eGovlab); usability.<br /> |}<br /> Figure 8 further details the level of criticality of the listed barrier in the context of DE4A. <br /> [[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]<br /> All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.<br /> <br /> === Performance and Non-Functional Requirements ===<br /> The same systematization of the types of barriers investigated above is also ascribed to the various aspects (dimensions) of the building blocks through which we can analyze the BBs performance at a more granular level. <br /> <br /> In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.<br /> [[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Importance_of_each_BB_aspect_(dimension)_for_DE4A.png&diff=5845 2023-01-27T14:45:01Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Importance of each BB aspect (dimension) for DE4A</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Level_of_criticality_of_the_barriers_from_Table_6_for_DE4A.png&diff=5844 2023-01-27T14:44:15Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Level of criticality of the barriers from Table 6 for DE4A</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5843 2023-01-27T14:42:03Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Under construction!<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> <br /> [[File:Contribution of each BB.png|thumb|alt=|none]]<br /> [[File:Contribution per interoperability dimension..png|none|thumb]]<br /> [[File:Potential for contribution of each BB.png|none|thumb]]<br /> [[File:Potential for contribution per interoperability dimension.png|none|thumb]]<br /> <br /> <br /> Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.<br /> <br /> === BB Maturity ===<br /> In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:<br /> <br /> 1.   Technical<br /> <br /> 2.   Administrative<br /> <br /> 3.   Operational<br /> <br /> The aim of this initial feedback was to provide the grounds for a comparative analysis over the same dimensions, after the current (second) phase of the BB assessment (i.e. check if anything changed meanwhile). <br /> <br /> The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.<br /> [[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]<br /> However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.<br /> <br /> As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects. <br /> [[File:Technical.png|none|thumb]]<br /> [[File:Administrative.png|none|thumb]]<br /> [[File:Operational.png|none|thumb]]<br /> <br /> <br /> Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.<br /> [[File:General state of maturity of each BBs.png|none|thumb]]<br /> <br /> === BB Openness ===<br /> In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.<br /> [[File:Properties enabling building block openness.png|none|thumb]]<br /> It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .<br /> <br /> Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Properties_enabling_building_block_openness.png&diff=5842 2023-01-27T14:40:24Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Properties enabling building block openness</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:General_state_of_maturity_of_each_BBs.png&diff=5841 2023-01-27T14:39:24Z

<p>Ictu harold.metselaar: </p> <hr /> <div>General state of maturity of each BBs</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Operational.png&diff=5840 2023-01-27T14:37:08Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Operational</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Administrative.png&diff=5839 2023-01-27T14:36:32Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Administrative</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Technical.png&diff=5838 2023-01-27T14:36:01Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Technical</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Grading_semantics_of_the_evaluation_scores_used_in_the_first_and_the_second_phase.png&diff=5837 2023-01-27T14:32:58Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Grading semantics of the evaluation scores used in the first and the second phase</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Potential_for_contribution_per_interoperability_dimension.png&diff=5836 2023-01-27T14:31:18Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Potential for contribution per interoperability dimension</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Potential_for_contribution_of_each_BB.png&diff=5835 2023-01-27T14:30:03Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Potential for contribution of each BB to interoperability</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Contribution_per_interoperability_dimension..png&diff=5834 2023-01-27T14:28:39Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Contribution per interoperability dimension.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5833 2023-01-27T14:26:50Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Under construction!<br /> <br /> == Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.<br /> [[File:Contribution of each BB.png|left|thumb]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:Contribution_of_each_BB.png&diff=5832 2023-01-27T14:26:27Z

<p>Ictu harold.metselaar: </p> <hr /> <div>Contribution of each BB</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5831 2023-01-27T14:24:18Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.<br /> In addition to the new functionalities, we also inquired about the redundant ones, those that were already defined, but found unusable in the context of DE4A. Thus, in 4 of the (10) cases there were redundant functionalities found for the implementation of the pilot.<br /> <br /> Despite the existing BBs that were on the list for evaluation, 4 of the partners also pointed out the following additional BBs or components that were employed in the pilots: <br /> <br /> * Logs and error messages (in the MA-pilot);<br /> * IAL / IDK (used by the Member States); and <br /> * eIDAS (used by the SA pilot and the MSs).<br /> <br /> With their use, the following additional functionalities were provided:<br /> <br /> * Cross-border identification of students;<br /> * Clarity and understanding; and<br /> * Authentication and lookup routing information.<br /> <br /> For the additional BBs, one new functionality was also defined during piloting: Common Errors.<br /> <br /> Finally, the survey also inquired on the possibility of completely new BBs being defined during the lifespan of the project. According to the partners’ feedback, in 4 of the 10 cases such BBs were also defined, all of which were also regarded as '''reusable''' by other projects and in other cases as well, such as:<br /> <br /> * For any SSI or verifiable credential like pattern;<br /> * MOR semantics in EBSI and SDGR; and<br /> * By IAL: for lookup routing information.<br /> <br /> === BB Interoperability ===<br /> EIF/EIRA defines 4 dimensions with respect to interoperability: Legal, Organizational, Semantic and Technical. Thus, in addition to analyzing the contribution of each BB to interoperability (as defined by EIF/EIRA), we also delved into more granular inquiry on how each of the interoperability dimensions was addressed in the DE4A project (with the implementation of the given set of BBs). This was done both for the cases of the current implementation of the BBs, as well as in view of the potential of each BB to contribute to (the dimensions of) interoperability in contexts other than DE4A. <br /> <br /> Figure 2a) shows the contribution of each BB to interoperability in the context of DE4A, while Figure 2b) granulizes this contribution per each interoperability dimension.<br /> <br /> Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5830 2023-01-27T14:21:22Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.<br /> <br /> === Inventory of BBs and functionalities ===<br /> In this part of the survey, we inquired on the new functionalities and requirements defined for the BBs during the project life-time.<br /> <br /> In 9 of the 10 cases, there were new functionalities defined for one or more of the implemented BBs, and in 7 of the 10 cases, new requirements as well. This is shown in Figure 1a) and b), respectively.<br /> <br /> Of the functionalities, most noticeable were:<br /> <br /> * Iteration 2: definition of notification request and response regarding the Subscription and Notification (S&amp;N) pattern;<br /> * Evidence request, DE/DO mocks;<br /> * Average grade element was added to the diploma scheme, due to requirements at the Universitat Jaume I (UJI) to rank applicants;<br /> * Automatic confirmation of messages;<br /> * Canonical data models: additional information to generate other types of evidence;<br /> * Capacity to differentiate between &quot;environments&quot; (mock, preproduction and piloting) in the information returned by the IAL, since in the second iteration we had just one playground for all the environments; and<br /> * Deregistration, multi evidence.<br /> <br /> [[File:New functionalities.png|left|thumb]]<br /> [[File:New requirements.png|thumb|239x239px]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Figure 1. a) New functionalities; b) New requirements for the existing BBs defined in DE4A lifetime<br /> <br /> Of the new requirements[1], the following were noted:<br /> <br /> * Those necessary to define and implement the above functionalities;<br /> * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 (&quot;Diploma/Certs/Studies/Professional Recognition&quot;) service;<br /> * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and<br /> * Deregistration.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:New_requirements.png&diff=5829 2023-01-27T14:19:58Z

<p>Ictu harold.metselaar: </p> <hr /> <div>New requirements for existing BBs</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=File:New_functionalities.png&diff=5828 2023-01-27T14:18:49Z

<p>Ictu harold.metselaar: </p> <hr /> <div>New functionalities</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5827 2023-01-27T14:15:46Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}<br /> <br /> == Questionnaire design ==<br /> This questionnaire aims to analyze the extent and the ways of employment of a list of BBs, whichwere cataloged during the first assessment phase of this task. Through a number of assessment categories and indicators assigned to them, the questionnaire supports a methodology that allows us to qualify and quantify the applicability, functionality, maturity and potential for reusability of each of the BBs, especially in view of the DE4A project.<br /> <br /> The questionnaire contains 9 sections, i.e. categories, inquiring on:<br /> <br /> * Inventory of BBs and functionalities;<br /> * Interoperability;<br /> * Maturity;<br /> * Openness;<br /> * Ease of implementation;<br /> * Meeting pilot requirements;<br /> * Performance (Non-functional requirements);<br /> * Patterns; and<br /> * Trust, Identity, Security, Privacy, Protection.<br /> <br /> The questionnaire was distributed among the relevant (aforementioned) partners, and the feedback has been obtained in the period 28.11.2022 - 12.12.2022. Based on the insights from the provided feedback, we are able to also extract valuable lessons learned through the implementation practices, as well as recommendations for future reuse of the analyzed BBs.<br /> <br /> '''''Note:''''' ''The BB assessment includes the BBs used in both iterations of the pilots. It also includes BBs used in the playground and the mocked DE/DO.''<br /> <br /> == Results and Analysis ==<br /> <br /> == Data and preprocessing ==<br /> After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.<br /> <br /> Table 2.Distribution of received valid feedback per partner type<br /> {| class=&quot;wikitable&quot;<br /> |'''Partner type'''<br /> |'''# of assessments done'''<br /> |-<br /> |1 (WP5 representative)<br /> |2<br /> |-<br /> |2 (DBA pilot representative)<br /> |1<br /> |-<br /> |3 (SA pilot representative)<br /> |4<br /> |-<br /> |4 (MA pilot representative)<br /> |1<br /> |-<br /> |5 (MS representative)<br /> |2<br /> |-<br /> |Valid<br /> |10<br /> |}<br /> <br /> == Data analysis ==<br /> In this section, we present the analysis of the obtained data and put the results in both the DE4A and the wider context relevant for reusing the analyzed BBs. We then provide comparative analysis between the two evaluation phases of the BBs carried out in the DE4A project.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=5826 2023-01-27T14:13:31Z

<p>Ictu harold.metselaar: </p> <hr /> <div>== Building Block Assessment - 2nd Phase ==<br /> The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.<br /> <br /> == Methodology ==<br /> The methodology for evaluation was designed following general systemic principles, with a set of indicators including: usability, openness, maturity, interoperability, etc. The identification of the evaluation criteria and the analysis of the results have been approached from several perspectives: literature survey and thorough desktop research; revision and fine-tuning of the initial BB set and evaluation methodology, and an online questionnaire designed for gathering feedback by the relevant project partners:<br /> <br /> -      Member States (MSs)<br /> <br /> -      WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)<br /> <br /> -      WP5 partners - for specific components<br /> <br /> <br /> To revise and fine-tune the evaluation methodology developed in the first phase, as well as the set of BBs selected for assessment as a result, several meetings and consultations were held with the aforementioned project partners. This led to a narrower set of relevant BBs consisting of a subset of the ones assessed in the first phase, and news ones resulting from the piloting needs and implementation. To capture these specificities, a wide set of questions from the survey capture all aspects important for the decisions made and for future reuse. Several iterations over the initial set of questions were performed, determining the relevance according to the roles of the project partners that provided feedback. Finally, a process of feedback coordination was also determined for the pilot leaders, who gathered additional information by the pilot partners’ implementation of some of the BBs (or important aspects of them).<br /> <br /> It is important to note that the division of partners according to their role in the project was done due to the difference in the set of BBs that they had experience with. This implies that not each partner evaluated the whole set of BBs, but only the BBs relevant for their practice and research in the DE4A project.<br /> <br /> The final set of relevant BBs per partner type is given in Table 1, together with statistics on the number of assessments obtained for each BB.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 List of building blocks evaluated in the second phase, per relevant partner<br /> |'''#'''<br /> |'''Building Block'''<br /> |'''# of assessments on the BB'''<br /> |'''Relevant partner(s)'''<br /> |-<br /> |<br /> |'''Common Components'''<br /> |<br /> |<br /> |-<br /> | '''1'''<br /> |eDelivery (data exchange)<br /> |3<br /> |WP5/MSs<br /> |-<br /> | '''2'''<br /> |SMP/SML<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''3'''<br /> |DE4A Connector<br /> |2<br /> |MSs via pilots <br /> |-<br /> | '''4'''<br /> |DE4A Playground<br /> |6<br /> |DBA/SA/MA<br /> |-<br /> |<br /> |'''Semantic'''<br /> |<br /> |<br /> |-<br /> | '''5'''<br /> |Information Exchange Model<br /> |7<br /> |DBA/SA/MA/WP5 <br /> |-<br /> | '''6'''<br /> |Canonical Data Models<br /> |6<br /> |DBA/SA/MA DE and DO pilot partners <br /> |-<br /> | '''7'''<br /> |ESL (implemented as part of SMP/SML)<br /> |1<br /> |WP5 <br /> |-<br /> | '''8'''<br /> |IAL<br /> |1<br /> |WP5 <br /> |-<br /> | '''9'''<br /> |MOR<br /> |1<br /> |MA pilot partners <br /> |-<br /> |<br /> |'''eID/PoR'''<br /> |<br /> |<br /> |-<br /> | '''10'''<br /> |SEMPER<br /> |1<br /> |DBA<br /> |-<br /> |<br /> |'''VC Pattern'''<br /> |<br /> |<br /> |-<br /> | '''11'''<br /> |SSI Authority agent<br /> |4<br /> |SA<br /> |-<br /> | '''12'''<br /> |SSI User agent (mobile)<br /> |4<br /> |SA <br /> |-<br /> | '''13'''<br /> |EBSI-ESSIF (CEF Blockchain)<br /> |1<br /> |WP5 (T5.4) <br /> |}</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Lookup_Pattern&diff=4757 2022-05-02T13:58:21Z

<p>Ictu harold.metselaar: /* Application Collaborations */</p> <hr /> <div>The Lookup pattern is used by the Doing Business Abroad Pilot in [[Use Case &quot;Doing Business in Another Member State&quot; (DBA UC2)]].<br /> <br /> == Functional Variants of the Lookup Pattern ==<br /> The basic logic of the Lookup pattern is a simple Request-Response interaction between DC and DP without any user involvement. This is only applicable in cases where the exchange has a legal basis and can be executed without explicit request or consent from the User. Its main characteristic is online and near real-time (NRT) use of information. The pattern must be &quot;light weight&quot;. DC and DP usually know each other up front and the communication relationship is set up to cover a number of repetitive interactions over time.<br /> <br /> We identified two functional variations: the Evidence Lookup and the Attribute Lookup.<br /> <br /> === Evidence Lookup ===<br /> This variant is for looking up a complete Evidence. Once is established that a lookup of the evidence is needed, e.g. via a notification from the DP to DC (see for instance the [[Subscription and Notification Pattern]]), the evidence can be retrieved in its entirety. This flavour of the Lookup Pattern can also be used for integration in public service (back-office) processes for cases where a legal basis for data sharing exists (e.g. bilateral agreement or publicly available data).<br /> {| class=&quot;wikitable&quot;<br /> |+Message Exchange<br /> !Request<br /> !Response<br /> |-<br /> |Evidence type ID<br /> |The evidence in its entirety<br /> |}<br /> <br /> === Attribute Lookup (i.e., using API) ===<br /> This variant is for getting updates for specific attribute(s) as well as addressing the need for an API approach. Reusing existing APIs that already exist in MSs and providing a light-weight alternative for eDelivery.<br /> {| class=&quot;wikitable&quot;<br /> |+Message Exchange<br /> !Request<br /> !Response<br /> |-<br /> |(array of) attribute(s) [canonical of domestic]<br /> |A partial evidence, i.e., a number of attributes (key/value pairs or a data structure)<br /> |}<br /> <br /> === Alternative Solution Approaches ===<br /> <br /> ==== Evidence Lookup ====<br /> It makes sense to reuse what has already been implemented, i.e., the Intermediation Pattern. This way we are leveraging the AS4-infrastructure and message definitions which are already put in place. Because the Lookup Pattern doesn't imply user intervention the Intermediation pattern can be simplified, i.e., no explicit request and no preview and less multiplicity concerns.<br /> <br /> This alternative is the proposed solution approach for DBA second iteration.<br /> <br /> ==== Attribute Lookup ====<br /> This flavour of the Lookup Pattern addresses the need for a &quot;light weight&quot; alternative for eDelivery as well as the need for reusing existing APIs in MSs.<br /> <br /> One such example in context of our [[Doing Business Abroad Pilot]]: The Netherlands is calling an API in Belgium to retrieve some simple piece of information. Redeveloping existing solutions in order to make use of the eDelivery infrastructure cannot be justified.<br /> <br /> The Commission also recognises the need for a simple, complementary alternative. An interesting development is the piloting of an API approach in ISA&lt;sup&gt;2&lt;/sup&gt;. This project investigates new patterns of data access by request and data sharing. The initiative will facilitate design choices on the legal, organizational, semantic and technical level necessary for setting up APIs. It includes the piloting of such an approach through a combination of the CEF eDelivery building block and a REST-based profile (a.k.a. &quot;the APIs approach&quot;). This looks like a promising initiative and an interesting development for the future. At this point in time however, there is no mature BB for DE4A to be used. This is one of the reasons why we recommend the Evidence Lookup as solution direction for the DBA Pilot.<br /> <br /> == Working hypotheses and implementation principles ==<br /> {| class=&quot;wikitable&quot;<br /> |+Table 5: Lookup Pattern working hypotheses and implementation principles<br /> |'''Interdisciplinary Topic'''<br /> |'''Hypothesis / Principle'''<br /> |'''Implications and Limitations'''<br /> |-<br /> |Orchestration / Choreography<br /> |The DC is orchestrating the overall flow. This means that the process on DP side is a child processes of the process on the DC side.<br /> |The DC controls the status of the DP evidence retrieval process. The DC can retain overall control by reacting to responses of the DP (evidence or error) and monitoring the a response is received in a reasonable amount of time (i.e. SLA)<br /> |-<br /> |Complementary, overlapping or conflicting evidence equivalents<br /> |Cases of ambiguous evidences must in principle be supported by the technical system. These cases are expected to be rare for lookup, because it is always related to a single Evidence request, single Evidence Type and single DP in contrast to the [[Intermediation Pattern]] that by definition needs to be able to handle multiple Evidence requests to multiple DP in potentially different countries relevant for a single eProcedure.<br /> |The DE4A pilot cases appear not to suffer from this issue and the canonical evidence approach also means that this issue is usually resolved at the DP-side.<br /> |-<br /> |Interrupted vs. Uninterrupted exchange<br /> |The whole lookup is handled in an uninterrupted manner. This means that any exception during the lookup leads to its termination, potentially to be repeated at a later time as a new attempt.<br /> <br /> |<br /> |-<br /> |Identity and Record Matching<br /> |From experience on MS-level we see that a reasonably good match can result from the use of the (mandatory) eIDAS attributes. The working hypothesis is that this insight can be generalised to all pilot MSs and that the subject of the lookup can be identified with a similar set data set. This data set can be delivered by the DC as part of the Evidence Request. <br /> |The DC must be in possession of the identification data set when requesting the evidence. If the subject is a natural person, then the DC must have a legal basis to transmit the identification data set as it is personal data.<br /> The problem is not relevant for DBA there the subject is a company and the European Unique Identifier for companies (EUID) can be used. <br /> |-<br /> |Encryption Gap<br /> |Identical to [[Intermediation Pattern|Intermediation]]: OOP in the public sector does not require true E2E encryption. The exchange between DR and DP must be encrypted and signed, as well as the transfers (if applicable on national level) between DR and DE on DC side and DT and DO on DP side (i.e. using the national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable.<br /> |This might not hold for cases where the gateway would be outsourced to a private sector subcontractor, which is not foreseen for the DE4A pilots.<br /> |-<br /> |Structured data vs. unstructured data<br /> |Identical to [[Intermediation Pattern|Intermediation]]: Evidence is handled as structured data. This is not contradicting the addition of an unstructured or scanned document/certificate as part of the structured data transfer (hybrid approach) for reasons of legal validity as identified as barrier in [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/f739c2_c67cf3f7cdf943a48cf8c14c8b1bf36f.pdf D1.7]: L4: National requirements for original and /or certified copies of evidence.<br /> |<br /> |-<br /> |Automated re-use of data<br /> |Identical to [[Intermediation Pattern|Intermediation]]: Evidence and its use in public service procedures has legal consequences. We assume that automated re-use without premediated harmonization of evidence data definitions is not applicable for the OOP transfer of evidence between MS.<br /> |To facilitate automated re-us of data requires establishing canonical evidence definitions. For [[Doing Business Abroad Pilot|DBA]], this is the case.<br /> |-<br /> |Production system and real-life cases<br /> |The lookup pattern is not covered by the SDGR [ref] or only as so far as the exchange is allowed under national or Union law. This means that it requires a separate legal basis (see also legal considerations below).<br /> |For [[Doing Business Abroad Pilot|DBA]], company registration data is already publicly available which serves a legal basis for the lookup.<br /> |-<br /> |Payment for evidence<br /> |In the context of the pilots we assume that no payments are required.<br /> |This can restrict transition of pilot solutions to production in cases that competent authorities require payment for issuing evidence. As this is often the case for business registers and could impact the exploitation of the [[Doing Business Abroad Pilot|DBA]] results.<br /> |-<br /> |BRIS integration<br /> |A technical re-use or bridge to BRIS is not possible because of differences in scope and accessibility by competent authorities other than business registers. The semantic definitions of BRIS can be largely reused.<br /> |The pilot system for the [[Doing Business Abroad Pilot|DBA]] need to be set-up separate from BRIS.<br /> |-<br /> |Matching evidences between Member States<br /> |The final system should support both harmonized and harmonized evidence type and the architecture is taking account of both bases. In the pilot context, focus will be put on establishing deep semantic interoperability through the definition of canonical evidences <br /> |Heterogeneous, national evidence types do not need to be matched in run-time in the pilots. For all evidence types in DE4A, a canonical form is defined and agreed between the pilot partners.<br /> Each partner needs to implement a transformation from national to canonical evidence.<br /> |-<br /> |Multi-evidence Cases<br /> |The system should support all four multi-evidence cases, which means that an array of evidence types and evidences could be included in a single OOP request/response.<br /> |The second iteration should expand the MVP restriction to a single request to single evidence cases, which requires an update of the Exchange Information Model. It is likely that piloting would focus on simpler cases to show the inclusion of multiple evidences in a single evidence response.<br /> The multi-evidence cases are likely not relevant for the [https://wiki.de4a.eu/index.php/Doing_Business_Abroad_Pilot Doing Business Abroad Pilot]. Theoretically, the 'Multi Evidence Types'-case could be applied in the second iteration to request e.g. company registration evidence and annual financial statement in a single request.<br /> |}<br /> <br /> == Legal Considerations ==<br /> In terms of legal challenges, the lookup pattern faces the complexity that it is not directly supported by the SDGR. The objective of the lookup pattern is not to transfer evidence in accordance with the SDGR, since evidence transfers under the SDGR are driven (in principle) by an explicit user request. The lookup pattern instead by definition aims to transfer information directly at an authority's request, without any necessary involvement of a user in the specific exchange. <br /> <br /> However, this is not necessarily a fundamental problem. If the lookup pattern focuses on information that is publicly available (e.g. in a publicly accessible database or using an open web service or API), then it would be perfectly feasible for an authority to query that database using the lookup pattern. This would be lawful even outside of the context of the SDGR, assuming that the data holder has the legal authority to indeed make the relevant information publicly accessible, and that the data evaluator has the legal authority to request such information without user request (i.e. if there is no legal requirement on them to rely exclusively on information provided by the user). If those two prerequisites are satisfied, the lookup pattern can be piloted in DE4A, without any reliance on the SDGR. <br /> <br /> It is worth cautioning for an additional complexity when using the lookup pattern for personal data. The challenge is not the legal basis for personal data processing, which both the data holder and data evaluator should be able to find in their respective legal mandates under national law. Instead, the challenge is transparency: the data evaluator will be using the obtained data under its own legal responsibility, acting as a data controller. This implies that it is legally bound to provide transparency information to the data subject. This will generally only be feasible if there has been direct communication between the data evaluator and the data subject, so that this information can be provided (basically that the lookups will happen, and what the information will be used for). If such direct contact is not legally possible, then lookups of personal data are legally inadvisable<br /> <br /> == Business Process of the Evidence Lookup ==<br /> <br /> The Figure below shows the BPMN Business Process Collaboration view of the Evidence Subscription Process, which is either triggered because a [[Subscription and Notification Pattern|Notification]] was interpreted to require an evidence update, or it is triggered by a Public Service procedure that requires an evidence that can be fetched based in bilateral agreement or national or Union law. Please note that this pattern is '''not''' triggered by the user. The Evidence Lookup could therefor also be used in a traditional procedure based on a physical transaction with the user.[[File:Evidence Lookup pattern.png|alt=Evidence Lookup Business Process Collaboration|none|thumb|Evidence Lookup Business Process Collaboration]]As you can see in the Business Process Collaboration view above, the process of looking up an evidence for the first time or looking up a new version of the evidence is essentially identical. These variants have, however, different legal implications and might consequently differ in the authorization aspect of the Evaluate Evidence Request activity. The process is also very similar to the [[Intermediation Pattern]], even though not all activities listed below are equally relevant for all use cases. The Establish Subject Identity activity, for example, is not relevant for all business use-cases that can base identification on a European unique identifier. The DC looks up the correct DP, which might be simplified for pilot purposes, and sends an Evidence request to the DP. The DP checks the request, extracts the evidence and returns the Evidence response that is then saved by the DC. <br /> {| class=&quot;wikitable sortable&quot;<br /> |+Business activities of the Lookup pattern<br /> |'''Activity / UC'''<br /> |'''Role'''<br /> |'''Type'''<br /> |'''Description'''<br /> |-<br /> |Determine required cross-border evidence<br /> |DE<br /> |Service<br /> |This step makes sure that the DE always requests the recent version of the Evidence type (cf. canonical evidences); in the evidence update case, for example, the evidence type definitions might have changed since the last lookup.<br /> In cases where the evidence type is not harmonized, the required evidence type (in terms of the DC country) is translated into equivalent evidence types that are issued in a lawful way in the DP country indicated by the user (not in pilot scope). <br /> |-<br /> |Lookup routing information<br /> |DR<br /> |Service<br /> |The DR retrieves the technical routing information (e.g. eDelivery rooting identifier), based on the evidence type (in terms of DP country) and the issuing competent authority (or geographic scope of authority). Note that the Evidence Lookup is used in DE4A in combination with the [[Subscription and Notification Pattern]], so as long as the subscription and lookup service is provided by the same DC, the participant ID can be assumed to be known and be included in the Evidence update requirement.<br /> |-<br /> |Request evidence<br /> |DR<br /> |Service<br /> |The DR encrypts, signs and sends the evidence request to the identified technical data service interface of the DP. The evidence request must include subject (i.e. company) information that enables the DP to identify for which subject the evidence must be issued. Companies already have a European unique identifier available (EUID), which is sufficient identification information.<br /> |-<br /> |Evaluate evidence request<br /> |DT<br /> |Service<br /> |The DT receives and decrypts the request and checks whether the request meets formal requirements and can be accepted. It should be checked whether the requesting competent authority can reasonably and rightfully request that specific type of evidence (The authority check is not piloted in DE4A)<br /> |-<br /> |Establish subject identity<br /> |DO<br /> |Service<br /> |This activity is only relevant in absence of a European Unique Identifier. The DO matches identification information about the subject (i.e. equivalent to eIDAS mandatory and optional attributes) with the DP country’s records to identify the subject in their systems. This amounts to matching the eIDAS attributes to a national identification number. This is a Data Owner activity, because in a distributed scenario the data transferor might not have a legal basis to do so.<br /> |-<br /> |Communicate non-availability of OOP<br /> |DT<br /> |Service<br /> |This exception handling activity is only relevant in absence of a European Unique Identifier: The DT informs the DR that the subject cannot be identified unequivocally and the system cannot be used to transfer the evidence.<br /> |-<br /> |Extract evidence<br /> |DO<br /> |Service<br /> |The DO extracts the requested evidence form their registry and forwards it to the DT.<br /> |-<br /> |Communicate non-availability of evidence<br /> |DT<br /> |Service<br /> |Exception handling activity: The DT informs the DR that the requested evidence cannot be provided or cannot be provided within the agreed SLA.<br /> |-<br /> |Establish non-availability of OOP<br /> |DR<br /> |Service<br /> |Exception handling activity: The DR catches the negative (non-evidence) response from the DT and establishes the reason in terms of the DC country system and language:<br /> There are potentially several reasons why an OOP transfer of evidence is not available. The DT communicates these reasons to the DR in all cases that the evidence request cannot be fulfilled (i.e. by sending the digitally available evidence within the agreed SLA as described above).<br /> <br /> At the moment we expect at least the following reasons for such an exception that should be framed in standard error messages or codes, each one with a corresponding recommendation.<br /> <br /> * Subject cannot be uniquely identified – fall-back to another channel (i.e. IMI)<br /> * Evidence not found – Check whether the request specified the correct geographical scope of authority and contact the DP directly if that was the case<br /> * Evidence transfer blocked for legal or authorization reasons – Contact the DP directly<br /> * Evidence is not readily available in a digital format now. Expected time for the evidence to be available is x days – return after x days and issue a new evidence request<br /> |-<br /> |Compose evidence response<br /> |DO<br /> |Service<br /> |The DO prepares the extracted evidence to be sent as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, as is the case in [[Doing Business Abroad Pilot|DBA]], then this task includes the translation of the national definitions into the canonical evidence.<br /> |-<br /> |Transfer evidence<br /> |DT<br /> |Service<br /> |The DT creates the evidence response message (compliant to agreed message format), encrypts and signs the message and sends it to the DR.<br /> |-<br /> |Forward evidence<br /> |DR<br /> |Service<br /> |The DR registers the receipt, decrypts the message and in many cases encrypts the message in a MS specific format to hand it on to the DE.<br /> |-<br /> |Evaluate evidence<br /> |DE<br /> |Service<br /> |The DE validates that the evidence conforms to the evidence type requested and stored or updates the evidence. If it is a new evidence that was requested as part of a public service procedure, the availability of the evidence is signalled to the active procedure. <br /> |}<br /> <br /> == Process Realisation of the Evidence Lookup ==<br /> <br /> The figure below shows how application services serve the Data Consumer process. The application services are realized by application collaborations.<br /> [[File:Lookup Process Realization - DC.png|alt=|none|thumb|Process realization of the Data Consumer]]<br /> The process starts by an external business trigger identifying the need for an evidence or update thereof. With the help of the [[Information Desk]] the required cross-border evidence is determined and the relevant routing information is looked up.<br /> <br /> Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and can be tracked using [[Evidence Interchange Management]]. The signature of the Evidence response message is validated and the message decrypted ([[Trust Architecture]]). Next the evidence can be evaluated by the DC ([[EProcedure Portal]]) and if all is well the public service can be (or continued to be) provided.<br /> <br /> &lt;span style=&quot;background:#FFFF00&quot;&gt;TODO After discussion with DBA change Req/Evidence matching (eProcedure Portal) to &quot;Assess Evidence&quot; in eProcedure Back-office.&lt;/span&gt;<br /> <br /> The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.[[File:Lookup Process Realization - DP.png|alt=|none|thumb|Process Realization of the Data Provider]]<br /> <br /> The Evidence request is received via [[Data Logistics]] and with the help of [[Trust Architecture]] the DP checks the signature of the request and decrypts it. An Authority check may be performed using the [[Information Desk]] establishing that the DC is allowed to request the evidence type, which is most likely not in scope of the pilot with a limited number of participants. Next the subject identity is established using [[Trust Architecture]]. If successful, the evidence is extracted by [[Evidence Retrieval]] Retrieval and transformed to canonical form ([[Evidence Portal]]). Various exceptions like non-availability of OOP or the delay or non-availability of evidence are handled by [[Evidence Portal]] and [[Data Logistics]] . If all is well , the Evidence response is composed and prepared for transfer ([[Evidence Portal]]), encrypted and digitally signed using [[Trust Architecture]] and ultimately exchanged using [[Data Logistics]].<br /> <br /> &lt;span style=&quot;background:#FFFF00&quot;&gt;TODO as per target architecture (D2.7) it should be eProcedure Back-office communicating with Evidence Interchange Management&lt;/span&gt;<br /> <br /> === Application Collaborations ===<br /> [[Information Desk]]<br /> <br /> [[Evidence Retrieval]]<br /> <br /> [[Trust Architecture]]<br /> <br /> [[Data Logistics]]<br /> <br /> [[Evidence Interchange Management]]<br /> <br /> [[Evidence Portal]]<br /> <br /> [[EProcedure Portal]]<br /> <br /> == Future Extension: Attribute Lookup Using API ==<br /> As elaborated above an interesting development is a pilot project of ISA&lt;sup&gt;2&lt;/sup&gt;. We think this development holds great promise for future cross border data exchange in specific contexts.<br /> <br /> &lt;span style=&quot;background:#FFFF00&quot;&gt;&lt;&lt;reference in PSA: ISA&lt;sup&gt;2&lt;/sup&gt; Action ‘Innovative Public Services’: Piloting a REST API extension of CEF eDelivery, 30/10/2020 v1.1&gt;&gt;&lt;/span&gt;<br /> {| class=&quot;wikitable&quot;<br /> |Source<br /> |European Commission<br /> |-<br /> |Action Owner<br /> |CONNECT (DIGIT, JRC).<br /> |-<br /> |Objectives &amp;<br /> <br /> scope<br /> |Develop relevant legal, organizational and technical artefacts trialled through a combination of the CEF eDelivery building block with blockchain-based transactions’ log and a REST-based profile (a.k.a. APIs approach), that support new patterns of data access by request and data sharing. The initiative will facilitate design choices on the legal, organizational, semantic and technical level necessary for setting up APIs.<br /> |}<br /> The REST-based profile is relevant for the DE4A Attribute Lookup pattern; however the scope of the API project is (much) wider. The envisaged implementation is an extension of the eDelivery BB. In the next section, we summarize some of the results of that Pilot project, e.g. the business case, the envisaged Light Context and the requirements which were fed in to the activity as well as the legal basis for this data exchange approach. We conclude with an analysis from a DE4A point of view which could act as a checklist of decisions to be made when implementing an API approach for cross-border eGovernment interoperability. <br /> === Business Case ===<br /> The need for a complementary alternative to eDelivery was identified. The data exchange would operate in a so-called &quot;light context&quot;. A BB with a profile to cater for the REST API architectural style primarily addressing different architectures and communication patterns than those already supported by the eDelivery AS4 profile. <br /> <br /> === Light Context ===<br /> The term “light context” refers to a set of constraints and circumstances applying to organisations or environments that do not run (in) an enterprise IT data centre (non-limitative):<br /> * Organisational constraints<br /> * Hardware and IT infrastructure constraints<br /> * “Low throughput” scenarios<br /> * Limitations introduced by sandbox environments<br /> <br /> * <br /> <br /> === Requirements ===<br /> A number of requirements were drawn up for the envisaged specification:<br /> <br /> * Simple or automatic installation of the software<br /> * Minimal or zero configuration that assumes no advanced knowledge of the used technology<br /> * Minimal operation and maintenance<br /> * Ease of use with immediate start and no complicated enrolment<br /> * Reduced requirements on the hardware resource<br /> * Reduced access privileges on the host <br /> <br /> === Legal Basis ===<br /> Legal basis: the activity is carried out under the ISA² action on Innovative Public Services, legal artefacts are also envisaged.<br /> <br /> See also Legal Consideration above.<br /> <br /> === Analysis - Checklist of Required Decisions for Applying API-Approach ===<br /> The analysis of the proposed API-approach for the ISA&lt;sup&gt;2&lt;/sup&gt; pilot yields the following list of aspects to be considered when implementing an API approach:<br /> <br /> ==== The number of corners to be supported, 2 or more ====<br /> The specification/profile could consider a variable number of corners, starting with as few as two and extending the model to support an arbitrary number greater than four (interoperability with other existing protocols and message/data exchange networks). <br /> <br /> # 2-corner – traditional client-server call (proposed for DE4A as simplifying assumption)<br /> # 3-corner – a reduced version of the 4-corner where corners C1 and C2 are collapsed into a single corner, C1+2, or corners C2 and C3 are collapsed into a single corner, C2+3 (examples include a conference call app or sending an email directly via SMTP)<br /> # Four corners or more, in particular in the sense of not introducing accidental barriers to interoperability between the REST API profile and other existing protocols and message/data exchange networks is concerned (CEF eDelivery AS4, SDG, X-Road, GAIA-X). The profile should strive to minimise the need for a conformant API to be adapted for use in different such networks.<br /> * The communication patterns to be supported<br /> <br /> ==== Communication patterns ====<br /> Various communication patterns can be considered, e.g.:<br /> <br /> # Synchronous business response (the sending corner (C1) sends a business message to the receiving corner (C2) via an http request and expects a business response. The http response it receives from C2 contains a business message and completes the exchange) (proposed as a simplifying assumption for DE4A).<br /> # Asynchronous business response (the sending corner (C1) sends a business message to the receiving corner (C2) via an http request and expects a business response. The http response it receives from C2 contains no business message, but only an acknowledgment of receipt. The business response will be obtained at a later time, e.g., through a pull or web socket).<br /> # No business response (the sending corner (C1) sends a business message to the receiving corner (C2) via an http request and does not expect a business response. The http response it receives from C2 contains only an acknowledgment of receipt and completes the exchange).<br /> # reliable delivery (in a 3-corner model, by enabling retry calls from C2 to C3)<br /> # broadcast (in a 3-corner model, by forwarding the call to a list of recipients)<br /> # asynchronous send buffer / streaming (send buffer instead of full message)<br /> # correlated calls to transmit multi-part messages<br /> <br /> ==== How to manage identity ====<br /> Direct management of certificates is impractical in a “light context”, alternative authorisation approaches relying on protocols designed for the web/mobile application world are required instead. There are a number of candidates to be considered. Currently, it is not clear what standard(s) should be supported.<br /> <br /> # OAuth 2.0 / OpenID Connect<br /> # JSON Web Token<br /> # SAML<br /> # Web authentication<br /> # FIDO 2<br /> # potentially others (e.g., EU Login)<br /> <br /> ==== Transport protocols ====<br /> An obvious candidate is HTTP/JSON which would also be our recommendation for DE4A, however, there are alternatives, e.g. XML.<br /> # <br /> <br /> ==== Integrity &amp; confidentiality ====<br /> Here we have a clear recommendation of TLS (&lt;&lt;see WP5 recommendation document: 1.2 or later + strong block cipher&gt;&gt;) <br /> <br /> The message signing option would have to be investigated. <br /> <br /> ==== (Q)ERDS = Qualified Electronic Registered Delivery Service ====<br /> This would not be required for DE4A but implies some interesting use cases.<br /> <br /> As can be concluded from the above analysis the API approach is definitely more complex than the initially envisage lookup pattern from D2.1 (a simple synchronous request/reply to obtain a few attributes). However it holds promise in the sense that we could leverage existing APIs in the MSs to facilitate cross-border data exchange instead of costly redevelopments to make it fit e the Delivery/AS4 solution.</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Evidence_Portal&diff=4718 2022-04-20T12:24:22Z

<p>Ictu harold.metselaar: </p> <hr /> <div>The Evidence portal application collaboration constitutes back-end functionality implementing error handling for the DP. It interfaces with Evidence retrieval and Data logistics.<br /> <br /> &lt;gallery widths=&quot;400&quot; perrow=&quot;4&quot; caption=&quot;Graphic representations of the Evidence Portal application collaboration&quot;&gt;<br /> File:Evidence Portal IM.png|alt=Graphic representation of the Evidence Portal application collaboration in the Intermediation Pattern|[[Intermediation Pattern|IM]] and [[Lookup Pattern|LKP]]<br /> File:Evidence Portal USI.png|alt=Graphic representation of the Evidence Portal application collaboration in the User Supported Intermediation Pattern|[[User-supported Intermediation Pattern|USI]]<br /> File:Evidence Portal (VC).png|alt=Graphic representation of the Evidence Portal application collaboration in the Verifiable Credentials Pattern|[[Verifiable Credentials Pattern|VC]]<br /> &lt;/gallery&gt;<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+ Application Components of the Evidence Portal<br /> |-<br /> ! Application Component !! Description !! Pattern(s)<br /> |-<br /> | [[Evidence Portal Front-end]] <br /> | This application component implements UI functionality to handle exceptions connected to evidences as well as the preview of evidences. For VC this also includes the enabler of DID connection establishment with the user.<br /> | [[Intermediation Pattern|IM]], [[User-supported Intermediation Pattern|USI]], [[Verifiable Credentials Pattern|VC]]<br /> |-<br /> | [[Evidence Portal Back-end]] <br /> | Shares the functionality that enables the secure exchange of messages, records, forms, and other kinds of data between different ICT systems. <br /> This includes the DID connection handling and evidence related events (VC). Generation of persistent URL which will be communicated to the DC enabling the user to return to “the right place” at a later point in time (USI). Error handling connected to evidences and rendering the evidence so it can be previewed by the user.<br /> | [[Intermediation Pattern|IM]], [[User-supported Intermediation Pattern|USI]], [[Verifiable Credentials Pattern|VC]], [[Lookup Pattern|LKP]]<br /> |}</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=4711 2022-04-20T07:57:27Z

<p>Ictu harold.metselaar: /* How */</p> <hr /> <div>This pages serves for preparation of the 2nd phase of the BB assessment.<br /> <br /> === Why ===<br /> Learn from DE4A real world experience applying BBs. <br /> <br /> === Who ===<br /> People participating in the BB assessment:<br /> * WP leaders/task leaders<br /> * Pilot leaders/architects<br /> * Domain experts in the different WPs<br /> <br /> === What ===<br /> Assess the Solution Building Blocks (SBBs) used in DE4A Pilots.<br /> <br /> Also includes 2nd iteration Pilots.<br /> <br /> Also include new &quot;BBs&quot; like Connector, mockDE/DO, playground, others TBD?<br /> <br /> Take the list of BBs from the first preliminary assessment.<br /> <br /> Select only those BBs that where used in DE4A.<br /> <br /> Add possible missing BBs, i.e. BBs used by the technical WPs that are not on the list.<br /> <br /> * <br /> <br /> === How ===<br /> See [https://wiki.de4a.eu/index.php/Building_Blocks BB 1st phase], are we doing this?<br /> <br /> For this set of BBs a questionnaire/survey can be completed.<br /> <br /> ==== indicators ====<br /> Possible indicators for the questionnaire:<br /> * interoperability (4 dimensions --&gt; EIF/EIRA): assess interoperability of the 4 dimensions<br /> *# organizational<br /> *# legal<br /> *# semantic<br /> *# technical<br /> * maturity on context of DE4A:<br /> <br /> # Technical<br /> # Administrative<br /> # Operational<br /> * openness? CAMMS? -&gt; WP6 (WP1/2 can reuse) TODO discuss with Fredrik way forward<br /> * classification BB? Maybe we provide this<br /> *# Standards and Specifications<br /> *# Common code or Components<br /> *# Building Blocks<br /> *# Core Service Platforms<br /> *# Generic Services<br /> * degree of meeting pilot's requirements? any gaps? Pilot leaders assess level of meeting requirements. <br /> * easy of implementation/configuration? separate section. Practical example of using BBs<br /> * performance of the BB? Fit for purpose?<br /> * any lessons learned?<br /> * enabler for something, e.g. Wallet or SEMPER<br /> * any recommendations?<br /> * barriers for implementation, what nature? technical?<br /> * using the BBs, how much do they contribute/ degree of automation, e.g. USI pattern what types of patterns<br /> * cyber security aspects?<br /> * description of context BBs -&gt; how to define sections -&gt; DoA? general questions, specific process related questions, evaluated related questions<br /> * <br /> * <br /> * <br /> <br /> ==== questionnaire ====<br /> For WP3,4 and 5<br /> <br /> Which BB are used by which pilot, by which pattern, new BBs?<br /> <br /> Which SBB is implementing which ABB (from ref. arch.)? Harold <br /> <br /> Provide answers for the indicators above.<br /> <br /> === When ===<br /> TODO planning (April-May):<br /> <br /> # draft questionnaire (first half of May)<br /> # KO and discuss with participants (second half of May)<br /> # finalize questionnaire and submit <br /> <br /> M33 deadline of Wiki, preferably BB assessment takes place before Holidays<br /> <br /> === Envisaged output ===<br /> <br /> === recommendations/lessons learned ===<br /> next steps:<br /> <br /> * plan KO/inputs<br /> *<br /> <br /> [[Category:wip]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=4710 2022-04-20T07:55:16Z

<p>Ictu harold.metselaar: /* How */</p> <hr /> <div>This pages serves for preparation of the 2nd phase of the BB assessment.<br /> <br /> === Why ===<br /> Learn from DE4A real world experience applying BBs. <br /> <br /> === Who ===<br /> People participating in the BB assessment:<br /> * WP leaders/task leaders<br /> * Pilot leaders/architects<br /> * Domain experts in the different WPs<br /> <br /> === What ===<br /> Assess the Solution Building Blocks (SBBs) used in DE4A Pilots.<br /> <br /> Also includes 2nd iteration Pilots.<br /> <br /> Also include new &quot;BBs&quot; like Connector, mockDE/DO, playground, others TBD?<br /> <br /> Take the list of BBs from the first preliminary assessment.<br /> <br /> Select only those BBs that where used in DE4A.<br /> <br /> Add possible missing BBs, i.e. BBs used by the technical WPs that are not on the list.<br /> <br /> * <br /> <br /> === How ===<br /> See [https://wiki.de4a.eu/index.php/Building_Blocks BB 1st phase], are we doing this?<br /> <br /> For this set of BBs a questionnaire/survey can be completed.<br /> <br /> ==== indicators ====<br /> Possible indicators for the questionnaire:<br /> * interoperability (4 dimensions --&gt; EIF/EIRA): assess interoperability of the 4 dimensions<br /> *# organizational<br /> *# legal<br /> *# semantic<br /> *# technical<br /> * maturity on context of DE4A:<br /> <br /> # Technical<br /> # Administrative<br /> # Operational<br /> * openness? CAMMS? -&gt; WP6 (WP1/2 can reuse) TODO discuss with Fredrik way forward<br /> * classification BB? Maybe we provide this<br /> *# Standards and Specifications<br /> *# Common code or Components<br /> *# Building Blocks<br /> *# Core Service Platforms<br /> *# Generic Services<br /> * degree of meeting pilot's requirements? any gaps? Pilot leaders assess level of meeting requirements. <br /> * easy of implementation/configuration? separate section. Practical example of using BBs<br /> * performance of the BB? Fit for purpose?<br /> * any lessons learned?<br /> * enabler for something, e.g. Wallet or SEMPER<br /> * any recommendations?<br /> * barriers for implementation, what nature? technical?<br /> * using the BBs, how much do they contribute/ degree of automation, e.g. USI pattern what types of patterns<br /> * cyber security aspects?<br /> * description of context BBS -&gt; how to define sections -&gt; DoA? general questions, specific process related questions, evaluated related questions<br /> * <br /> * <br /> * <br /> <br /> ==== questionnaire ====<br /> For WP3,4 and 5<br /> <br /> Which BB are used by which pilot, by which pattern, new BBs?<br /> <br /> Which SBB is implementing which ABB (from ref. arch.)? Harold <br /> <br /> Provide answers for the indicators above.<br /> <br /> === When ===<br /> TODO planning (April-May):<br /> <br /> # draft questionnaire (first half of May)<br /> # KO and discuss with participants (second half of May)<br /> # finalize questionnaire and submit <br /> <br /> M33 deadline of Wiki, preferably BB assessment takes place before Holidays<br /> <br /> === Envisaged output ===<br /> <br /> === recommendations/lessons learned ===<br /> next steps:<br /> <br /> * plan KO/inputs<br /> *<br /> <br /> [[Category:wip]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=4708 2022-04-13T08:57:11Z

<p>Ictu harold.metselaar: /* When */</p> <hr /> <div>This pages serves for preparation of the 2nd phase of the BB assessment.<br /> <br /> === Why ===<br /> Learn from DE4A real world experience applying BBs. <br /> <br /> === Who ===<br /> People participating in the BB assessment:<br /> * WP leaders/task leaders<br /> * Pilot leaders/architects<br /> * Domain experts in the different WPs<br /> <br /> === What ===<br /> Assess the Solution Building Blocks (SBBs) used in DE4A Pilots.<br /> <br /> Also includes 2nd iteration Pilots.<br /> <br /> Also include new &quot;BBs&quot; like Connector, mockDE/DO, playground, others TBD?<br /> <br /> Take the list of BBs from the first preliminary assessment.<br /> <br /> Select only those BBs that where used in DE4A.<br /> <br /> Add possible missing BBs, i.e. BBs used by the technical WPs that are not on the list.<br /> <br /> * <br /> <br /> === How ===<br /> See [https://wiki.de4a.eu/index.php/Building_Blocks BB 1st phase], are we doing this?<br /> <br /> For this set of BBs a questionnaire/survey can be completed.<br /> <br /> ==== indicators ====<br /> Possible indicators for the questionnaire:<br /> * interoperability (4 dimensions --&gt; EIF/EIRA): assess interoperability of the 4 dimensions<br /> *# organizational<br /> *# legal<br /> *# semantic<br /> *# technical<br /> * maturity on context of DE4A:<br /> <br /> # Technical<br /> # Administrative<br /> # Operational<br /> * openness? CAMMS? -&gt; WP6 (WP1/2 can reuse) TODO discuss with Fredrik way forward<br /> * classification BB? Maybe we provide this<br /> *# Standards and Specifications<br /> *# Common code or Components<br /> *# Building Blocks<br /> *# Core Service Platforms<br /> *# Generic Services<br /> * degree of meeting pilot's requirements? any gaps? Pilot leaders assess level of meeting requirements. <br /> * easy of implementation/configuration? separate section. Practical example of using BBs<br /> * performance of the BB? Fit for purpose?<br /> * any lessons learned?<br /> * enabler for something, e.g. Wallet or SEMPER<br /> * any recommendations?<br /> * bariers for implementation, what nature? technical?<br /> * using the BBs, how much do they contribute/ degree of automation, e.g. USI pattern what types of patterns<br /> * cyber security aspects?<br /> * description of context BBS -&gt; how to define sections -&gt; DoA? general questions, specific process related questions, evaluated related questions<br /> * <br /> * <br /> * <br /> <br /> ==== questionnaire ====<br /> For WP3,4 and 5<br /> <br /> Which BB are used by which pilot, by which pattern, new BBs?<br /> <br /> Which SBB is implementing which ABB (from ref. arch.)? Harold <br /> <br /> Provide answers for the indicators above.<br /> <br /> === When ===<br /> TODO planning (April-May):<br /> <br /> # draft questionnaire (first half of May)<br /> # KO and discuss with participants (second half of May)<br /> # finalize questionnaire and submit <br /> <br /> M33 deadline of Wiki, preferably BB assessment takes place before Holidays<br /> <br /> === Envisaged output ===<br /> <br /> === recommendations/lessons learned ===<br /> next steps:<br /> <br /> * plan KO/inputs<br /> *<br /> <br /> [[Category:wip]]</div>

Ictu harold.metselaar https://wiki.de4a.eu/index.php?title=Second_phase&diff=4707 2022-04-13T08:48:55Z

<p>Ictu harold.metselaar: /* questionnaire */</p> <hr /> <div>This pages serves for preparation of the 2nd phase of the BB assessment.<br /> <br /> === Why ===<br /> Learn from DE4A real world experience applying BBs. <br /> <br /> === Who ===<br /> People participating in the BB assessment:<br /> * WP leaders/task leaders<br /> * Pilot leaders/architects<br /> * Domain experts in the different WPs<br /> <br /> === What ===<br /> Assess the Solution Building Blocks (SBBs) used in DE4A Pilots.<br /> <br /> Also includes 2nd iteration Pilots.<br /> <br /> Also include new &quot;BBs&quot; like Connector, mockDE/DO, playground, others TBD?<br /> <br /> Take the list of BBs from the first preliminary assessment.<br /> <br /> Select only those BBs that where used in DE4A.<br /> <br /> Add possible missing BBs, i.e. BBs used by the technical WPs that are not on the list.<br /> <br /> * <br /> <br /> === How ===<br /> See [https://wiki.de4a.eu/index.php/Building_Blocks BB 1st phase], are we doing this?<br /> <br /> For this set of BBs a questionnaire/survey can be completed.<br /> <br /> ==== indicators ====<br /> Possible indicators for the questionnaire:<br /> * interoperability (4 dimensions --&gt; EIF/EIRA): assess interoperability of the 4 dimensions<br /> *# organizational<br /> *# legal<br /> *# semantic<br /> *# technical<br /> * maturity on context of DE4A:<br /> <br /> # Technical<br /> # Administrative<br /> # Operational<br /> * openness? CAMMS? -&gt; WP6 (WP1/2 can reuse) TODO discuss with Fredrik way forward<br /> * classification BB? Maybe we provide this<br /> *# Standards and Specifications<br /> *# Common code or Components<br /> *# Building Blocks<br /> *# Core Service Platforms<br /> *# Generic Services<br /> * degree of meeting pilot's requirements? any gaps? Pilot leaders assess level of meeting requirements. <br /> * easy of implementation/configuration? separate section. Practical example of using BBs<br /> * performance of the BB? Fit for purpose?<br /> * any lessons learned?<br /> * enabler for something, e.g. Wallet or SEMPER<br /> * any recommendations?<br /> * bariers for implementation, what nature? technical?<br /> * using the BBs, how much do they contribute/ degree of automation, e.g. USI pattern what types of patterns<br /> * cyber security aspects?<br /> * description of context BBS -&gt; how to define sections -&gt; DoA? general questions, specific process related questions, evaluated related questions<br /> * <br /> * <br /> * <br /> <br /> ==== questionnaire ====<br /> For WP3,4 and 5<br /> <br /> Which BB are used by which pilot, by which pattern, new BBs?<br /> <br /> Which SBB is implementing which ABB (from ref. arch.)? Harold <br /> <br /> Provide answers for the indicators above.<br /> <br /> === When ===<br /> TODO planning (April-May):<br /> <br /> # draft questionnaire<br /> # KO and discuss with participants<br /> # finalize questionnaire and submit <br /> <br /> M33 deadline of Wiki, preferably BB assessment takes place before Holidays<br /> <br /> === Envisaged output ===<br /> <br /> === recommendations/lessons learned ===<br /> next steps:<br /> <br /> * plan KO/inputs<br /> *<br /> <br /> [[Category:wip]]</div>

Ictu harold.metselaar