---
title: "ETSI TS 103 120: warrant information interface"
chapter: "07"
---

# ETSI TS 103 120: warrant information interface

ETSI TS 103 120 specifies an electronic interface for warrant-related information between an authorized organization and a communications provider. It supports structured establishment and management of authorized actions. The standard improves interoperability; it does not validate the law or replace national approval.

> **Safety boundary:** this chapter teaches lawful, governed system design from
> public standards. It does not provide operational targeting, activation,
> decryption, surveillance-evasion, or covert collection instructions.

## The mental model

| Concept | Plain meaning | Control that must travel with it |
|---|---|---|
| **Structured warrant information** | Machine-readable administrative data for controlled processing | The signed legal source remains authoritative |
| **Object lifecycle** | Creation, modification, cancellation, and status can be represented | Only permitted transitions are accepted |
| **Tasking information** | Bounded technical scope derived from authority | Translation must be independently checked |
| **Acknowledgement/status** | Makes processing outcome visible | Avoid revealing provider internals or target data unnecessarily |
| **National extensions** | Jurisdiction-specific parameters where standardized | Version and interpretation need bilateral agreement |
| **Schema validation** | Rejects malformed or incompatible messages | Syntactic validity is not legal validity |

## Apply it as a controlled workflow

1. Pin the published TS 103 120 edition and the applicable national profile.
2. Validate transport peer, message signature, schema, freshness, and replay protection.
3. Perform legal and authority validation outside the wire parser.
4. Map the accepted object into a controlled case lifecycle.
5. Return bounded status without leaking sensitive topology.
6. Audit amendments, cancellations, and conflicts against the original authority.

## Evidence to demand

- Interoperability tests cover create, amend, reject, revoke, duplicate, and expired cases.
- A schema-valid but unauthorized request is denied before provisioning.
- Message and case identifiers remain stable across retries.
- National extensions are documented, tested, and rejected when unknown.

## Failure to reason about

An incoming object is perfectly valid XML or ASN.1 but names an issuing body outside the configured authority set. The parser succeeded; the request must still stop. Conformance and authorization are separate controls.

## Feynman check

TS 103 120 gives two trusted offices a common form and envelope. It does not decide whether the person filling the form has legal permission.