Update file TR_104196.md

---

Title: Considerations for using portals to support requests from <br>Authorized Organisations

Spec Number: 104 196

Version: v0.6.1

Version: v0.6.2

Date: 2025-12

keywords: Lawful Disclosure, Lawful Interception, Security requirements

Copyright Year: 2025

## 4.4 Reference design

The approach in Figure 4.4-1 is recommended. The key point is to run one system with two front ends (one for meeting an ETSI Technical Specification, and one for a portal). The goal is to make the front end systems as thin as possible i.e. to put most of the functionality in the main Request Processing System. 

The approach in figure 4.4-1 is recommended. The key point is to run one system with two front ends (one for meeting an ETSI Technical Specification, and one for a portal). The goal is to make the front end systems as thin as possible i.e. to put most of the functionality in the main Request Processing System. 

![A picture showing the reference design](fig441.png)

**Figure 4.4-1: Approach to portal design**

The design in Figure 4.4-1 is not a strict architecture or design and is not intended to constrain data flows or security boundaries. 

The design in figure 4.4-1 is not a strict architecture or design and is not intended to constrain data flows or security boundaries. 

The functionality in the smaller boxes (labelled front end in Figure 4.4-1) is likely to be different between APIs and portals. This would typically include the following:

The functionality in the smaller boxes (labelled front end in figure 4.4-1) is likely to be different between APIs and portals. This would typically include the following:

-	The portal needs a User Interface design; the API needs to terminate API connections. 

-	The security is different (see clause 4.6).  

It is clear that the full API is the best long-term solution for high volume uses, but the present document does not advise in favour or against running portals alongside an API solution. Clause 4.5 notes some benefits and drawbacks of doing this, in order to help people make decisions about use of portals.

Considerations around offering both an ETSI-compliant API and a portal (designed in line with the present document): 

-	It is credible to state that this is a solution that can meet the needs of any AO globally. If the AO has a high volume of requests, they can use the ETSI-compliant API (designed to meet a wide range of requirements and agreed by a broad community). If an AO has a low volume of requests, or does not want to build a ETSI solution, then they can use the provider portal. With an API and a portal (producing identical results, from the same underlying system), there is considerable credibility to a statement that no other solution needs to be offered or will be offered by the provider.  

-	It is credible to state that this is a solution that can meet the needs of any AO globally. If the AO has a high volume of requests, they can use the ETSI-compliant API (designed to meet a wide range of requirements and agreed by a broad community). If an AO has a low volume of requests, or does not want to build a ETSI solution, then they can use the provider portal. With an API and a portal (producing identical results, from the same underlying system), it is realistic to state that no other solution needs to be offered or will be offered by the provider.  

Considerations around offering an API (without a portal): 

-	If a provider offers an API, then it would incur some extra cost to build a portal as well. The present document is not implying it is a requirement to build portals in addition to APIs; in some scenarios the extra expense of a portal might not be justified.

-	The security will be easier without portal access, because then the user management issues (which users are allowed to access the system) are taken care of by the AO. Further details are given in clause 4.6. 

-	The security will be easier without portal access, because then the user management issues (i.e. which users are allowed to access the system) are taken care of by the AO. Further details are given in clause 4.6. 

-	The onboarding process is harder for smaller AOs, which can introduce a higher barrier to entry.

## 4.6 Security

### 4.6.1 General

The present document does not contain a full analysis of portal security but identifies some risks and issues to consider. 

The present document does not contain a full analysis of portal security, instead it identifies some risks and issues to consider. 

### 4.6.2 Clear boundaries of responsibility

The Responsible Owner at an AO is the person who takes responsibility for a request that is issued (Was it lawful? Was it correct? Did it go to the right place? Can I justify it?)

The Responsible Owner at a Provider is the person who takes responsibility for how the request is handled (Did I check it was correct and authorised? Was it lawful to release this data? Can I justify it?)

The Responsible Owner at a Provider is the person who takes responsibility for how the request is handled (Did I check it was correct and authorized? Was it lawful to release this data? Can I justify it?)

In order to meet their responsibilities, it is important for a Responsible Owner to understand exactly where their responsibility starts and ends. This point will be called the Front Door.  The AO Front Door is the point where a request is issued (under the authority of the AO Responsible Owner). The Provider Front Door is the point where a Provider issues the results (under the authority of the Provider Responsible Owner).

Care should taken about functionality that sits between the AO Front Door and the Provider Front Door (i.e. is not inside either Front Door). It is likely to be best to minimise any functionality that sits here. It might be unclear who is responsible for anything that is between the Front Doors. The following examples might be relevant:   

-	Having stateful functionality between the Front Doors risks having a different understanding of the status of requests in AO and Provider. The Responsible Owner might have issued a request which they think has reached its destination but it has not, which might carry serious legal consequences. 

-	Having processing between the Front Doors might cause an issue when material is used in court. It also creates a risk of differing understandings of the data at AO and Provider. It introduces the risk of mistakes taking place between one Front Door and the other. 

-	Having storage between the Front Doors could create a data security issue. Who can see the data? Who can access it? Who is responsible for the data if it compromised. Ultimately the Responsible Owner at AO or Provider (or both) will carry various consequences here.

-	Having storage between the Front Doors could create a data security issue. Who can see the data? Who can access it? Who is responsible for the data if compromised. Ultimately the Responsible Owner at AO or Provider (or both) will carry various consequences here.

-	Care should be taken about routeing or proxying between the Front Doors. Basic network-level routeing is often necessary. It is important that the choice of destination for a request was made inside the AO Front Door. Care should be taken about routeing or proxying that could result in requests going to a different place from the Front Door that the Responsible Owner chose. 

-	There are risks about functionality which could be used by more than one AO or Provider. This carries risk of information going to the wrong place, or data being shared with people who are not entitled to see it.

-	Generating requests anywhere other than within the AO runs the risk of the request being unlawful as it might not have been approved and fully understood by the Responsible Owner. 

### 4.6.4	Other security points 

Standard cyber security risks (e.g. Distributed Denial of Service attack) should be considered.  It should be noted that an attack through either front end (see Figure 4.4-1) can affect the central Request Processing System i.e. care should be taken around the security of both front ends.

Standard cyber security risks (e.g. Distributed Denial of Service attack) should be considered.  It should be noted that an attack through either front end (see figure 4.4-1) can affect the central Request Processing System i.e. care should be taken around the security of both front ends.

If a separate results channel is created, it is important to consider the security of this channel too.

1. Identifiers and house-keeping. This would include using provider and AO identifiers. 

1. Request types: For certain situations (e.g. vehicles), there is a clear set of request types (see ETSI TS 103 976 [i.1]). It is recommended that these are used where they are suitable. 

1. Request types: for certain situations (e.g. vehicles), there is a clear set of request types (see ETSI TS 103 976 [i.1]). It is recommended that these are used where they are suitable. 

1. Results: Where a standardised request type has been used (as described in the point about request types), it is recommended to use the corresponding response structures (e.g. see ETSI TS 103 976 [i.1]). F)

1. Results: where a standardised request type has been used (as described in the point about request types), it is recommended to use the corresponding response structures (e.g. see ETSI TS 103 976 [i.1]).

1. Workflow: it is recommended to follow the Workflow steps from an ETSI TS (mostly this is defined in ETSI TS 103 120 [i.2] e.g. see the Simple Workflow in Annex H.2). This gives a structure for when results are delivered and when error responses are sent etc.

### 5.2.1 Explanation

Clause 5.2 contains illustrations of the points listed in clause 5.1 but specifically for a vehicles context.  

Clause 5.2 contains illustrations of the points listed in clause 5.1, specifically for a vehicles context.  

### 5.2.2 Fundamental Model 

### 5.2.3 Definitions

For vehicles, it is recommended to use the standardised definitions for these concepts (and others where appropriate): 

-	VIN

-	Location

-	Time and date

-	IMSI and IMEI

-	VIN.

-	Location.

-	Time and date.

-	IMSI and IMEI.

### 5.2.4 Identifiers

It is helpful to have a clear system of identifiers for every party (AO or provider). It is useful to have a unique name for each organisation to prevent confusion. For example, the AOs involve should work together to ensure that they do not re-use common acronyms. It is out of scope to describe personal details for any individuals on either side of the interface.

It is helpful to have a unique reference number for each request that is made. There are different ways to create the reference number (either the AO creates it, or the provider does). For a portal it is recommended that there is an option for the AO to include a reference number as it submits the request. The provider is responsible for creating a unique request number (unique within that provider). The provider may use the AO reference number in their request numbering. 

### 5.2.5 Request types 

It is recommended that a portal uses any of the request types from ETSI TS 103 976 [i.1] clause 7 that are appropriate. 

It is recommended that a portal uses any of the request types from ETSI TS 103 976 [i.1] (clause 7) that are appropriate. 

### 5.2.6 Results 

Wherever one of the ETSI TS 103 976 [i.1] request types has been used, it is recommended to use the accompanying results format.