ADR-0029: Authentic Source Interface per ETSI TS 119 478¶
- Status: superseded by ADR-0037
- Date: 2026-08-24, superseded on 2026-11-02
- Satisfies: eIDAS Article 45e, GO: verification and retrieval service for QTSPs, PSA open decisions: central verification and retrieval service
- Superseded by: ADR-0037
- Deliberation: reference architecture v0.6.2, gap 8 and ASI design (archived and unpublished)
- Implemented in: not implemented in this form. The built route is ADR-0037.
Why superseded¶
The demo built the Authentic Source Interface after this ADR (SL-28). Three core points of this proposal changed:
- Retrieve is implemented. The ASIP offers clause 6.1.2 next to 6.1.1. EUDI issuance does not replace retrieve, because the QTSP issues the QEAA, and GBO does not (REQ-101, REQ-112).
- The QTSP is outside FSC. This proposal saw the ASI as a protocol adapter "in front of" the FSC chain. The ASI is an OAuth front door with its own trust model. The authorization server admits the QTSP, and the PDP does not. The generic chain starts behind the ASIP, which is an FSC peer of its own (F-87).
-
Clause numbers replace the labels I1 to I5. The labels came from the reference architecture:
- I1 is clause 5 (discovery).
- I2 is 6.1.1 (verify).
- I3 is 6.1.2 (retrieve).
- I4 is 6.1.3 (authorization server).
- I5 is citizen identification inside 6.1.3.
The TO uses the ETSI clause numbers and roles.
ADR-0037 records the decision that replaces this ADR. ADR-0038, ADR-0039, ADR-0041, and ADR-0042 record the details. The following sections hold the original proposal as history.
Context and problem statement¶
Article 45e of the amended eIDAS regulation obliges member states to let QTSPs verify attributes against authentic sources at the request of the user. ETSI TS 119 478 specifies the interfaces. Without this interface, QTSPs cannot issue QEAAs based on Dutch government registers.
Proposed decision¶
The proposal builds the ASI provider as a GBO edge service, in the HTTP/OAuth variant:
- Implement I2 (Verify). The service translates verification requests into GraphQL queries over FSC, through the standard PEP-PDP chain, and compares the values.
- Implement I4 and I5: citizen authorization through OAuth, with a wallet or eID.
- Skip I3 (Retrieve), because the EUDI chain covers direct issuance (ADR-0018).
- Register the data services in the EU catalogue of attributes (I1).
Open points¶
The proposal left these points open:
- The PDP policy set for QTSP verification (Trusted List check, citizen authorization, attribute scope).
- The design of the authorization server (I4), and its relation to the consent facility (toestemmingsvoorziening).
- The timeline pressure from the Article 45e deadline. For more information, see Risks and technical debt.