User-supported Intermediation Pattern

The User-supported Intermediation Pattern is one of the cross-border interaction patterns of the DE4A Reference Architecture. It is a user-managed access pattern in terms (cf. D2.1 Architecture Framework). It is used by the following use cases:

Working hypotheses and implementation principles

The User-supported Intermediation reference interaction pattern is valid under several working hypotheses, which are working hypotheses that are either validated or decided upon by the members of DE4A.

Table 22: User-supported Intermediation pattern working hypothesis and implementation principles
Interdisciplinary Topic	Hypothesis / Principle	Implications and Limitations
Orchestration / Choreography	The DC is orchestrating the overall flow. This means that the (potentially multiple) processes on DP side are child processes of the process on the DC side.	This is also essential for the user-supported intermediation pattern. The DC manages the interaction with the user in context of the eProcedure and controls the status of all PD evidence retrieval processes. The control of the overall process is thus not transferred to the user.
Multiple, complementary, overlapping or conflicting evidence equivalents	Multi-evidence cases must in principle be supported – Identical to Intermediation. Deep analysis on whether they are jointly valid or are contradicting each other is left to the public service provider and not included as functionality in the cross-border OOP sequence	Identical to Intermediation. It is to be investigated whether the pilot cases and MS combinations of the pilots entail multi-evidence cases at all. If that is not the case, the MVP could be restricted to a single request to single evidence case.
Interrupted vs. Uninterrupted exchange	The assumption can be slightly relaxed in comparison to Intermediation, as the direct interaction between U and DP makes it easier to communicate delays transparently. In order to prevent that process instances, need to be kept alive across multiple platforms in multiple MS, we treat the interdependencies as similar to the Intermediation pattern. This means that if the evidence is delayed, i.e. because it is not yet available in digital form, a second essentially independent request needs to be issued in a later attempt. A “save and resume” functionality on the side of the eProcedure portal of the DC becomes, arguably, more important, because of the higher probability that the eProcedure session hits a time-out during the addition time involved in the direct interaction of the U with the DP in comparison to the Intermediation pattern.	One example of a disrupted procedure is evidence that is not readily available in a digital format [..] said to be out of scope of the SDGR, however appears to be a frequent case for older evidence that resides still in paper archives. We might consider a subprocess at the DP that digitizes the requested evidence and informs the user (e.g. via a direct e-mail) about the evidence now being available in a digital format [..].
Explicit request and transitivity between actors	The assumption can be relaxed in comparison to the Intermediation pattern: After 2023 (with SDGR as legal basis), the DP does not need to re-validate the explicit user request, they can rely on the DC to have done so. It is questionable whether this is presently possible in the Pilots, as the SDGR Article 14 enters into force after the Pilot timeline (Article 39). The assumption is, however, that piloting for the SDGR is part of the public authority tasks related to the SDGR (i.e. fall under the application of Article 14 (11)).	The user authenticates himself at the DP and explicitly sustains the request issued to the DC.
Preview & Approval UI	The assumption can be relaxed in comparison to the Intermediation pattern: The preview can be provided, and the user approval collected, by the DC, prior to the evidence being used in eProcedure. It is well understood that the data processing of the evidence on the part of the DC is restricted to providing the preview to the user. This entails the risk that operators of the receiving competent authority could gain, either by accident or (disingenuous) intent, access to the evidence data prior to user authorisation, i.e. for example by using administrator rights on the underlying ICT infrastructure.	The preview is provided by the DP.
Identity and Record Matching	The assumption can be relaxed in comparison to the Intermediation pattern: 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. Two consequences of this hypothesis are that a) the user does not need to provide supplementary attributes and b) a second eIDAS authentication at the DP (potentially multiple DP) is not required.	In case of a user authentication at the DP, using an eID of the DP country, record matching is not needed. If eIDAS is used, then the DP can solicit additional information from the U to perform the match.
Transitivity of user identity	The assumption can be relaxed in comparison to the Intermediation pattern: After 12.12.2023, the SDGR and the legal task of the DC provide the legal basis for the exchange of user or data subject data from DC to DP. We assume that the development in preparation of the SDGR (i.e. piloting) is part of the public authorities’ tasks covered by the SDGR (i.e. Article 14 (11)), hence that the SDGR provides the legal basis for the pilots. Adding a GDPR consent in the explicit request is not a valid legal basis for the case that the identification does include personal data of other data subjects than the requestor (change of address for families).	The user authenticates himself at the DP.
Hand-on of UI between actors	The DP provides an UI to the DC that the user can navigate to.
Mandate and Proxy	Identical to Intermediation, however not relevant for the PSA: The mandate and proxy challenge can be resolved by an extension of the eIDAS node.	The matching of interaction pattern to pilot use cases means that the DBA pilot is not intending to use the user-supported intermediation pattern, hence mandates and powers are not in scope.
Encryption Gap	Identical to 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.
Structured data vs. unstructured data	Identical to 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
Automated re-use of data	Identical to 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.
Production system and real-life cases	The direct interaction between U and DP allows the pilot to go live in production under current national legal constraints	There might still be unforeseen technical, organisational or legal barriers that make a full production use of the pilot systems impractical for some MSs. DE4A Deliverables. D1.7 Legal, technical, cultural and managerial risks and barriers is an important input into this investigation.

Business process collaboration

Figure 15 models the user-supported intermediation pattern in BPMN notation. It consists of three interacting processes, one for the User (U) – the user journey -, one for the Data Consumer (DC) and one for the Data Provider (DP). The message flow (dashed lines) show the interactions – the conversation – between these participants.

In Table 23 the activities of all participants are listed roughly in chronological order across all three processes. The conversations between the participants are described in Table 24, Table 25 and Table 26, listing the messages between the U and DC (Table 24), between DC and DP (Table 25) and between U and DP (Table 26) respectively.

Figure 15: Business Process Collaboration view of the User-Supported Intermediation Pattern

In Table 23 the business activities of all three processes are listed roughly in chronological order from left to right. The first column names the activities shown in Figure 15 above. The second column provides the abbreviation of the responsible role. For a definition of these roles, please refer to the DE4A Deliverable D2.1 Architecture Framework. The third column contains the task type (please refer to the BPMN 2.0 standard specification) as shown in Figure 4 above. Please consider that the task type ‘User’ means that it is a Human/Computer interaction task, not that it is in the responsibility of the User (U) as defined in the Architecture Framework or in Article 3(1) of the SDGR. The fourth column describes the business activity in concise language.

Business Activities of the User-supported Intermediation Pattern

Table 23: Business Activities of the User-Supported Intermediation Pattern
Activity / UC	Role	Type	Description
Request or resume (public) service procedure	U	User	Identical with the Intermediation Pattern: The user navigates to the eProcedure in the DC country and requests a (public) service. This means they fill in the required information and start the eProcedure. It is specific to the MS and the eProcedure how much information is provided by the user (i.e. which fields to be filled out) in this activity (i.e. prior to authentication) or when submitting the eProcedure later in the process. Email should be included as means to contact the user or provide updates. If the user is returning to a previously started procedure, the eProcedure will return to original instance after authentication.
Request authentication	DE	Service	Identical with the Intermediation Pattern: The DE requests the U to authenticate themselves. This can happen in two ways, either using eIDAS (default) or using the eID of the DC MS, in case that the U has the national eID of the DC country available (see cases 3) and 4) in Table 4 above). The DE provides both options to the U.
Provide authentication details	U	User	Identical with the Intermediation Pattern: The U uses the means available to them to provide the authentication details. This can happen at the user’s discretion using the eID of the DC MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication. If the user is representing another entity (typically a legal person), this relation is also retrieved as part of this authentication.
Establish user identity	DE	Service	Identical with the Intermediation Pattern: The DE establishes the identity of the U in the DC MS environment. In the eIDAS case, this means that the eIDAS uniqueness ID must be linked to the national identification number used to access the MS registries. In the national eID case, this means that the eIDAS attributes (mandatory and optional) must be retrieved for further use in the process. In case of business user, the company identification must be matched. The match of the representing natural person to a population register is not required in all MS.
Redirect user to another channel	DE	Service	Identical with the Intermediation Pattern: Exception handling activity: The U cannot be identified in an automated way by the DC and alternative digital or non-digital channel information (depending on the eProcedure at hand user and potentially dependent on the type of identification error) is collected and provided to the U.
Abort eProcedure	U	User	Identical with the Intermediation Pattern: Exception handling activity: Alternative channel information is displayed to the user and the user exits the e-procedure.
Determine procedural requirements	DE	Service	Identical with the Intermediation Pattern: The DE compares the available information (i.e. in the DC MS registries via the national OOP layer) with the information required by the eProcedure. The result can be a (list of) required evidence, defined in terms of the DC country, which is then displayed to the user as a request to provide the evidence, together with the option for the user to request the evidence via the OOTS. This activity is not trivial and should prevent that we ask a User for evidence that is readily available in the DC MS and might not be available in the OOTS cross-border scope. Example: It would not make any sense for a Dutch DC to ask a German national born in the Netherlands to provide a birth certificate (which he could not get via the OOTS as it is not cross-border). A similar situation would be asking a French national with a Belgian university diploma to provide that diploma in order to be admitted for a PhD in another Belgian university.
Request OOP transfer of evidence	U	User	Identical with the Intermediation Pattern: The user choses to request the evidence to be fetched for them using the OOTS – the explicit OOP request. The user also indicates – in a guided way – which MS, and possibly lower administrative level, issues the required evidence. Alternatively, the user could provide (i.e. upload) the evidence, but that would not involve the OOTS at all, so we are not considering this case in the reference architecture.
Determine required cross-border evidence	DE	Service	Identical with the Intermediation Pattern: 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.
Save (public) service request	DE	Service	The eProcedure and all information provided by the U is automatically saved, in order for the user to be able to resume the procedure at a later time, e.g. after a session time-out during the interaction between the U and the DP.
Lookup routing information	DR	Service	The DR retrieves the technical routing information (e.g. eDelivery rooting identifier or URL of the webservice provider), based on the evidence type (in terms of DP country) and the issuing competent authority (or geographic scope of authority).
Request evidence	DR	Service	The DR encrypts, signs and sends the evidence request to the identified technical data service interface of (potentially several) DP. The evidence request must include the return URL of the Evidence Overview in the eProcedure portal, enabling the DP to direct the U back to the DC eProcedure. It should also include user information that enables the DP to identify for which user or represented company the evidence must be issued.
Evaluate evidence request	DT	Service	The DT receives and decrypts the request and checks whether the request meets formal requirements and can be accepted. Because of the direct interaction between U and DP the authority check is not needed, i.e. to check whether the requesting competent authority can reasonably and rightfully request that specific type of evidence. This might not be generalized to all potential cases (cf. OOTS target architecture), not the least for exchanges that do not require user preview and approval
Generate URL for direct user interaction	DO	Service	The DP generates a URL as landing place for the U to navigate that is specific for the required evidence type.
Display link to evidence portal	DR	Service	The link to the specific landing page, received from the DP, is displayed as clickable element (link or button) in the Evidence Status overview.
Navigate to evidence portal	U	User	The user clicks on a link to the evidence portal of the respective DP that is displayed in eProcedure portal of the DC.
Request authentication for evidence retrieval	DO	Service	The DO requests the U for to authenticate themself. This can happen in two ways, either using eIDAS (default) or using the eID of the DP MS, in case that the U has the national eID of the DP country available (case 1 and 2 in Table 4). The case of using the national eID scheme would consequently be quite common. The DP provides both options to the U.
Provide authentication details for evidence retrieval	U	User	The U uses the means available to him to provide the authentication details. This can happen to the user’s discretion using the eID of the DP MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication.
Re-establish user identity	DO	Service	The DO matches the information about the user (i.e. eIDAS mandatory and optional attributes) with DP country records to identify the user in their systems. This amounts to matching the eIDAS attributes to a national identification number. (If the national eID is used, this task is skipped). Data Owner activity, because in a distributed scenario, the data transferor might not have a legal basis to do so.
Provide additional identification information	U	User	Exception handling activity: Interactive form- of chat-based Q&A for additional identification information (beyond eIDAS attributes). The requested information clearly depends on the available information at the data provider.
Communicate non-availability of OOP	DT	Service	Identical with the Intermediation Pattern: Exception handling activity: The DT informs the DR that the user cannot be identified unequivocally and the OOTS cannot be used to transfer the evidence.
Extract evidence	DO	Service	Identical with the Intermediation Pattern: The DO extracts the requested evidence form their registry and forwards it to the DT.
Communicate non-availability of evidence	DT	Service	Identical with the Intermediation Pattern: Exception handling activity: The DT informs the DR that the requested evidence cannot be provided or cannot be provided within the agreed SLA.
Prepare preview	DO	Service	The DO prepares a preview for the U and displays it in the UI of the evidence portal. In addition, the name of the DE to which the evidence is to be transferred is displayed, in order to provide full transparency to the user what exchange he is accepting.
Receive error or delay notification	U	User	Exception handling activity: The DP displays error or delay information to the User. These error messages are listed above in the activity ‘Establish non-availability of OOP’ In addition, the exception UI informs the U to return to the eProcedure portal of the DC.
Preview evidence pre-transfer	U	User	The user can view the evidence in the UI of the DP and can either approve or decline the transfer of evidence. Additionally, the Preview UI informs the User to return to the eProcedure portal of the DC after accepting the evidence exchange.
Transfer evidence	DT	Service	Identical with the Intermediation Pattern: The DT creates the evidence response message (compliant to agreed message format), encrypts and signs the message and sends it to the DR.
Establish non-availability of OOP	DR	Service	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: There are potentially several reasons why and OOP transfer of evidence is not be available. The DT communicates these reasons to the DR in all cases that the evidence request cannot be fulfilled by sending the digitally available evidence within the agreed SLA as described above. 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 to the user. 1) User cannot be uniquely identified – fall back to another channel (i.e. IMI) 2) Evidence not found – Check whether the request specified the correct geographical scope of authority and contact the DP directly if that was the case 3) 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
Update evidence status	DE	Service	Identical with the Intermediation Pattern: The DE updates the status of a requested evidence and provides that update to the user in the evidence overview. Additionally, the update could be sent to the user via e-mail, including a link to the status overview page.
Follow evidence status	U	User	After the user requested the OOP transfer of evidence, they observe the status of the evidence request on an evidence status overview. It essentially shows the progress or the request for each separate evidence requested. These statuses should include: 1) Evidence requested, expected response in x seconds 2) User input required (click-here {link to evidence portal}) 3) Evidence available 4) SLA overrun – please try again later 5) User identification failed 6) Evidence not available 7) Evidence expected to be available in y days – please return If user input is required, a link to the evidence portal of the DP is included for the user to follow.
Forward evidence	DR	Service	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.
Evaluate evidence	DE	Service	Identical with the Intermediation Pattern: The DE checks whether all requested evidences are available and validates that they conform to the evidence type requested. In the positive scenario that all evidences are available, the DE communicates to the user that the procedure can be submitted. In the negative case that not all evidences are received, the DE communicates this back to the U. The Procedure can then not be completed.
Save or abort (public) service request	U	User	Identical with the Intermediation Pattern: Exception handling activity: The U is informed that not all required evidence could be received, hence that there are still missing evidences preventing the eProcedure to be completed. It depends (only) on the functionality of the specific eProcedure portal what options are provided to the U. We expect that in most cases the user can save the procedure in order to return at a later stage, to repeat the cross-border OOP request or to provide the missing evidence themselves.
Submit eProcedure	U	User	Identical with the Intermediation Pattern: The U fills the remaining fields required for the eProcedure. It is specific to the MS and the eProcedure which fields to be filled out in this activity or when requesting the eProcedure at the start of the process. Usually the U is prompted to verify the provided information in an overview before hitting the Submit button.
Receive acknowledgement of receipt	U	Receive	The U is waiting to receive the acknowledgment that their (public) service request is received in order and that the service will be provided, oftentimes incl. an indication of the expected time needed. The acknowledgment can be is displayed in the eProcedure portal or sent by e-mail or deposited in a government-hosted, secure message box or a combination of the above.
Provide public service	DE	Subprocess	Identical with the Intermediation Pattern: This is a subprocess that is very heterogenous in composition and timeline, depending on which public service is provided and by which competent authority. Theoretically, the subprocess could be fully automated in some cases, but typically this is a back-office process involving multiple activities of public servants and might take days to several weeks. In many countries the maximum time for this process is defined by law.
Receive (public) service result	U	Receive	Identical with the Intermediation Pattern: Once the public service is completed, the result is provided to the U. This communication is fully dependent on the functionalities of the eProcedure portal (e.g. e-mail and/or government-hosted, secure message box).

Table 24 describes the conservation between U and DC by listing the exchanged messages in chronological order. Table 25 does the same for the conversation between DC and DP and Table 26 for U and DP.

Conversation between User and Data Consumer

Table 24: User-Supported Intermediation - Conversation between User and Data Consumer
From	Message	To	Description
U	(Public) service request	DC	Identical with the Intermediation Pattern: The choice of public service requested and an initial set of information from the user required for the initiation of the request (breadth and type of information can vary between MS and requested service and can be substantial in some cases. Essentially this includes all information that the user provides prior to the point in the procedure where authentication is required). Inclusion of e-mail could facilitate (additional) messages to the user.
DC	Authentication request	U	Identical with the Intermediation Pattern: Link to UI or identity service provider, potentially to several alternative eID services.
U	Authentication details	DC	Identical with the Intermediation Pattern: Identity information of the user (i.e. uniqueness ID + identification data set).
DC	Alternative channel information	U	Identical with the Intermediation Pattern: Contact information (e.g. email, telephone or address) of an alternative channel to request the public service or to complete authentication/registration.
DC	Request for evidence	U	Identical with the Intermediation Pattern: List of evidences (in terms of the DC country) that are required to complete the eProcedure.
U	Explicit OOP request	DC	Identical with the Intermediation Pattern: Information about the geographic scope of authority for identifying the type of evidence and the data service provider (e.g. which MS ministry, region, municipality).
DC	Evidence portal link	U	Navigable link to the evidence portal that the user can follow in order to support the DP in retrieving and transferring the correct evidence
DC	OOP status update (not available)	U	Error message to the user (see activity description) explaining the reason why the evidence could not be retrieved and recommendation of action. In contrast to the intermediation pattern, the user was already informed by the DP.
DC	Evidence missing	U	Identical with the Intermediation Pattern: Message to the user that not all evidence could be retrieved and that they can resume the eProcedure once all evidence can be provided (either by the user or via the system).
U	(Public) service request (completed)	DC	Identical with the Intermediation Pattern: Complete and final submission of the (public service request), including all required information.
DC	Acknowledgement of receipt	U	Identical with the Intermediation Pattern: Acknowledgement that all required evidence was submitted and the (public) service can be provided to the user.
DC	(Public) service response	U	Identical with the Intermediation Pattern: The result of the (public) service, irrespective of how it is provided (post, email, secure message box, personal appearance.

Conversation between Data Consumer and Data Provider

Table 25: User-Supported Intermediation - Conversation between Data Consumer and Data Provider
From	Message	To	Description
DC	Evidence request	DP	Identical with the Intermediation Pattern: Must include user identification (eIDAS attributes, mandatory and possibly optional). Could additionally include the user email for direct communication
DP	Evidence portal URL	DC	Message containing the persistent URL for user-redirection to the evidence portal
DP	User unknown	DC	Identical with the Intermediation Pattern: Message that the user could not be identified
DP	Evidence not available	DC	Identical with the Intermediation Pattern: Message that the evidence does not exist or could not be retrieved in time
DP	Evidence response	DC	Identical with the Intermediation Pattern: The evidence in electronic format

Conversation between User and Data Provider

Table 26: User-Supported Intermediation - Conversation between User and Data Provider
From	Message	To	Description
U	User navigation trigger	DP	User followed the link to the evidence portal
DP	Authentication request	U	Link to UI of identify service provider, potentially to several alternative services
U	Authentication details	DP	Identity information of the user (i.e. uniqueness ID + identification data set)
DP	Request for additional information	U	Depending on the information on record at the DP this request can include different attributes (e.g. matriculation number for universities, national identifiers for ministries, maiden name….)
U	Additional information	DP	The information attribute that the DP requested to perform the extended identify matching
DP	User unknown	U	Message that the user could not be identified
DP	Evidence not available	U	Message that the evidence is not existing or could not be retrieved in time
DP	Evidence preview	U	Rendered preview of the evidence
U	Preview response	DP	Accepting or declining of the evidence exchange

Process realization

The following diagram shows how the User process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.

Figure: Process Realization of the User process

The User requests (or resumes) a public service via the EProcedure Portal and has to authenticate himself with the help of Trust Architecture. The user can choose to abort the eProcedure, or, If the authentication is succesful, request a transfer of evidence via the OOP Technical System (EProcedure Portal). The User can follow the Evidence Status with the help of Evidence Interchange Management. Next the user is redirected to DP (Evidence Interchange Management) where he has to re-authenticate himself using Trust Architecture, provide additional attributes if needed. Errors or a notification of delay is handled by the Evidence Portal as well as the preview of the evidence at DP side before it is transferred to the DC. If the user wishes so the the eProcedure can be aborted or saved to continue at a later point in time (EProcedure Portal). Finally submission of the eProcedure is also provided by EProcedure Portal after which the Public service can be offered to the User.

Note: difference between IM and USI w.r.t. receive acknowledgement?

The following diagram shows how the Data Consumer process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.

Figure: Process Realization of the Data Consumer process

The DC inititates the authentication of the user in order to establish his identity (Trust Architecture). If this fails the user may be directed to an alternative channel via EProcedure Portal. If authentication is successful the DC has to determine the procedureal requirements, match those requirements with the Evidence needed en determine what Evidence is already available (all through the EProcedure Portal). With he help of the Information Desk the required cross-border evidence is determined and the relevant routing information is looked up. Next the Evidence can be requested, the request message is encrypted and digitally signed using the Trust Architecture and exchanges using Data Logistics.

The user is forwarded to the DP (see image below). On return of the user there are two possible outcomes: either the OOP evidence is not available or the evidence was received by the DC (exchanged by Data Logistics). In both cases the evidence status is updated (through Evidence Interchange Management).

Assuming the happy flow the signature of the received message is validated and the message decrypted (Trust Architecture). Via EProcedure Portal the evidence is evaluated and if all is well the public service can be provided to the user.

The diagram below shows how the Data Provider process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.

Figure: Process Realization of the Data Provider Process

The Evidence request is received via Data Logistics and with the help of Trust Architecture the DP checks the signature of the request message and decrypts it. The DP generates a persistent URL (Evidence Portal) for user redirection (from DC to DP). Once the user arrives at DP he has to reauthenticate himself using Trust Architecture. If needed additional information is needed in order to establish the user's identity. If authentication fails the non-availability of OOP is communicated to the user via the Evidence Portal.

If successful the evidence is looked up in the registry (Evidence Retrieval) and transformed to cannonical format (Evidence Portal). The evidence might need to be digitised which is communicated as non-availability or delay of the evidence (Evidence Portal). The Evidence Portal also takes care of preparing the preview of the evidence. If successful (the user consents to the transfer) the evidence send as an encrypted and signed message (Data Logistics and Trust Architecture respectively) .