Update file 104196.md

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

### 4.6.2	Clear boundaries of responsibility

> EDITOR'S NOTE: All the text in 4.6.2 is new

### 4.6.2	Clear boundaries of responsibility (!all new text!)

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?)

-	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 

### 4.6.3	Management of users (!mainly new text!)

> 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 

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

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.

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

1. Look at ways that ETSI TC LI data structures (ETSI TS 103 705 [i.5]) can be used to help portal design.  

| Date       | Version | Information about changes |

|------------|---------|---------------------------|

|Dec 2025    |  0.6.1  | Version discussed on 2025-12-16 |

|            |         |                           |

|            |         |                           |

|December 2025    |  0.6.0  | Version uploaded for discussion on 2025-12-16 |

|December 2025    |  0.6.1  | Version at end of discussion on 2025-12-16 |

|            |         |                           |