Ga naar inhoud

ADR-0037: Authentic Source Interface as an OAuth front door per ETSI TS 119 478 clause 6.1

Context and problem statement

Article 45e of eIDAS lets a qualified trust service provider (QTSP) verify attributes of a citizen at an authentic source. The QTSP does this at the request of that citizen. ETSI TS 119 478 V1.1.1 specifies the interfaces.

Two regulations make clause 6.1.1 (verify) the legal interface: article 9 of Implementing Regulation 2025/1569, and Annex IV of Implementing Regulation 2026/1735. From January 1, 2027, every verification result must be sealed (article 9(4)). The regulations do not designate clause 6.1.3 (authorization) or clause 5 (discovery). For this reason, the design of the authorization part is a national choice (F-80).

The reference architecture placed the interface "in front of" the FSC and PEP-PDP chain (ADR-0029). The demo showed that this placement is not correct. A QTSP is an EU party with an access certificate and a register entitlement. A QTSP has no FSC peer, no OIN, and no PKIoverheid certificate (F-87). GBO needs two parts:

  • A trust model for the QTSP and the citizen that ends before FSC.
  • A chain behind that trust model that a source can judge like any other consumer.

Decision

GBO offers the Authentic Source Interface as an OAuth front door with its own trust model. The generic chain starts behind it. The front door works as follows:

  1. Interface. The Authentic Source Interface Provider (ASIP) offers clause 6.1 only: 6.1.1 verify, 6.1.2 retrieve, and 6.1.3 authorization with the scopes verify and retrieve. The ASIP does not offer clause 6.2 (ISO 15000) (REQ-112, Q-64). Each authentic source gets its own data service under /<data service>/authsrc-api (ADR-0038).
  2. Two services with separate keys. The ASIP and the authorization server are separate services. The ASIP gets the token keys of the authorization server from its RFC 8414 metadata.
  3. The QTSP is an OAuth client. It is not an FSC participant. QTSP admission is not a PDP rule. The authorization server admits a QTSP as follows (REQ-88, REQ-89):
    • The QTSP registers through RFC 7591. The QTSP seals the software statement with its certificate (x5c, registryURI).
    • The server verifies the chain against its trust anchors.
    • Then the server looks up the register entry. The entry must carry the entitlement QEAA_Provider and the organizationIdentifier of the certificate.
    • The client key is the certificate key.
    • The server repeats the lookup periodically. It deactivates a client without entitlement.
  4. Login is approval. Before login, the citizen sees one request page (REQ-91). The page shows the legal name of the QTSP from the register, the operation, the source, and the attributes, if they are bound. The citizen approves by logging in, or refuses without login (REQ-90). The approval is one login per request: it is not a stored consent, and it has no relation to the consent register (toestemmingsregister). Approval in a wallet is not a legal basis (F-83).
  5. Token. The authorization server uses the authorization code flow with PKCE S256 and private_key_jwt. It issues a DPoP-bound RFC 9068 JWT (ES256, 10 minutes). The token carries the identification data and the means used (acr, amr) (REQ-86). The resource parameter names exactly one data service (REQ-95). As an option, the token is bound to the attributes (ADR-0042).
  6. The ASIP takes the citizen only from the token. The ASIP verifies the token and the DPoP proof before anything else (REQ-87). Then the ASIP sends one GraphQL query per request through its own FSC Outway, as peer …1200 (REQ-92, REQ-46). The PDP of the source sees the ASIP as actor, and never the QTSP or the citizen. Rule ASI0001 grants the ASIP peer the fields behind the attributes, on service brp only.
  7. Results. Per attribute, the ASIP answers Match, NoMatch, MatchWithVariation, or Unknown:
    • A verify response contains no source value (REQ-85).
    • Unknown means only that the source has no complete value (REQ-84).
    • If the chain does not answer, the result is 503 or 500, and never Unknown (REQ-93).
    • If a retrieve finds no value, the result is 404, with no partial result (REQ-101).
    • If a request has mandate, the result is 501 (REQ-114).
  8. Seal. The ASIP seals every successful response (REQ-83). ADR-0041 sets the format.
  9. Discovery. The ASIP publishes a dataService record per attribute and data service. The contract of the data service names the metadata of the authorization server (REQ-99, REQ-100).
  10. Conformance. A conformance matrix gives every ETSI requirement ID a status and named tests. If an ID or a test is missing, CI fails.

Consequences

  • The ASIP is a channel adapter in the sense of REQ-44. The source decides with its own PDP. The source needs no ASI-specific logic.
  • The source sees only the ASIP. The ASIP passes nothing about the QTSP into the chain, and it writes no LDV record. A citizen cannot see which QTSP verified data (F-87).
  • Rule ASI0001 checks the actor, the service, and the field list. It also checks that the subject is a BSN, and not a placeholder. The rule does not check the token or the QTSP. The BSN is in the PDP input and in the decision log (REQ-60, ADR-0043).
  • EUDI issuance does not replace retrieve, because the QTSP issues the QEAA, and GBO does not.
  • QTSP admission depends on a register and on access certificates that do not exist on November 2, 2026. The demo uses a register file and test certificates (F-85).
  • If a QTSP needs attributes of two sources, it authorizes twice (ADR-0038).
  • The conformance matrix of v0.9.0 has 55 passed, 4 stub, 21 not applicable, and 1 failing. The failing item is REQ-ASIP-6.1.1.1-10-01: fuzzy matching asks for the value, and the ASIP returns none (F-92, Q-29).
  • The route runs locally only. ICTU/GBO-demo#594 tracks a deployment to the simulation environment with an external QTSP.

Considered options

The decision considered four other options:

  • Skip retrieve, as ADR-0029 proposed. Not chosen. A QTSP needs the value to issue a QEAA. The EUDI issuance chain does not replace that, because the QTSP issues the attestation, and GBO does not.
  • Make the QTSP an FSC participant. Not chosen. QTSPs are EU parties with access certificates and register entitlements. Clause 6.1 is HTTPS with OAuth.
  • Admit the QTSP in the PDP of the source (a Trusted List check as a rule). Not chosen. The PDP sees only the FSC actor. Admission belongs where the token is issued.
  • Offer clause 6.2 (ISO 15000) as well. Not in demo v0.9.0: Q-64 holds this point open.

Open points

Security profile of the authorization server

The security profile is open (Q-66). ETSI leaves the profile open and conflicts with FAPI 2.0 on PAR and RS256 (F-84, E8).

The demo uses private_key_jwt and DPoP. It has no mTLS client authentication, no PAR, and no refresh tokens. The authorization server signs with ES256. The ASIP also accepts RS256, because RFC 9068 requires it. security-considerations.md lists the demo choices.

These points of the profile are open:

  • The authorization response has no iss (RFC 9207). A QTSP that uses several ASIPs has no mix-up defense (F-96, E9).
  • Tokens stay valid for up to 10 minutes after the withdrawal of the entitlement (Q-41, E10).
  • If the register is unreachable during a re-check, the client stays active (Q-34).
  • Which identifier links the access certificate to the register entry (Q-35)?

Citizen identification at the authorization server

Citizen identification is open (Q-36). The demo accepts two means:

  • The NL Wallet over OpenID4VP, through the nl-wallet verification_server. It asks only the PID attributes of its registration, and it requires a BSN in urn:eudi:pid:nl:1 (REQ-102). The trusted PID issuers are a fixed list, and not a trusted list. The verifier accepts a PID with an undetermined revocation status.
  • A DigiD mock (stub). DigiD supplies only the BSN (F-88).

These related points are open:

  • The NL PID has no place of birth, but the implementing regulation makes it mandatory (F-94).
  • The BSN is in plain text in the token, so the QTSP can read it (F-86, E7, ICTU/GBO-demo#595).
  • Nothing links the citizen who logs in at the QTSP to the citizen who logs in at the authorization server (F-93, Q-40, E6).
  • The same-device wallet login did not run on a phone in demo v0.9.0 (ICTU/GBO-demo#596).
  • P-05 decides which means are recognized at the correct assurance level.

These points are open:

  • Who designates the ASI intermediary, and what is the role of GBO (Q-28, Q-37)? The PSA decision register holds this point as open decision B-14.
  • What is the legal basis to verify for private QTSPs, and does the ASIP return the value on a match (Q-29)?
  • Who registers the data services in the catalogue of attributes and the Discover Interface, and how does the contract name the authorization server (Q-31, Q-67, Q-39, F-91)?
  • How do requests on behalf of another person work (Q-65)?

Traceability