Title:My Technical Specification title containing a break<br>and continueing in next line
Title:Considerations for using portals to support requests from <br>Authorized Organisations
Spec Number:TS-0000
Spec Number:TR 104 196
Version:v0.0.0
Version:v0.6.0
Date:2025-11
Date:2025-11
Work Item:TC/WI-Number
keywords:Markdown, Gitlab
keywords:Markdown, Gitlab
Copyright Year:2025
Copyright Year:2025
Long ISG Name:Technical Committee
Long ISG Name:Technical Committee Lawful Interception
Short ISG Name:TC
Short ISG Name:TC LI
---
---
<!--- Table of contents will be inserted by Pandoc when generating the DOCX specification
<!--- Table of contents will be inserted by Pandoc when generating the DOCX specification
@@ -34,7 +33,7 @@ The present document may include trademarks and/or tradenames which are asserted
**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.
**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.
# Foreword
# Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group <long ISGname> (<short ISGname>).
This Technical Report (GR) has been produced by ETSI Technical Committee for Lawful Interception (TC LI).
# Modal verbs terminology
# Modal verbs terminology
@@ -44,13 +43,10 @@ In the present document \"**should**\", \"**should not**\", \"**may**\", \"**nee
\"**must**\" and \"**must not**\" are **NOT** allowed in ETSI deliverables except when used in direct citation.
\"**must**\" and \"**must not**\" are **NOT** allowed in ETSI deliverables except when used in direct citation.
# Executive summary
# Introduction
# 1 Scope
# 1 Scope
This is the scope
The present document describes considerations for situations in which providers choose to adopt web-based portal solutions to respond to requests from Authorized Organizations. The present document defines portals and explains how existing ETSI TC LI specifications can be used to improve portal design. The present document shows how portals can become a stepping stone towards adoption of interfaces defined by an ETSI TC LI Technical Specification. The present document highlights some caveats around portals and makes it clear that portals are not a substitute for meeting ETSI TC LI Technical Specifications.
# 2 References
# 2 References
@@ -59,9 +55,8 @@ This is the scope
Normative references are not applicable in the present document.
Normative references are not applicable in the present document.
<spanid="_ref_1"></span><aname="_ref_1">[1]</a> [My normative reference to a Google](https://www.google.es/): \"That is Google site\".
## 2.2 Informative references
## 2.2 Informative references - not done
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
@@ -73,206 +68,196 @@ The following referenced documents may be useful in implementing an ETSI deliver
# 3 Definition of terms, symbols and abbreviations
# 3 Definition of terms, symbols and abbreviations
## 3.1 Terms
## 3.1 Terms - not done
For the purposes of the present document, the [following] terms [given in ... and the following] apply:
For the purposes of the present document, the [following] terms [given in ... and the following] apply:
## 3.2 Symbols
## 3.2 Symbols - not done
For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
## 3.3 Abbreviations
## 3.3 Abbreviations - done
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
`ETSI European Telecommunications Standards Institute`
# 4 Examples
`AO Authorized Organization`
This is to define an example:
`API Application Programming Interface`
> EXAMPLE: This is my example
`RPS Request Processing System`
# 5 Notes
This is to define a note:
> NOTE: This is my note
# 4 Core concepts
# 6 Figures
## 4.1 Goal
This is to insert a figure:
The goal of the present document is to help people to adopt ETSI TC LI Technical Specifications i.e. full computer-to-computer API (Application Programming Interface). It is acknowledged that initially people might not be able to move to a full computer-to-computer system, and so portals can be a useful stepping stone. The present document aims to assist with the design of portal solutions, and in the longer term to facilitate the move towards adoption of ETSI TC LI Technical Specifications. The present document is neither encouraging nor discouraging the use of portals alongside an API system for the long term. Further details are given in clause 4.6.
<!---Figure caption needs to be duplicated, first occurrence for Pandoc, second for Gitlab rendering-->
## 4.2 Definition of a portal
A portal is defined to be a website hosted by the provider which allows an Authorized Organization to type in requests and then receive results either through the website or delivered over other channels (not specified here).
**Figure 6-1: This is the figure caption**
## 4.3 Caveat
# 7 Tables
Adoption of the present document does not imply that a system is compliant with any ETSI TC LI Technical Specification; it is not a substitute for compliance with other ETSI TC LI standards.
## 7.1 Pipe tables
This is a pipe-table:
## 4.4 Reference design
**Table 7.1-1: Pipe table**
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.
|C1 |C2 |C3 |C4 |
|-|-|-|-|
|Row 1 C1 |Row 1 C2 |Row 1 C3 |Row 1 C4 |
|Row 2 C1 |Row 2 C2 |Row 2 C3 |Row 2 C4 |
|Row 3 C1 |Row 3 C2 |Row 3 C3 |Row 3 C4 |
|Row 4 C1 |Row 4 C2 |Row 4 C3 |Row 4 C4 |
|Row 5 C1 |Row 5 C2 |Row 5 C3 |Row 5 C4 |
## 7.2 Grid tables
**Figure 4.4-1: Approach to portal design**
This is a grid table:
<!---Grid tables allow merged cells. They are rendered by Pandoc as well as Gitlab, not Web IDE preview-->
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:
| C1 | C2 |
- The portal needs a User Interface design; the API needs to terminate API connections.
The functionality in the larger box (labelled Request Processing System in Figure 4.4-1) would typically be created once and could be accessed via both the portal and API solutions. It would typically include:
- Single workflow engine: each request follows the same path regardless of whether it came from the portal or API.
- Single way to submit query into the provider database.
- Single way to create the results (meaning that the results are identical whether requested through a portal or through a API)
- Single approach to supplying integrity information such as hashing (e.g. see also ETSI TS 103 307 [i.3])
- Single audit log.
This is an unnumbered list:
- List item 1
## 4.5 Use of portals alongside systems with full APIs
- List item 2
- List item 3
- ...
This is another unnumbered list:
* List item 1
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.
* List item 2
Considerations around offering both an ETSI-compliant API and a portal (designed in line with the present document):
* List item 3
- 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.
* ...
This is another unnumbered list:
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 onboarding process is harder for smaller AOs, which can introduce a higher barrier to entry.
+ List item 1
+ List item 2
+ List item 3
+ ...
## 8.2 List numbered
## 4.6 Security
This is a numbered list:
### 4.6.1 General
The present document does not contain a full analysis of portal security but identifies some risks and issues to consider.
1. List item 1
1. List item 2
1. List item 3
1. ...
This is another way of numbered list:
### 4.6.2 Clear boundaries of responsibility
1. List item 1
> EDITOR'S NOTE: All the text in 4.6.2 is new
2. List item 2
3. List item 3
4. ...
# 9 Code blocks
This is to write code blocks:
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?)
<html>
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?)
<head>
</head>
</html>
<br/>
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).
Or:
The Responsible Owners may wish to get suppliers or vendors to build systems which help the Responsible Owner meet their responsibilities, i.e. to perform tasks behind the relevant Front Door. The appropriate legislation determines whether risks or obligations can be transferred to suppliers or vendors (it might be the case that risks and obligations ultimately still sit with the Responsible Owner). The Responsible Owners should make sure they know how their obligations are being met. This might include:
- Knowing where their Front Door is and exactly when/why information leaves/enters.
- Factors such as retention periods, user verification, data localisation (where is data stored) should be clearly understood by the 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.
- 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.3 Management of users
> EDITOR'S NOTE: The text "It is recommended" onwards is new
An important issue for portals is that the provider is responsible for management of the list of accredited users.
In general, for a portal solution, the provider would be responsible for managing risks arising when users join or leave the Authorized Organization (AO), or where privileges are revoked. Verification of new AO users can be difficult with risks around e-mail spoofing. It is recommended to use a range of techniques (beyond looking at the email domain) in order to build confidence in AO users. The Responsible Owner at the Provider (see clause 4.6.2) is responsible for data released by the Provider and therefore this is the person who needs to understand what assurances were received, so they can decide if they are sufficient. Risks can be introduced if particular AO staff are on leave and so need to allocate certain functions to others. The risks are increased if two different AO organisations are involved.
## 4.6.4 Other security points
Standard cyber security risks (e.g. DDoS 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.
<html>
<head>
</head>
</html>
```
# 10 Imports other md files
This is to import other md files:
::include{file=clauses/10.1.md}
# 5 Parts of ETSI TC LI Technical Specifications that are applicable to portal design
## 5.1 List of parts of ETSI TC LI Technical Specifications
# 11 Equations
These are some equations using Latex:
It is recommended that the following parts of an ETSI Technical Specification are used (where appropriate) as part of designing portals.
$\left[\int_{-infty}^{\infty} f(x) \; dx\right]$
1. Fundamental model. The ETSI model has a clear boundary between what is AO-managed and what is provider-managed. There are strong reasons to have clear boundaries of responsibility: it is fundamental to many legal and policy requirements in various jurisdictions.
$\log(x)$
1. Definitions: explaining that terms from the relevant specifications (e.g. ETSI TS 103 120 [i.2], ETSI TS 103 280 [i.4] and ETSI TS 103 976 [i.1]) should be used where suitable.
$\lim_{x \to \infty} f(x)$
1. Identifiers and house-keeping. This would include using provider and AO identifiers.
$\displaystyle \frac{\partial f}{\partial x}$
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 (see item D), it is recommended to use the corresponding response structures (e.g. see ETSI TS 103 976 [i.1]). F) 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.
# 12 References
1. Look at ways that ETSI TC LI data structures (ETSI TS 103 705 [i.5]) can be used to help portal design.
## 12.1 Links to normative and informative references
These are references to a normative reference [\[1\]](#_ref_1) and to an informative reference [\[i.1\]](#_ref_i.1).
User interface design can help support the above points. For example, it would be helpful for a user interface to guide an AO user through the ETSI-defined fields, enforcing the strongly-typed definitions from the very start of the process and using ETSI-defined terminology. It would be helpful for the user interface to guide users through the ETSI-defined workflow.
## 12.2 Links to tables, figures and clauses
TO BE DONE
## 5.2 Use of ETSI TC LI specifications in a vehicles context
# Annex A: Title of annex
### 5.2.1 Explanation
## A.1 First clause
Clause 5.2 contains illustrations of the points listed in clause 5.1 but specifically for a vehicles context.
### A.1.1 First subclause
# Annex B: Title of annex
### 5.2.2 Fundamental Model
This point relates to ensuring that the boundaries of responsibility are clearly demarcated. The following transitions should be clear to all parties:
- The point when the AO submits a request (i.e. an obligation is created on the provider). The AO user should be asked to confirm the submission of a request (with clarity about where the request will be sent).
- The point when the response is delivered (the end of the obligation on the provider).
## B.1 First clause of the annex
It is helpful for everyone to be able to see and understand which stage of the workflow (described in clause 5.2.7) is in progress.
### B.1.1 First subdivided clause of the annex
### 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
# Annex: Bibliography
### 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.
# Annex : Change history
### 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.
### 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.
### 5.2.7 Workflow
It is recommended to follow the steps in ETSI TS 103 120 [i.2] clause H.2.4. The benefit is that it is clear at all items who is supported to be responding next.
### 5.2.8 Use of ETSI TC LI data structures
No additional comments on this topic are made in the present document.
