Update file TR_104196.md

## 4.1 Goal

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.

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.5.

## 4.2 Definition of a portal

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. 

## 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. 

**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 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).  

-	Single approach to supplying integrity information such as hashing (e.g. see also ETSI TS 103 307 [i.3])

-	Single audit log. 

## 4.5 Use of portals alongside systems with full APIs

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.  

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.

### 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.

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.