My ETSI TS 103 120 Notes
Find and download ETSI standards here
My notes on ETSI TS 103 120 document titled Lawful Interception (LI); Interface for warrant information.
103 120 Scope
ETSI TS 103 120 document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception. Typically this interface would be used between: on one side, a Communications Service Provider; and, on the other side, a Government or Law Enforcement Agency who is entitled to request a lawful action.
The ETSI reference model for LI (ETSI TS 102 232-1) defines three interfaces between law enforcement and CSPs, called HI-1, HI-2 and HI-3. The protocol defined in 103 120 document is designed to provide a large part of the functionality for HI-1. It is not designed to be used for HI-2 (delivery of intercept related information) or HI-3 (delivery of communications content). The protocol designed in 103 120 document may also be used for interfaces which require structured exchange of information relating to the establishment and management of Lawful Interception. The general view is that the HI-1 concept can also be used for other legal actions than LI. For that reason the present document could, besides LI, also be applied for retained data requests, seized data requests, data preservation orders and other similar legal requests
See specification for full details.
6. Message Structure
See 6.1 overview for details.
Each message consists of two parts:
- Message Header
- Message Payload (Request | Response)
Request format:
Message > Header > Request Payload > Action Request (one to many) > (GET | CREATE | UPDATE | LIST) > (Object Identifier, Object)
Response format:
Message > Header > Response Payload > Action Response (one to many) > (GET | CREATE | UPDATE | LIST) Response > (Object Identifier, Object)
Top level container for all HI-1 message
Header contains routing and timestamp information - see clause6.2
Payloads contain multiple Actions (either Requests or Responses) - see clause 6.3
Each Action has a Verb such as GET or CREATE – either a request or a response, depending on the message. See clauses 6.4.5 through 6.4.8.
This generally contains an Object Identifier, which identifies the Object being acted on (see clause 7 and clause 8). Depending on the verb. It may also contain an Object.
There may be many Action Requests in a Request message. Each will generally act on a separate message.
In the response, there should be an Action Response for each Action Request (in the absence of errors)
6.2.2. Structure
Table 6.1 shows the structure of every valid MessageHeader within an HI-1 message.
| Field | Format | Description |
|---|---|---|
| SenderIdentifier | EndpointID (see clause 6.2.4 for details) | Nationally unique identifier and country code, sufficient to uniquely identify the Sender node in the message exchange. See clause 6.2.4 for details. |
| ReceiverIdentifier | EndpointID (see clause 6.2.4 for details) | Nationally unique identifier and country code, sufficient to uniquely identify the intended Receiver in the message exchange. See clause 6.2.4 for details. |
| TransactionIdentifier | UUID (see ETSI TS 103 280 [7]) in IETF RFC 4122 [3] canonical form | Identifier that uniquely identifies the message exchange between a given Sender and Receiver. See clause 6.2.5 for details. |
| Timestamp | QualifiedMicrosecondDateTime (see ETSI TS 103 280) | Timestamp indicating the time the message was sent. |
| Version | Version (see clause 6.2.3 for details) | Version of the present document and relevant national profile used for interpreting the message. |
6.4.1 Overview
Clause 6.4 defines a set of verbs to aid the two parties in creating, updating, exchanging and reporting on the HI-1 Objects. It does not dictate business processes that vary nationally.
6.4.2 Action Requests
Each Action Request in the Request Payload shall be assigned an Action Identifier (see clause 6.4.4). Each Action Request appears in ascending order of the Action Identifier.
An Action Request shall be one of the following "verbs".
| Verb | Description | Definition |
|---|---|---|
| GET | Retrieve HI-1 Object | See clause 6.4.5 |
| CREATE | Create new HI-1 Object | See clause 6.4.6 |
| UPDATE | Update existing HI-1 Object | See clause 6.4.7 |
| LIST | List identifiers of HI-1 Objects | See clause 6.4.8 |
| DELIVER | Deliver an HI-1 Object | See clause 6.4.10 |
The list of verbs is deliberately limited, as they are not intended to describe the business processes. Such higher level processes should instead be represented by the state of the relevant HI-1 Object. The present document simply provides a mechanism for transferring objects between participants in the process.
6.4.3 Action Responses
A response message sent from a Receiver to a Sender describes the legibility of the Request message received. An Action Response is generated for each Action Request provided in a Request, providing the Request Message as a whole could be understood. Each Action Response contains an Action Identifier that correlates with the Action Identifier provided in the Request. For the avoidance of doubt, in the case of a DELIVER Response, the Action Identifier shall match the one given in the DELIVER Request, and not any associated with the creation of related objects.
An Action Response shall be one of the following "verbs".
| Verb | Description | Definition |
|---|---|---|
| GET RESPONSE | Successful retrieval of HI-1 Object of given identifier in Action Request. | See clause 6.4.5 |
| CREATE RESPONSE | Receipt of legible Create Request of given identifier in Action Request. | See clause 6.4.6 |
| UPDATE RESPONSE | Receipt of legible Update Request of given identifier in Action Request. | See clause 6.4.7 |
| LIST RESPONSE | Successful retrieval of identifiers of given type from Action Request. | See clause 6.4.8 |
| ERROR INFORMATION | Action Request could not be successfully processed. On receipt of this, the Sender shall regard the Action Request as not having been processed. | See clause 6.4.9 |
| DELIVER RESPONSE | Successful receipt of an HI-1 Object. | See clause 6.4.10 |
6.4.5 GET
See spec.
6.4.6 CREATE
A CREATE Request represents a request for the Receiver to create a new HI-1 Object.
A CREATE Request shall have the following parameters.
| Field | Format | Description | Mandatory? |
|---|---|---|---|
| HI1Object | HI-1 Object | epresentation of the HI-1 Object to be created by the Receiver. | Yes |
The Receiver shall respond to a successful CREATE Request with a CREATE Response with the following parameters.
| Field | Format | Description | Mandatory? |
|---|---|---|---|
| Identifier | Object Identifier (see clause 7.1.2) | Value provided in the CREATE Request. | Yes |
| HI1Object | HI-1 Object | HI-1 Object that is identified by the identifier. | No |
If the Receiver is unable to create an HI-1 Object with the defined identifier, then an Action Error response with an appropriate error code is returned. Unsuccessful creations could be as a result of an already used identifier.
The Receiver may, optionally, return an updated version of the Object as part of the CREATE Response (see table 6.9). This may be useful in situations where the Receiver populates or updates additional fields as part of processing the CREATE request.
The Receiver shall set the Generation of a created Object to 1 (see clause 7.1.3).
8.3 LDTaskObject
8.3.1 Overview
An Lawful Disclosure Task Object (LDTaskObject) represents the state of an LD Task - that is, the act of disclosing information. This corresponds to the WarrantTargetID and WarrantTechSpec elements defined in ETSI TR 103 690. In general, multiple tasks may be authorised by a single warrant.
The LDTaskObject consists of the following fields.
| Field | Format | Description | Reference |
|---|---|---|---|
| Reference | LDID (see ETSI TS 103 280) | LDID assigned to the product of task. | Clause 8.3.2 |
| Status | LDTaskStatus Dictionary Entry. | The current status of the task as determined by the Receiver. | Clause 8.3.3 |
| StatusReason | ActionUnsuccessful structure (see clause 6.4.9). | Optional information for the Receiver to indicate why the Object is in a certain state (such as Invalid or Rejected). Usage for national agreement. | Clause 6.4.9 |
| DesiredStatus | LDTaskDesiredStatus Dictionary Entry. | The current status of the task as specified by the Sender. | Clause 8.3.4 |
| RequestDetails | LDRequestDetails (see clause 8.3.5). | Details regarding the content of the disclosure request, such as identifiers and dates. | Clause 8.3.5 |
| DeliveryDetails | List of LDDeliveryDestination structures (see clause 8.3.6). | Destination(s) for the disclosure product. | Clause 8.3.6 |
| ApprovalDetails | ApprovalDetails (see annex E). | Details regarding the approval for this Task, including dates and signatures where appropriate. | Clause 8.2.9 |
| CSPID | EndpointID (see clause 6.2.4). | Describes the CSP required to implement the Task. | Clause 8.2.10 |
| HandlingProfile | LDHandlingProfile (see clause 8.2.11). | A dictionary entry which gives the name of a handling profile that represents a set of configuration information associated with this task. | Clause 8.2.11 |
| Flags | LDTaskFlags (see clause 8.3.7). | A set of flags associated with the Task Object. | Clause 8.3.7 |
| NationalLDTaskingParameters | See annex G. | See annex G. | Annex G |
8.3.2 Reference
The Reference field gives a reference identifier for the Task, for correlation with other processes. For LD, this shall be set to the LDID that will be assigned to the product of the disclosure. Format will be as per ETSI TS 103 280.
8.3.3 Status
The Status field gives the status of the LDTaskObject as determined by the Receiver. A Sender shall not attempt to set the Status as part of a CREATE or UPDATE Request, and a Receiver shall return an Action Unsuccessful Information Response if the Sender attempts to do so.
The Status field provides a key mechanism for mapping the content of the Object to the relevant nationally-defined processes. The rules for evaluating the correct value of the Status field shall be defined in the relevant national profile.
Given as a LDTaskStatus Dictionary Entry. The LDTaskStatus Dictionary is defined in table 8.16 (see annex F for more details on Dictionaries).
| Dictionary Owner | Dictionary Name |
|---|---|
| ETSI | LDTaskStatus. |
| Value | Meaning |
|---|---|
| AwaitingApproval | he Task is still waiting approval from one or more relevant authorities. |
| AwaitingDisclosure | The Task is approved, but is not yet processed by the LD system. |
| Disclosed | The Task has been processed and the product has been disclosed by the LD system. |
| DisclosureNotAvailable | The Task has been processed and the CSP has determined there is no product available to disclosure. |
| Rejected | The Task has been explicitly denied or rejected by one or more relevant authorities. |
| Cancelled | The Task has been permanently cancelled. |
| Error | The Task has not been processed due to a problem with the underlying LD system. |
| Invalid | The Task has not been processed to a problem with the current information populated in the Task Object. |
8.3.4 DesiredStatus
The DesiredStatus field gives the status of the LDTaskObject as determined by the Sender. Given as a LDTaskDesiredStatus Dictionary Entry. The LDTaskDesiredStatus Dictionary is defined in table 8.17 (see annex F for more details on Dictionaries).
| Dictionary Owner | Dictionary Name |
|---|---|
| ETSI | LDTaskDesiredStatus. |
| Value | Meaning |
|---|---|
| AwaitingApproval | The Task is still waiting approval from one or more relevant authorities. |
| AwaitingDisclosure | The Task is approved, but is not yet processed by the LD system. |
| Disclosed | The Task has been processed and the product has been disclosed by the LD system. |
| Rejected | The Task has been explicitly denied or rejected by one or more relevant authorities. |
| Cancelled | The Task has been permanently cancelled. |
8.3.5 RequestDetails
8.3.5.1 Overview
The RequestDetails structure specifies the content of the disclosure request. It consists of the following fields.
| Field | Format | Description |
|---|---|---|
| Type | RequestType (see clause 8.3.5.2). | Specifies the products to be disclosed. |
| StartTime | QualifiedDateTime (see ETSI TS 103 280). | If a date/time range needs to be applied to the request, the StartTime and EndTime shall be provided. |
| EndTime | QualifiedDateTime (see ETSI TS 103 280). | If a date/time range needs to be applied to the request, the StartTime and EndTime shall be provided. |
| ObservedTime | QualifiedDateTime (see ETSI TS 103 280). | If an observed date/time needs to be applied to the request. This field may be used to indicate at which date/time a certain value was observed by the requestor.
If multiple observed dates/times need to be applied to the request, the ObservedTimes field shall be used instead of this field. |
| ObservedTimes | List of QualifiedDateTime (see ETSI TS 103 280). | If multiple observed dates/times all need to be applied to the request. This field may be used to indicate at which dates/times a certain value was observed by the requestor.
This field shall only be used if multiple dates/times need to be applied to the request. |
| RequestValues | List of RequestValue structures (see clause 8.3.5.3). | Specifies the value(s) used to define the disclosure request. |
8.3.5.2 RequestType
Type of disclosure or disclosures to produce using the specified RequestDetails.
Given as a list of RequestType DictionaryEntries. The usage and meaning of the Request Type is likely to be closely coupled to national legislation, as will the permissible combinations of Request Values and Request Types. It is therefore expected that most national profiles will need to define their own extensions to this dictionary.
| Dictionary Owner | Dictionary Name |
|---|---|
| ETSI | RequestType |
As of document V1.11.2 (2022-05) no dictionary entries have been defined for this dictionary.
8.3.5.3 RequestValues
The RequestValues field contains a list of RequestValue structures, which are combined (with ordering and Boolean ANDed together) to identify the requested disclosure. Each RequestValue structure contains the following fields.
| Field | Format | Description |
|---|---|---|
| FormatType | As defined below. | Specifies a Request Value Format (see below) which defines the format for the Request Value fields. See annex C for the list of Request Value Formats defined by ETSI. Other definitions may be managed on a national basis. |
| Value | LongString (see ETSI TS 103 280). | Additional formatting information is given by the Request Value Format. |
The RequestValue Format ID and format descriptions are given in annex C.
The Receiver is responsible for checking that the format of the RequestValue matches the format defined for the Request Value Format Type. If any of the RequestValues are not correctly formatted, the Action should be rejected.
8.3.5.4 FormatType
A RequestValue FormatType uniquely identifies a particular Request Value Format. It can be used to retrieve the correct RequestValue Format definition for a RequestValues structure. It consists of the following fields.
| Field | Format | Description |
|---|---|---|
| FormatOwner | ShortString (see ETSI TS 103 280). | Name of the Owner of the Format definition. See below. |
| FormatName | ShortString (see ETSI TS 103 280). | Uniquely identifies the format definition within the Owner. |
A Format owner is specified by a string value. The following owners are defined by the present document:
- "ETSI": The Format is owned by ETSI, and defined in the present document in annex C.
- A valid ISO 3166-1 alpha-2 country code: The Format is owned and defined by the relevant national authority for the country specified by the country code.
A Format definition shall contain, at a minimum, the following information.
| Field | Format | Description |
|---|---|---|
| FormatOwner | ShortString (see ETSI TS 103 280). | Identifies the Owner of the Format definition. See below. |
| FormatName | ShortString (see ETSI TS 103 280). | Identifies the format, unique within the Format Owner. |
| Description | LongString (see ETSI TS 103 280). | Human-readable description associated with the Format. |
| Format | IEEE POSIX® 1003.1 ERE Regular Expression. | Regular expression defining the permissible contents of the field. If absent, any UTF-8 string is permitted, subject to the length restriction of the field. |
See annex C for the list of Request Value Formats defined by ETSI. Other definitions may be managed on a national basis.
8.3.6 DeliveryDetails
8.3.6.1 Overview
The LDTaskDeliveryDetails field indicates where disclosed product should be delivered.
The LDTaskDeliveryDetails field consists of a list of LDDeliveryDestination structures. Each entry in the list represents a desired destination for product related to the Task.
Limits on the type, number or combinations of LDDeliveryDestination for a given type of Task shall be specified by the relevant national profile.
8.3.6.2 LDDeliveryDestination
The LDDeliveryDestination structure contains the following fields.
| Field | Format | Description |
|---|---|---|
| DeliveryAddress | DeliveryAddress (see clause 8.2.8.3). | The address to which the product for this Task should be delivered. |
| EncryptionDetails | NationalEncryptionDetails. | Details regarding the encryption to be applied to product delivered to this destination. Shall be defined by the relevant national profile. |
| HandoverFormat | LDHandoverFormat DictionaryEntry (see clause 8.3.6.3). | Specifies the handover format to be used. |
| DeliveryProfile | LDDeliveryProfile DictionaryEntry. | A dictionary entry which gives the name of a delivery profile that represents a set of configuration information associated with the destination and delivery of the product from this Task.
If used, the dictionary shall be defined by the relevant national profile. |
| NationalDeliveryParameters | See annex G. | See annex G. |
8.3.6.3 HandoverFormat
The LDHandoverFormat dictionary is defined in table 8.24 (see annex F for more details on Dictionaries).
| Dictionary Owner | Dictionary Name |
|---|---|
| ETSI | LDHandoverFormat. |
| Value | Meaning |
|---|---|
| TS102657 | Handed over in ETSI TS 102 657 format, using HI-B as described in ETSI TS 102 657. |
| EncapsulatedTS102657 | Handed over as ETSI TS 102 657 format, using the DeliveryObject as described in clause 10. |
| TS103120 | Handed over using the DeliveryObject as described in clause 10. |
| TS103707 | Handed over as ETSI TS 103 707 [24], using the DeliveryObject as described in clause 10. |
8.3.7 Flags
The Flags field allows a set of multiple flags to be associated with the LDTaskObject. Each flag is given as a LDTaskFlag Dictionary Entry. If a flag is present in the Flags field, then the meaning given as part of that flag's definition shall be taken to apply.
The LDTaskFlag Dictionary is defined in table 8.25 (see annex F for more details on Dictionaries).
| Dictionary Owner | Dictionary Name |
|---|---|
| ETSI | LDTaskFlag. |
| Value | Meaning |
|---|---|
| IsTest | Indicates that the current Task is for test purposes. This may alter the process or documentation accompanying the authorization. |
| IsEmergency | Indicates if the LD Task was issued under nationally-defined emergency procedures. The circumstances and consequences for setting the field shall be defined by the relevant national profile (see clause B.1.3). |
| IsNonLocal | Indicates that the current Task shall disclose information about a non-local identity. |
| IsLocal | Indicates that the current Task shall disclose information about a local identity. If both the IsNonLocal and IsLocal flag are absent, the identity provided within the Task shall be considered as a local identity unless otherwise agreed. |