ADR-0041: Seal format of ASI results¶
- Status: proposed (waits for Q-32)
- Date: 2026-11-02
- Satisfies: Implementing Regulation (EU) 2025/1569 article 9(4), as replaced by Implementing Regulation (EU) 2026/1735, from January 1, 2027, and S11
- Deliberation: REQ-83, F-80, and demo ICTU/GBO-demo#498, PR #499
- Implemented in: demo grade, with a development certificate:
- The seal in seal.go#L18-L57.
- The seal on successful responses only, in handler.go#L402-L417.
- The header in the contract, in completions.json#L25-L33.
- The validation by the reference QTSP, in qtsp-reference/internal/seal/seal.go.
Context and problem statement¶
From January 1, 2027, every verification result of an ASIP must be signed or sealed. The seal is at least an advanced electronic seal based on a qualified certificate. The certificate belongs to the responsible public sector body or to the designated intermediary (F-80). ETSI TS 119 478 defines no seal on the response (E4).
A QTSP that verifies at several ASIPs must validate every seal in the same way. If each ASIP chooses its own format, every QTSP must implement each format. For this reason, the format is an interface agreement. It is not a choice per ASIP (REQ-83). Q-32 asks who decides the format. This ADR stays proposed until that decision.
Proposed decision¶
The proposal has five parts:
- The ASIP seals the exact response body with a detached JWS (RFC 7515,
Appendix F). The JWS goes in the header
X-JWS-Signature(<protected header>..<signature>). - The algorithm is ES256. The protected header carries the certificate
chain in
x5c, leaf first. - The body stays plain JSON, as the ETSI OpenAPI prescribes. The contract of the data service names the header as an addition.
- The ASIP seals every successful verify and retrieve response (200). An error response is not a verification result and gets no seal.
- The QTSP validates the signature over the received body, and the chain against its trust anchors. The QTSP does not accept a result without a valid seal.
Consequences¶
- With only the response and the trusted lists, the QTSP can establish that the response comes unchanged from this ASIP.
- The format works with any HTTP client. It leaves the ETSI response schema unchanged.
- The demo seals with a development certificate. Production needs a
qualified certificate for electronic seals (Implementing Regulation
(EU) 2025/1943, Annex II). The certificate has the registration number
of the organization as
organizationIdentifier. - It is open who holds that certificate: the bronhouder, or the designated intermediary (Q-17, Q-28).
Considered options¶
- A detached JWS in a header (proposed). It is simple for a JSON API. The body stays as ETSI specifies.
- A JAdES baseline signature (ETSI TS 119 182-1). This is the EU format for JSON signatures, with the signing time and the certificate references in the header. It is more work for the QTSP and the ASIP, but it is closer to the eIDAS ecosystem.
- An enveloping JWS, with the result as the JWS payload. This option changes the response form that the ETSI OpenAPI prescribes.
Open points¶
These points are open:
- Who decides the format for all Dutch ASIPs, and does ETSI ESI add it to TS 119 478 (Q-32, E4)?
- Does every source response get one seal, regardless of the channel (DvTP, EUDI, ASI) (Q-75)?