Coverage

The script scripts/gen_traceability.py makes this page from the registers and from the Traceability section of every page. Do not edit this page by hand. After you change a register entry or a Traceability section, run python3 scripts/gen_traceability.py.

Decision chains

Each architecture decision has one row. The row names the requirements that the decision serves and the demo increments that are its evidence. It also names the findings that led to the decision or stay open against it, and the open questions that the decision depends on. An open finding or an open question is in bold.

Decision	Status	Requirements	Demo increments	Findings	Open questions
ADR-0001 GraphQL as the source access interface	accepted	REQ-08, REQ-11, REQ-17	SL-03a, SL-03b	—	Q-11, Q-14
ADR-0002 OPA/Rego in OpenFTV, the FSC Inway as PEP, AuthZEN with the FTV GraphQL profile	accepted	REQ-04, REQ-17, REQ-42, REQ-44	SL-17, SL-18, SL-31, SL-40	F-02, F-27, F-31, F-35	Q-16
ADR-0003 FSC for all domestic connectivity	accepted	REQ-46	SL-34, SL-39, SL-42	—	Q-53
ADR-0004 Five authorization concerns, federated evaluation, no central authorization server	accepted	REQ-04, REQ-18, REQ-46, REQ-48, REQ-74	—	F-02, F-08	Q-02, Q-09, Q-10
ADR-0005 BSNk PP polymorphic pseudonyms for private-sector access	accepted	BSNK-01, BSNK-03, BSNK-04, BSNK-05, BSNK-06, BSNK-09, BSNK-11, REQ-20, REQ-21, REQ-80, REQ-82	SL-02, SL-51	F-15, F-75, F-78	Q-01, Q-26
ADR-0006 Consent register as runtime PIP	superseded by ADR-0007, which ADR-0032 supersedes in turn	REQ-18, REQ-68	SL-08	F-24	Q-05, Q-23
ADR-0007 Consent as a signed token with a live status check	superseded by ADR-0032	REQ-68, REQ-79	SL-23, SL-47, SL-51	F-04, F-44	Q-05
ADR-0008 Service catalog as a data-driven policy ceiling	superseded by ADR-0009	REQ-08, REQ-121	SL-14	F-21, F-23, F-38	—
ADR-0009 Closed-world per-field rules: the rule is the catalog	accepted	REQ-06, REQ-08, REQ-17, REQ-48, REQ-74, REQ-97	SL-03b, SL-13, SL-33	F-21, F-23, F-90	Q-14
ADR-0010 BSN resolution inside the PEP	superseded by ADR-0011, which ADR-0033 supersedes in turn	BSNK-04, REQ-21	SL-02	F-30, F-37	—
ADR-0011 Source-owned sidecar resolves pseudonyms, and the PDP never sees a BSN	superseded by ADR-0033	REQ-21, REQ-60	SL-02, SL-22, SL-29	F-30, F-37, F-54	—
ADR-0012 Query AST inspection with OPA's graphql.parse_query	superseded by ADR-0013	REQ-17	SL-03a	F-25	Q-14
ADR-0013 GraphQL request mapping in the PDP ahead of policy evaluation	accepted	REQ-17, REQ-18, REQ-42, REQ-60	SL-03a, SL-18, SL-31	F-25, F-54	Q-14
ADR-0014 Flow and subject identifier semantics through a provider-side Additional Claims service	superseded by ADR-0030, which ADR-0031 supersedes in turn	REQ-74	SL-48	F-32, F-45, F-62	Q-15
ADR-0015 FSC contract acceptance by policy	accepted	AV-06, REQ-61, REQ-62, REQ-63, REQ-110, REQ-123	SL-09, SL-45	F-52, F-55, F-56	Q-22, Q-53, Q-74
ADR-0016 Source-owned metadata and reconciliation-based onboarding	accepted (mechanism). The document format is a proposal for PSA S10	AV-07, AV-08, REQ-58, REQ-64, REQ-65, REQ-66, REQ-67	SL-46	F-50, F-57, F-58, F-59, F-68, F-71, F-74	Q-17, Q-19, Q-38
ADR-0017 Gbo-simple-v1 as the attestation mapping profile	accepted	REQ-64, REQ-78, REQ-116, REQ-124	SL-46	—	Q-20, Q-38
ADR-0018 EUDI issuance through disclosure-based OpenID4VCI on the nl-wallet stack	accepted	REQ-44, REQ-45, REQ-57, REQ-58, REQ-60, REQ-74, REQ-77	SL-19, SL-25, SL-26, SL-29, SL-43	F-47, F-70, F-82, F-83	Q-14, Q-18
ADR-0019 FSC transaction ID as the end-to-end correlation key	superseded by ADR-0035	REQ-55	SL-07, SL-38	F-39, F-41, F-67	—
ADR-0020 AS4 bridge for SDG-OOTS	accepted (not implemented in gbo-demo v0.9.0)	—	—	—	Q-79
ADR-0021 Policy management and distribution per bronhouder	accepted	REQ-59, RL-01, RL-02, RL-03, RL-04, RL-05	SL-44	F-09, F-51, F-52, F-59	Q-21
ADR-0022 Sector-level grants with organizational attribute verification	deferred	REQ-61, REQ-62	SL-05	F-36, F-56	—
ADR-0023 Organization identity from the certificate, and separate EUDI certificate roles	accepted (part A, organization identity), proposed (part B, EUDI certificate roles)	REQ-46, REQ-58, REQ-67	SL-34a, SL-49	F-60, F-66, F-81	Q-06, Q-07, Q-17, Q-30, Q-68
ADR-0024 Canonical semantic models per bronhouder	proposed	REQ-124	—	—	Q-79
ADR-0025 GraphQL as a recognized FDS data service type	proposed	—	—	—	—
ADR-0026 Each controller logs its own processing in an LDV logbook	accepted	AV-02, REQ-32, REQ-55, REQ-60, REQ-72, REQ-76	SL-50	F-07, F-63, F-64, F-65, F-68, F-69	Q-08, Q-24, Q-25, Q-27, Q-72
ADR-0027 Bronhouder onboarding toolkit	proposed	AV-07, AV-09, BSNK-09, REQ-64, REQ-65	SL-09, SL-46	F-57, F-71	Q-74
ADR-0028 PubEAA Provider productization	proposed	AV-12, AV-13, REQ-45, REQ-58, REQ-77	SL-26	F-66, F-81, F-82	Q-17, Q-28, Q-30, Q-75
ADR-0029 Authentic Source Interface per ETSI TS 119 478	superseded by ADR-0037	REQ-101, REQ-112	SL-28	F-80, F-87	—
ADR-0030 Flow and subject identifier semantics as FSC grant properties	superseded by ADR-0031	REQ-74	SL-24, SL-48	F-32, F-43, F-62, F-70	Q-15
ADR-0031 The authorization regime follows from the evidence a request carries	accepted	REQ-18, REQ-45, REQ-48, REQ-74	SL-24, SL-48	F-32, F-43, F-49, F-62, F-70	Q-15
ADR-0032 The consent proof: signed, a value per source, a placeholder in the query, status online over FSC, verified in policy	accepted	AV-05, BSNK-03, BSNK-04, REQ-14, REQ-18, REQ-19, REQ-20, REQ-21, REQ-68, REQ-75, REQ-76, REQ-79, REQ-80, REQ-82	SL-08, SL-23, SL-47, SL-51	F-44, F-61, F-72, F-76, F-77, F-78	Q-05, Q-13, Q-46, Q-47, Q-55, Q-69
ADR-0033 The source gateway decrypts its own value after the allow, and only the Inway reaches it	accepted	AV-09, BSNK-04, BSNK-07, BSNK-08, BSNK-09, REQ-04, REQ-17, REQ-21, REQ-79, REQ-80, REQ-81	SL-02, SL-22, SL-51	F-06, F-30, F-37, F-79	Q-01
ADR-0034 An integrator connects under FSC delegation, and the consent binds the represented party	accepted	AV-06, REQ-48, REQ-61, REQ-62, REQ-106, REQ-110	—	F-20, F-73	Q-12, Q-46, Q-68
ADR-0035 W3C Trace Context is the correlation key, and the FSC transaction ID is recorded next to it	accepted	AV-01, REQ-55, REQ-71, REQ-72	SL-07, SL-38, SL-50	F-16, F-39, F-40, F-41, F-67	—
ADR-0036 The ADL is the authoritative record of authorization decisions	accepted	REQ-06, REQ-32, REQ-59, REQ-60, REQ-71	SL-04, SL-50	F-07, F-53, F-63, F-72	Q-08, Q-25
ADR-0037 Authentic Source Interface as an OAuth front door per ETSI TS 119 478 clause 6.1	accepted (demo grade)	REQ-44, REQ-46, REQ-60, REQ-83, REQ-84, REQ-85, REQ-86, REQ-87, REQ-88, REQ-89, REQ-90, REQ-91, REQ-92, REQ-93, REQ-99, REQ-100, REQ-101, REQ-102, REQ-112, REQ-114	SL-28	F-80, F-83, F-84, F-85, F-86, F-87, F-88, F-91, F-92, F-93, F-94, F-96	Q-28, Q-29, Q-31, Q-34, Q-35, Q-36, Q-37, Q-39, Q-40, Q-41, Q-64, Q-65, Q-66, Q-67
ADR-0038 One data service per authentic source, one token per data service	accepted	REQ-91, REQ-94, REQ-95, REQ-99	SL-28	F-89	Q-37, Q-67
ADR-0039 ASI attributes described by the source (asi capability in source metadata)	accepted, partly implemented. In demo v0.9.0, the authorization server takes its resour...	REQ-64, REQ-84, REQ-92, REQ-93, REQ-94, REQ-113, REQ-115	SL-28, SL-46	F-57	Q-31, Q-38, Q-70, Q-71
ADR-0040 Citizen recognition and the BSNk participant: route D	proposed (waits for Q-49)	BSNK-01, BSNK-02, BSNK-03, BSNK-10, REQ-20, REQ-23, REQ-24, REQ-40, REQ-69	SL-51	F-75, F-98	Q-26, Q-49, Q-50, Q-56, Q-57, Q-58, Q-63
ADR-0041 Seal format of ASI results	proposed (waits for Q-32)	REQ-83, REQ-94	SL-28	F-80	Q-17, Q-28, Q-32, Q-75
ADR-0042 Optional per-attribute token binding for ASI tokens	proposed (waits for Q-33)	REQ-91, REQ-95, REQ-103	SL-28	F-95	Q-33
ADR-0043 Keep identifiers out of the PDP input instead of masking decision logs	proposed (waits for demo #368)	REQ-20, REQ-60, REQ-71	SL-29	F-54	Q-08

Where each ID is explained

Each register entry has one row. The row names the TO pages and the decisions that explain the entry or depend on it. Open entries that no page cites are in Not explained.

Requirements

ID	Title	Status	Explained in
REQ-04	The source delivers only after a positive decision by its PDP	ready for review	Component catalog, GBO Basis, Building block view, Authorization, ADR-0002, ADR-0004, ADR-0033
REQ-06	A denial carries a machine-readable reason: coarse for the consumer, full for the operator	ready for review	Authorization in GBO Basis, Authorization, ADR-0009, ADR-0036, Introduction and goals, Quality requirements, DvTP: the consumer queries a source under consent, Runtime view
REQ-08	Source access delivers only the fields that the request selects	ready for review	GBO Basis, Generic source access, Authorization, ADR-0001, ADR-0008, ADR-0009, DvTP: the consumer queries a source under consent
REQ-10	Consent covers a whole data set, and the citizen does not pick fields within a set	ready for review	Consent facility, Consent, Glossary, DvTP: the citizen gives consent
REQ-11	A GBO component fetches source data from the source for each request and does not store it	ready for review	Component catalog, Generic source access, ADR-0001, Introduction and goals
REQ-12	A consent is bound to one consumer, one service, and a named data scope	draft	DvTP channel, Consent, DvTP: the citizen gives consent
REQ-14	After revocation, the chain denies every later request on that consent	ready for review	Consent facility, Consent, ADR-0032, Quality requirements, DvTP: the citizen views and revokes consents
REQ-17	The PDP decides on every field that the source runs, and denies an uncertain field list	ready for review	Component catalog, Authorization in GBO Basis, Authorization, Constraints, ADR-0001, ADR-0002, ADR-0009, ADR-0012, ADR-0013, ADR-0033, Introduction and goals, Solution strategy
REQ-18	The PDP decides on facts that it established itself, and never on what the consumer declares	ready for review	Authorization in GBO Basis, Authorization, ADR-0004, ADR-0006, ADR-0013, ADR-0031, ADR-0032, DvTP: the consumer queries a source under consent
REQ-19	A consent has a finite validity, and after that the PDP denies	ready for review	Consent, ADR-0032
REQ-20	In the consent path the consumer gets no BSN in the proof or in the response	draft	DvTP channel, Consent, Pseudonymization, ADR-0005, ADR-0032, ADR-0040, ADR-0043, Introduction and goals, Quality requirements, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent
REQ-21	The source converts the value from the proof itself, only after a positive decision and without a central party	ready for review	Component catalog, DvTP channel, Generic source access, Pseudonymization, Context and scope, ADR-0005, ADR-0010, ADR-0011, ADR-0032, ADR-0033, DvTP: the consumer queries a source under consent, Solution strategy
REQ-23	The consent register gets no BSN, not even temporarily	draft	Consent facility, Pseudonymization, Context and scope, ADR-0040, DvTP: the citizen gives consent
REQ-24	The citizen identity comes from the authentication service assertion at the required assurance level and not from client input	ready for review	Context and scope, ADR-0040, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent
REQ-32	Audit records are protected, complete, and stored apart from operational logs	ready for review	Records: decisions, processing, transport, Logging, audit and traceability, ADR-0026, ADR-0036, Deployment view
REQ-37	A consent request names the consumer, the service, the requested data sets, and the return address	draft	DvTP channel, Context and scope, DvTP: the citizen gives consent
REQ-38	A logged-in citizen can view consents with status and revoke them	draft	Consent, Constraints, DvTP: the citizen views and revokes consents
REQ-39	Only the consent backend can create, query, and revoke the consents of a citizen in the register	draft	Deployment view, Risks and technical debt, DvTP: the citizen views and revokes consents
REQ-40	A citizen sees and revokes only their own consents	draft	Consent, ADR-0040, DvTP: the citizen views and revokes consents
REQ-42	The authorization request follows an open PEP-PDP profile, and the PEP passes the request on unchanged	ready for review	Component catalog, GBO Basis, Authorization, Context and scope, ADR-0002, ADR-0013, DvTP: the consumer queries a source under consent
REQ-44	A channel adapter translates protocol, and the decision on source data lies with the PDP of the source	ready for review	PuB-EAA provider, Building block view, OOTS channel, Authorization, Constraints, ADR-0002, ADR-0018, ADR-0037, Design-level scenarios, EUDI issuance: the PuB-EAA route
REQ-45	The source is queried only about the citizen from a verified PID disclosure	draft	Component catalog, EUDI wallet channel, PuB-EAA provider, Authorization in GBO Basis, Authorization, Identity and trust, Context and scope, ADR-0018, ADR-0028, ADR-0031, Deployment view, Quality requirements, Risks and technical debt, EUDI issuance: the PuB-EAA route
REQ-46	Every channel that calls a source on behalf of an external party does so through FSC, with a valid certificate	ready for review	GBO Basis, Building block view, OOTS channel, Identity and trust, ADR-0003, ADR-0004, ADR-0023, ADR-0037, Deployment view, Design-level scenarios, EUDI issuance: the PuB-EAA route
REQ-48	Every rule checks actor and scope itself, and a request passes only if no check denies	ready for review	Component catalog, Authorization, ADR-0004, ADR-0009, ADR-0031, ADR-0034, Introduction and goals, DvTP: the consumer queries a source under consent
REQ-55	One trace ID per request across the whole chain, and the transaction ID can be linked to it	ready for review	Records: decisions, processing, transport, Logging, audit and traceability, Context and scope, ADR-0019, ADR-0026, ADR-0035, Introduction and goals, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route, Solution strategy
REQ-57	An attestation about someone other than the requester follows an agreed relation from the verified requester	draft	PuB-EAA provider, Generic source access, ADR-0018, EUDI issuance: the PuB-EAA route
REQ-58	Every bronhouder has its own certificate set for issuance, and missing material fails	ready for review	Component catalog, PuB-EAA provider, Source configuration, Identity and trust, Source onboarding, ADR-0016, ADR-0018, ADR-0023, ADR-0028, Deployment view, Quality requirements, Admission and activation, EUDI issuance: the PuB-EAA route
REQ-59	The decision record names the policy version that decided	ready for review	Policy rules and their management, Records: decisions, processing, transport, Logging, audit and traceability, Policy lifecycle, ADR-0021, ADR-0036, Quality requirements, Risks and technical debt, Policy distribution
REQ-60	Logging contains no BSN that the processing does not need	ready for review	ASI provider, EUDI wallet channel, Records: decisions, processing, transport, Generic source access, Logging, audit and traceability, Pseudonymization, ADR-0011, ADR-0013, ADR-0018, ADR-0026, ADR-0036, ADR-0037, ADR-0043, Introduction and goals, Quality requirements, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute, Design-level scenarios, EUDI issuance: the PuB-EAA route, Policy distribution
REQ-61	Admission comes from a register and not from decision policy	ready for review	Component catalog, Authorization in GBO Basis, Authorization, Constraints, Context and scope, ADR-0015, ADR-0022, ADR-0034, Admission and activation, DvTP: the consumer queries a source under consent, Solution strategy
REQ-62	The admission decision on a contract is its own rule set, separate from request policy	ready for review	Component catalog, Authorization in GBO Basis, Policy rules and their management, Authorization, ADR-0015, ADR-0022, ADR-0034, Admission and activation, DvTP: the consumer queries a source under consent, Policy distribution
REQ-63	An automated refusal of a contract proposal is recoverable	draft	Authorization in GBO Basis, Authorization, ADR-0015, Admission and activation
REQ-64	A GBO component works only with the service description the source publishes itself, after validation	ready for review	Component catalog, PuB-EAA provider, Source configuration, Authorization, Source onboarding, Context and scope, ADR-0016, ADR-0017, ADR-0027, ADR-0039, Admission and activation, EUDI issuance: the PuB-EAA route, Solution strategy
REQ-65	Only an explicit management action takes a source into use, and a valid contract is not enough	ready for review	Component catalog, PuB-EAA provider, Source configuration, Source onboarding, ADR-0016, ADR-0027, Admission and activation, EUDI issuance: the PuB-EAA route
REQ-66	Source metadata fails closed per source, ages within bounds, and can be rolled back	ready for review	Component catalog, Source configuration, Policy lifecycle, Source onboarding, ADR-0016, Deployment view, Quality requirements, Admission and activation, EUDI issuance: the PuB-EAA route, Policy distribution
REQ-67	The legal identity of a bronhouder comes from its certificate and not from configuration	draft	Component catalog, Source configuration, Identity and trust, Source onboarding, Constraints, ADR-0016, ADR-0023, Deployment view, Glossary
REQ-68	The PDP decides only on a consent whose origin, binding, and current status it establishes itself	draft	Component catalog, Consent facility, DvTP channel, Authorization, Consent, ADR-0006, ADR-0007, ADR-0032, DvTP: the consumer queries a source under consent, Solution strategy
REQ-69	The consent register stores the polymorphic values under its own reference and no encrypted values per party	ready for review	Component catalog, Pseudonymization, ADR-0040, Deployment view, Quality requirements, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent
REQ-71	Every authorization decision is in an ADL-conformant decision record, and that record is the audit source	ready for review	Component catalog, Records: decisions, processing, transport, Logging, audit and traceability, Context and scope, ADR-0035, ADR-0036, ADR-0043, Deployment view, Quality requirements, Risks and technical debt, Solution strategy
REQ-72	A GBO component that processes personal data writes an LDV log record for each processing at its controller	ready for review	Component catalog, PuB-EAA provider, Records: decisions, processing, transport, Logging, audit and traceability, Context and scope, ADR-0026, ADR-0035, Deployment view, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent, EUDI issuance: the PuB-EAA route, Solution strategy
REQ-74	The authorization regime follows from the evidence a request carries	ready for review	Component catalog, EUDI wallet channel, Authorization in GBO Basis, Building block view, OOTS channel, Authorization, ADR-0004, ADR-0009, ADR-0014, ADR-0018, ADR-0030, ADR-0031, Quality requirements, Risks and technical debt, Design-level scenarios, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route, Runtime view, Solution strategy
REQ-75	Consent status is available within a set propagation time, availability, and latency	draft	Consent facility, Consent, ADR-0032, Deployment view, Quality requirements, Risks and technical debt, DvTP: the citizen views and revokes consents, DvTP: the consumer queries a source under consent
REQ-76	The register gives consent status only to an authenticated, authorized PDP, over FSC, and records who asked	draft	Consent facility, Consent, Logging, audit and traceability, Context and scope, ADR-0026, ADR-0032, Deployment view, Risks and technical debt, DvTP: the consumer queries a source under consent
REQ-77	An attestation gets the validity and revocation policy of the bronhouder	draft	PuB-EAA provider, ADR-0018, ADR-0028, Risks and technical debt, Design-level scenarios, EUDI issuance: the PuB-EAA route
REQ-78	Issuance issues nested claims, with selective disclosure per element as the schema prescribes	draft	PuB-EAA provider, Source onboarding, ADR-0017, EUDI issuance: the PuB-EAA route
REQ-79	Under a consent the subject comes only from the proof	ready for review	Component catalog, DvTP channel, Generic source access, Authorization, Consent, Pseudonymization, Context and scope, ADR-0007, ADR-0032, ADR-0033, Glossary, Introduction and goals, Quality requirements, DvTP: the consumer queries a source under consent
REQ-80	The proof carries a value per party that only that party can read, and the recipient checks that the value is meant for it	ready for review	Component catalog, Consent facility, Generic source access, Consent, Pseudonymization, ADR-0005, ADR-0032, ADR-0033, Quality requirements, DvTP: the citizen gives consent, DvTP: the consumer queries a source under consent, Solution strategy
REQ-81	Only the component that enforces the decision reaches the source gateway	ready for review	Component catalog, GBO Basis, Generic source access, Pseudonymization, Constraints, Context and scope, ADR-0033, Deployment view, Quality requirements, Risks and technical debt, DvTP: the consumer queries a source under consent
REQ-82	When consent is given, the consent facility knows the OIN, the key version, and the BSN authorization of each source	draft	Consent, Pseudonymization, ADR-0005, ADR-0032, DvTP: the citizen gives consent
REQ-83	Every ASIP verification result is sealed	ready for review	Component catalog, ASI provider, Identity and trust, Context and scope, ADR-0037, ADR-0041, Quality requirements, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
REQ-84	Unknown only means the source has no (complete) value	ready for review	ASI provider, ADR-0037, ADR-0039, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-85	The verify response contains no value from the source	draft	ASI provider, ADR-0037, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-86	The access token carries the citizen's identification data and the means used to identify him	ready for review	Component catalog, Context and scope, ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
REQ-87	The ASIP takes the citizen only from a valid token bound to the QTSP that covers the operation	ready for review	ASI provider, ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
REQ-88	Only a QTSP with the QEAA_Provider right in the register becomes a client	ready for review	ASI provider, Identity and trust, Context and scope, ADR-0037, Quality requirements, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
REQ-89	The right of a registered client is re-checked periodically	ready for review	ASI provider, ADR-0037, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-90	The citizen approves the request by logging in, or refuses	ready for review	ASI provider, EUDI wallet channel, Authorization, ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
REQ-91	The citizen sees who asks what at which source before logging in	ready for review	ASI provider, ADR-0037, ADR-0038, ADR-0042, ASI verification: a QTSP verifies or retrieves an attribute
REQ-92	The ASIP asks the source only for the fields of the requested attributes	ready for review	Component catalog, ASI provider, Source onboarding, ADR-0037, ADR-0039, ASI verification: a QTSP verifies or retrieves an attribute
REQ-93	A chain that does not answer is an error, not Unknown	ready for review	ASI provider, Source onboarding, ADR-0037, ADR-0039, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-94	Every ASI response names the one authentic source responsible for it	ready for review	ASI provider, Source onboarding, ADR-0038, ADR-0039, ADR-0041, ASI verification: a QTSP verifies or retrieves an attribute
REQ-95	An access token is valid only for the source the citizen saw	ready for review	ASI provider, ADR-0038, ADR-0042, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-97	Every rule names the FSC services it applies to	ready for review	Component catalog, Authorization in GBO Basis, Authorization, ADR-0009, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route, Solution strategy
REQ-99	The ASIP provides a discovery record for each attribute and data service, with a path to endpoint, contract, and authorization server	draft	Context and scope, ADR-0037, ADR-0038, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-100	A data service contract names its authorization-server metadata at the location RFC 8414 prescribes	draft	Context and scope, ADR-0037, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-101	A retrieve for which the source lacks a requested attribute is not found and gives no partial result	ready for review	ASI provider, ADR-0029, ADR-0037, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-102	The authorization server identifies the citizen with the EUDI wallet through OpenID4VP and asks only the PID attributes in its registration	ready for review	ASI provider, Context and scope, ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
REQ-103	An authorization can be bound to the requested attributes, and the ASIP then processes only those attributes	draft	ADR-0042, Quality requirements, ASI verification: a QTSP verifies or retrieves an attribute
REQ-106	An integrator acts only with a registered mandate, and the consent binds the represented party	ready for review	Component catalog, DvTP channel, Authorization, Consent, Context and scope, ADR-0034, Introduction and goals, Quality requirements, Risks and technical debt, Admission and activation, DvTP: the consumer queries a source under consent, Solution strategy
REQ-107	Consent can be given only after confirmation that the citizen saw the information	ready for review	Consent, DvTP: the citizen gives consent
REQ-108	The citizen can export the overview of consents	ready for review	DvTP: the citizen views and revokes consents
REQ-109	Revocation is possible only for a valid consent	ready for review	Consent, Quality requirements, Risks and technical debt, DvTP: the citizen views and revokes consents
REQ-110	A suspended or departed consumer gets no more data, even with a valid consent	draft	Authorization, ADR-0015, ADR-0034, Quality requirements, Risks and technical debt, Admission and activation, DvTP: the consumer queries a source under consent
REQ-111	What the citizen sees about the consumer, and the return address, come from the registration and not from the request	ready for review	DvTP: the citizen gives consent
REQ-112	The ASIP offers the clause 6.1 interface	draft	ASI provider, EUDI wallet channel, Context and scope, ADR-0029, ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute, Solution strategy
REQ-113	Fuzzy matching only on free text, with documented rules	draft	ASI provider, ADR-0039, ASI verification: a QTSP verifies or retrieves an attribute
REQ-114	A request on behalf of another person gets 501	draft	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
REQ-115	The ASIP verifies attribute fragments	draft	ADR-0039
REQ-116	An attestation contains only what the source answered, per its mapping, and an answer that does not fit gives no attestation	draft	Component catalog, PuB-EAA provider, Source onboarding, ADR-0017, EUDI issuance: the PuB-EAA route
REQ-117	Before choosing, the citizen sees in plain language who asks what, for what, and for how long	draft	Consent, DvTP: the citizen gives consent
REQ-118	If a service excludes delegation, an authorized representative cannot give consent for it	draft	Consent
REQ-119	After every outcome the citizen returns to the consumer with that outcome	draft	DvTP: the citizen gives consent
REQ-120	For every consent and after every revocation, the portal points the citizen to their rights at the consumer	draft	Consent, DvTP: the citizen views and revokes consents
REQ-121	Screen, initiation check, and reference policy follow the same data-set description	draft	Authorization, ADR-0008
REQ-122	The citizen gets a confirmation of their choice	draft	DvTP: the citizen gives consent
REQ-123	Every change to an admission, mandate, or activation is traceable	draft	Component catalog, Source configuration, Authorization, Source onboarding, ADR-0015, Admission and activation
REQ-124	For every attestation, the versions of the mapping, the source schema, and the attestation schema are traceable	draft	OOTS channel, Source onboarding, ADR-0017, ADR-0024, Design-level scenarios, EUDI issuance: the PuB-EAA route

Guidelines

ID	Title	Status	Explained in
RL-01	Deliver policy as a versioned bundle instead of baking it into the PDP	ready for review	Policy rules and their management, Policy lifecycle, Constraints, ADR-0021, Policy distribution
RL-02	Authorize the management API with its own policy set and deny on an empty store	ready for review	Policy rules and their management, Policy lifecycle, ADR-0021, Policy distribution
RL-03	Separate writing from publishing, and publish with a non-personal, short-lived identity	ready for review	Policy rules and their management, Policy lifecycle, ADR-0021, Policy distribution
RL-04	Withdraw policy instead of deleting it, and reconcile the deployed set with version control	ready for review	Policy rules and their management, Policy lifecycle, ADR-0021, Policy distribution
RL-05	Validate a bundle before activation, and fall back visibly to the last valid set	ready for review	Policy rules and their management, Policy lifecycle, Constraints, ADR-0021, Policy distribution

Connection conditions

ID	Title	Status	Explained in
AV-01	Consumer sends trace context and records the transaction ID	candidate	Logging, audit and traceability, Constraints, ADR-0035, DvTP: the consumer queries a source under consent
AV-02	Consumer records its processing according to LDV	candidate	Logging, audit and traceability, ADR-0026
AV-03	Consumer uses the consent facility and BSNk PP	candidate	—
AV-04	Consumer has its own FSC peer with PKIoverheid certificate and OIN	candidate	Identity and trust
AV-05	Consumer sends the consent proof unchanged	candidate	Consent, Context and scope, ADR-0032, DvTP: the consumer queries a source under consent
AV-06	Integrator is admitted separately and acts as processor	candidate	ADR-0015, ADR-0034, Admission and activation, DvTP: the consumer queries a source under consent
AV-07	Bronhouder publishes a machine-readable description for each data service	candidate	Source onboarding, ADR-0016, ADR-0027
AV-08	Bronhouder without its own endpoint provably agrees with a taken-over description	candidate	Source configuration, Source onboarding, ADR-0016, Admission and activation
AV-09	Bronhouder keeps decryption keys of an older version while proofs for that version are valid	candidate	Consent, Pseudonymization, ADR-0027, ADR-0033, Deployment view, DvTP: the consumer queries a source under consent
AV-10	Bronhouder logs every living data subject of a relation attestation	candidate	EUDI issuance: the PuB-EAA route
AV-11	Bronhouder tests its view for relation attestations	candidate	—
AV-12	Bronhouder as provider has a public validity and revocation policy	candidate	ADR-0028, EUDI issuance: the PuB-EAA route
AV-13	Bronhouder gives the instruction to revoke an attestation	candidate	ADR-0028, EUDI issuance: the PuB-EAA route
AV-14	Consumer has registered contact details for GDPR rights	candidate	—
AV-15	Consumer declares an equivalent alternative at admission	candidate	Constraints

BSNk preconditions

ID	Title	Status	Explained in
BSNK-01	Only a recognized party can activate and transform	fixed	Pseudonymization, Constraints, ADR-0005, ADR-0040, DvTP: the citizen gives consent
BSNK-02	Activation needs the BSN and check data	fixed	Pseudonymization, ADR-0040
BSNK-03	A PI belongs to the requester and nobody else	fixed	Pseudonymization, ADR-0005, ADR-0032, ADR-0040, DvTP: the citizen gives consent
BSNK-04	Transformation is possible only while the citizen is logged in	fixed	Consent, Pseudonymization, Constraints, ADR-0005, ADR-0010, ADR-0032, ADR-0033, DvTP: the citizen gives consent, DvTP: the consumer queries a source under consent
BSNK-05	At most four recipients per request	fixed	Pseudonymization, ADR-0005, DvTP: the citizen gives consent
BSNK-06	The BSN Authorization List sets BSN or pseudonym	fixed	Pseudonymization, ADR-0005, DvTP: the citizen gives consent
BSNK-07	The recipient is an OIN	fixed	Pseudonymization, ADR-0033
BSNK-08	An encrypted value belongs to one key version	fixed	Pseudonymization, ADR-0033, DvTP: the citizen gives consent
BSNK-09	The recipient gets its keys through an Access Service or Key Requester	fixed	Pseudonymization, ADR-0005, ADR-0027, ADR-0033, Deployment view, DvTP: the consumer queries a source under consent
BSNK-10	The party that activates has the inspection duty	fixed	Pseudonymization, ADR-0040
BSNK-11	The interfaces are SOAP with PKIoverheid	fixed	Pseudonymization, Constraints, Context and scope, ADR-0005, DvTP: the citizen gives consent

Demo increments

ID	Title	Status	Explained in
SL-01a	Consent TTL and finer denial reasons	done	Consent
SL-01b	Single use and status machine	blocked	Consent
SL-02	Pseudonymization in the path	done	Pseudonymization, ADR-0005, ADR-0010, ADR-0011, ADR-0033
SL-03a	AST field parsing in OPA	done	Authorization in GBO Basis, ADR-0001, ADR-0012, ADR-0013
SL-03b	Constraint axis (4b) and two-schema model	done	Authorization, ADR-0001, ADR-0009
SL-04	Persist OPA decision logs	done	ADR-0036
SL-05	FSC sector-grant check	done	ADR-0022
SL-06a	User demo flow A: consent issuance	done	DvTP channel, DvTP: the citizen gives consent
SL-06b	User demo flow B: access under MijnOverheid	done	DvTP: the citizen views and revokes consents
SL-07	Restore trace correlation	done	ADR-0019, ADR-0035
SL-08	Consent PIP through PEP pre-fetch	done	ADR-0006, ADR-0032
SL-09	Onboarding and gatekeeper flow	partly covered	ADR-0015, ADR-0027, Admission and activation
SL-10	Observability infrastructure (Loki and Grafana)	done	Deployment view
SL-11	Consent portal backend (S02)	done	Component catalog, Consent facility, Consent, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent
SL-12	Consent register persistence	planned	Risks and technical debt
SL-13	Rego structure clean-up	done	Policy rules and their management, Authorization, Policy lifecycle, ADR-0009
SL-14	Query template as upper bound (POC)	done	ADR-0008
SL-15	Phase out orchestrator	done	—
SL-16	Developer portal	done	Component catalog
SL-17	AuthZEN envelope adoption	done	Authorization, ADR-0002
SL-18	RFC0052-GBO policy refactor and PDP handler	done	ADR-0002, ADR-0013
SL-19	EUDI stand-alone in the demo compose stack	done	EUDI wallet channel, ADR-0018, EUDI issuance: the PuB-EAA route
SL-20	EUDI adapter with AuthZEN dispatch through the PEP	done	—
SL-21	Level C multi-policy demo	planned	—
SL-22	Source gateway de-pseudonymization (DvTP)	done	Component catalog, Generic source access, Pseudonymization, ADR-0011, ADR-0033, DvTP: the consumer queries a source under consent
SL-23	Consent out of the query, pseudonym in the query, and policy binding	done	ADR-0007, ADR-0032
SL-24	Access-basis dispatch through component metadata or certificate	dropped	ADR-0030, ADR-0031
SL-25	PID signature verification in the EDI adapter	dropped	PuB-EAA provider, ADR-0018, Risks and technical debt, EUDI issuance: the PuB-EAA route
SL-26	EDI issuer through an FSC Outway (OIN): PuB-EAA route	done	EUDI wallet channel, PuB-EAA provider, Context and scope, ADR-0018, ADR-0028, Deployment view, Introduction and goals, EUDI issuance: the PuB-EAA route
SL-27	Legitimation of the authorization context (signed envelope)	merged	—
SL-28	Authentic Source Interface (QTSP verification)	done	Component catalog, ASI provider, EUDI wallet channel, Building block view, Constraints, Context and scope, ADR-0029, ADR-0037, ADR-0038, ADR-0039, ADR-0041, ADR-0042, Deployment view, Introduction and goals, Quality requirements, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute, Solution strategy
SL-29	BSN out of the EDI decision logs	done	Pseudonymization, ADR-0011, ADR-0018, ADR-0043, Risks and technical debt
SL-30	Dev portal EUDI flow tracing	done	—
SL-31	FSC Inway payload is pure GraphQL and a token, with no envelope	done	ADR-0002, ADR-0013, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route
SL-32	Adapter parameters from a use-case catalog instead of code	done	Source configuration, Source onboarding
SL-33	EUD0001 explicit scope and actor authorization	done	ADR-0009, EUDI issuance: the PuB-EAA route
SL-34	FSC exploration	done	ADR-0003, Deployment view
SL-34a	Root CA and self-hosted certificate portal (offline CA)	done	Identity and trust, ADR-0023, Deployment view
SL-34b	Tracer bullet: one organization running before broad roll-out	merged	Deployment view
SL-34c	Self-hosted directory peer and directory UI (offline registry)	done	Identity and trust, Deployment view
SL-35	Bootstrap of the FSC organization EDI issuer (consumer)	done	Deployment view
SL-36	Bootstrap of the FSC organization Belastingdienst mock (provider)	done	Deployment view
SL-37	FSC service bri and contract negotiation between organizations	done	Deployment view
SL-38	FSC txlog observability and trace ID equal to Fsc-Transaction-Id	done	Records: decisions, processing, transport, Logging, audit and traceability, ADR-0019, ADR-0035
SL-39	Eudi-adapter to real FSC Outway	done	ADR-0003, EUDI issuance: the PuB-EAA route
SL-40	Pdp-service as AuthZEN endpoint behind FSC Inway (EUDI)	done	Authorization, ADR-0002, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route
SL-41	Documentation and developer portal update: real FSC nodes	done	—
SL-42	Follow-up: fully phase out fsc-mock (option B, DvTP)	done	GBO Basis, Context and scope, ADR-0003
SL-43	Death certificate: BRP source and second EUDI attestation (subject differs from discloser)	done	PuB-EAA provider, ADR-0018, EUDI issuance: the PuB-EAA route
SL-44	OpenFTV Manager: policy management and distribution through bundles (PAP)	done	Component catalog, Policy rules and their management, Policy lifecycle, ADR-0021, Policy distribution
SL-45	Admission as a register and contract decision by the PDP	done	Component catalog, Authorization in GBO Basis, GBO Basis, Policy rules and their management, Authorization, ADR-0015, Quality requirements, Admission and activation, Policy distribution, Solution strategy
SL-46	Generic source metadata: source publishes, GBO validates and activates	done	Component catalog, PuB-EAA provider, Source configuration, Source onboarding, ADR-0016, ADR-0017, ADR-0027, ADR-0039, Admission and activation, EUDI issuance: the PuB-EAA route, Solution strategy
SL-47	Signed, actor-bound consent proof	done	Component catalog, Consent facility, DvTP channel, Consent, Context and scope, ADR-0007, ADR-0032, Quality requirements, DvTP: the citizen gives consent, DvTP: the consumer queries a source under consent, Solution strategy
SL-48	Flow dispatch cleaned up: no default regime, no flow header	done	Authorization in GBO Basis, Authorization, ADR-0014, ADR-0030, ADR-0031, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route, Runtime view, Solution strategy
SL-49	Identity separation: FSC Peer ID separate from source OIN	done	Source configuration, Identity and trust, Source onboarding, ADR-0023, Deployment view, EUDI issuance: the PuB-EAA route
SL-50	LDV and ADL exploration: three logging standards, one trace ID	done	Component catalog, Records: decisions, processing, transport, Logging, audit and traceability, ADR-0026, ADR-0035, ADR-0036, Introduction and goals, Quality requirements, Risks and technical debt, Solution strategy
SL-51	Encrypted identity per source in the consent proof, replaced after the decision	done	Component catalog, Consent facility, DvTP channel, GBO Basis, Records: decisions, processing, transport, Generic source access, Building block view, Consent, Logging, audit and traceability, Pseudonymization, Constraints, Context and scope, ADR-0005, ADR-0007, ADR-0032, ADR-0033, ADR-0040, Glossary, Introduction and goals, Quality requirements, Risks and technical debt, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent, DvTP: the consumer queries a source under consent, Solution strategy

Findings

ID	Title	Status	Explained in
F-02	Central PDP as an implicit choice	closed	ADR-0002, ADR-0004
F-03	The UI offered per-field selection against FR-10 (atomicity)	closed	—
F-04	No consent lifecycle: no TTL, no single use, no status model	closed	ADR-0007
F-06	The source trusted the PEP without a check and had no fourth validation point (FR-26)	closed	ADR-0033
F-07	Only OTel tracing, with no LDV and no non-repudiable decision log	closed	ADR-0026, ADR-0036
F-08	No mTLS or certificate-bound token on FSC	closed	ADR-0004
F-09	No policy lifecycle: hot reload without bundle, signing or versioning	closed	Policy rules and their management, Policy lifecycle, ADR-0021, Policy distribution
F-11	The demo lets the consumer set the validity period	closed	Consent
F-14	The scope header is an untrusted catalog index, not a token claim	resolved in demo	—
F-15	REQ-20 was worded BSN-only	closed	ADR-0005
F-16	No single trace across consent issuance and the DvTP query	closed	Logging, audit and traceability, ADR-0035
F-17	Scope descriptions in the consent portal are hard-coded	closed	—
F-18	DvTP initiation is redirect-only and does not cover an asynchronous invitation	closed	—
F-19	The register does not record the consent-use event ("first used"), so the FR-22 usage status cannot be shown	open	Consent
F-20	The integrator role in DvTP needed PSA elaboration	closed	ADR-0034
F-21	The catalog role split between FDS and GBO was not explicit	closed	ADR-0008, ADR-0009
F-22	The catalog runtime pattern for the PDP was undecided	closed	—
F-23	Rich catalog or rich policy	closed	ADR-0008, ADR-0009
F-24	An unknown consent gave an HTTP error instead of a clean deny	resolved in demo	ADR-0006, DvTP: the consumer queries a source under consent
F-25	PEP schema translation was regex-based and DvTP-specific	closed	ADR-0012, ADR-0013
F-26	Trace-driven UI coloring in the developer portal was fragile	closed	—
F-27	AuthZEN envelope adopted, but not the RFC0052-GBO wire shape	closed	ADR-0002
F-28	The tech lead agreed to the generic GBO chain	closed	—
F-29	consentId in the query was DvTP-specific	closed	—
F-30	De-pseudonymization belongs at the source, and the GBO core stays BSN-free (DvTP path)	resolved in demo	Pseudonymization, ADR-0010, ADR-0011, ADR-0033
F-31	Generic chain shown: two front doors through one PEP and one PDP	closed	ADR-0002
F-32	Access basis from a self-declared flow field was an interim solution	resolved in demo	ADR-0014, ADR-0030, ADR-0031
F-34	Placement of per-request context in transport is a choice	resolved in demo	—
F-35	The FSC Inway has a built-in AuthZEN plugin, so the PEP service doubled the PEP role	resolved in demo	Authorization, ADR-0002
F-36	A sector grant is not a native FSC concept	resolved in demo	ADR-0022
F-37	Transformation after authorization is a gateway task, not a policy task	resolved in demo	ADR-0010, ADR-0011, ADR-0033
F-38	The rich catalog extended to routing and policy lookup	closed	ADR-0008
F-39	FSC v2.4.0 has no OTel instrumentation, so trace context breaks at FSC hops	resolved in demo	Logging, audit and traceability, ADR-0019, ADR-0035
F-40	fsc-logging defines a transaction log and Fsc-Transaction-Id correlation	resolved in demo	ADR-0035
F-41	FSC plugins use context.Background() for downstream calls	resolved in demo	Logging, audit and traceability, ADR-0019, ADR-0035
F-42	Two routes to the FSC transaction log	closed	Logging, audit and traceability, Context and scope, Deployment view
F-43	Grant properties as a trusted dispatch signal per contract	superseded	ADR-0030, ADR-0031
F-44	Where does the PI live, and how does policy bind to the subject?	resolved in demo	ADR-0007, ADR-0032
F-45	Grant-link configuration only through a Controller UI form	closed	ADR-0014
F-46	Service endpoint update only through the Controller UI or database	closed	—
F-47	Wallet credential where the subject of the claim differs from the discloser	open	Component catalog, PuB-EAA provider, Generic source access, ADR-0018, EUDI issuance: the PuB-EAA route
F-49	A flow-name suffix as the PDP source-profile discriminator was ad hoc	premise lapsed	ADR-0031
F-50	Attestation issuer and purpose statement are bound to the signing certificate	closed	Source configuration, Identity and trust, Source onboarding, ADR-0016
F-51	The PDP protects its own management endpoints with the decision policy	open	Policy rules and their management, Policy lifecycle, ADR-0021, Policy distribution
F-52	The policy store is cumulative and cannot delete, and one duplicate package breaks every decision	open	GBO Basis, Policy rules and their management, Authorization, Policy lifecycle, ADR-0015, ADR-0021, Risks and technical debt, Admission and activation, Policy distribution
F-53	Two decision logs side by side and no designated audit source	resolved in demo	Logging, audit and traceability, ADR-0036, Policy distribution
F-54	Log masking in the policy engine is inert, so the BSN-free decision log depended on input construction	open	EUDI wallet channel, Records: decisions, processing, transport, Generic source access, Logging, audit and traceability, Pseudonymization, ADR-0011, ADR-0013, ADR-0043, Introduction and goals, Risks and technical debt, EUDI issuance: the PuB-EAA route
F-55	Admission is a registration instead of a policy rule, and the automatic "no" stays reversible	closed	Source onboarding, ADR-0015, Admission and activation
F-56	The contract payload is thin: the decider sees who, not what	closed	Authorization, ADR-0015, ADR-0022, Admission and activation
F-57	The source owns its service description, and GBO validates and activates it	open	Component catalog, Source configuration, Source onboarding, ADR-0016, ADR-0027, ADR-0039, Admission and activation, EUDI issuance: the PuB-EAA route
F-58	A valid transport contract does not take a source into use	closed	Source configuration, Source onboarding, ADR-0016, Admission and activation
F-59	Source releases have the lifecycle that policy bundles lack	closed	Policy rules and their management, Source configuration, Policy lifecycle, Source onboarding, ADR-0016, ADR-0021, Admission and activation, Policy distribution
F-60	Three identity carriers, with the certificate authoritative for the legal identity	closed	Identity and trust, ADR-0023
F-61	The legal basis travels as proof, the status stays online: a deliberate asymmetry in freshness	closed	Consent facility, Consent, ADR-0032, DvTP: the consumer queries a source under consent
F-62	The additional-claims service is a version-compatibility workaround, and the contract-properties route is open again	resolved in demo	ADR-0014, ADR-0030, ADR-0031
F-63	Logius has three related logging standards, and the demo decision log implements one of them	closed	Logging, audit and traceability, ADR-0026, ADR-0036
F-64	The LDV gap is at the processing instead of the decision, and the source gateway transformation is itself a processing	resolved in demo	Logging, audit and traceability, ADR-0026
F-65	dataSubjectId and the read extension fit the GBO pseudonym model and settle how citizen access works	closed	Logging, audit and traceability, ADR-0026
F-66	Erratum: the PuB-EAA seal and the Access CA were confused with PKIoverheid	closed	Identity and trust, ADR-0023, ADR-0028
F-67	A trace ID equal to Fsc-Transaction-Id conflicts with LDV and the ADL	resolved in demo	Records: decisions, processing, transport, Logging, audit and traceability, ADR-0019, ADR-0035
F-68	A chain read goes forward only, and in DvTP the chain starts at a party that LDV does not bind	open	Records: decisions, processing, transport, Logging, audit and traceability, Source onboarding, ADR-0016, ADR-0026
F-69	A pseudonym that travels across the chain lands in the logbooks of two controllers	resolved in demo	Logging, audit and traceability, ADR-0026
F-70	The regime follows from the proof, but only consent is positive proof: the PID regime comes from not sending something	open	Component catalog, EUDI wallet channel, PuB-EAA provider, Authorization in GBO Basis, GBO Basis, Policy rules and their management, Building block view, OOTS channel, Authorization, Policy lifecycle, ADR-0018, ADR-0030, ADR-0031, Introduction and goals, Quality requirements, Risks and technical debt, Design-level scenarios, DvTP: the consumer queries a source under consent, EUDI issuance: the PuB-EAA route, Runtime view, Solution strategy
F-71	A source without its own metadata endpoint: the operator takes over its service description	open	Component catalog, Source configuration, Source onboarding, ADR-0016, ADR-0027, Admission and activation
F-72	The decision record can carry only what the consumer also gets to see	open	Component catalog, Authorization in GBO Basis, GBO Basis, Records: decisions, processing, transport, Authorization, Consent, Logging, audit and traceability, ADR-0032, ADR-0036, Risks and technical debt, DvTP: the consumer queries a source under consent
F-73	The actor binding of consent assumes that the consumer calls itself, and an integrator breaks that assumption	closed	ADR-0034, Admission and activation
F-74	DvTP scope comes from the demand side, EUDI scope from the supply side, and the intersection is what is technically allowed	open	PuB-EAA provider, Source configuration, Authorization, Source onboarding, ADR-0016, EUDI issuance: the PuB-EAA route
F-75	The BSNk design fits the specification, but the consent facility can fetch the values only as a recognized party	open	Pseudonymization, ADR-0005, ADR-0040, Glossary, DvTP: the citizen gives consent
F-76	The consumer has no citizen identifier, so what it records about "this person" depends on the consent	open	DvTP channel, Consent, Pseudonymization, ADR-0032, DvTP: the citizen gives consent, DvTP: the consumer queries a source under consent
F-77	The PDP checks that the subject comes from the proof, and no longer who the subject is	open	Authorization in GBO Basis, Generic source access, Authorization, Pseudonymization, ADR-0032, DvTP: the consumer queries a source under consent
F-78	The proof freezes at consent: parties, key versions, and proof form are fixed for the whole validity period	open	Consent facility, DvTP channel, Consent, Pseudonymization, Constraints, ADR-0005, ADR-0032, Risks and technical debt, DvTP: the citizen gives consent
F-79	"After the decision" holds only if nothing but the Inway reaches the source gateway	open	Component catalog, GBO Basis, Generic source access, Pseudonymization, ADR-0033, Deployment view, Quality requirements, Risks and technical debt, DvTP: the consumer queries a source under consent, Solution strategy
F-80	Since 2026 the ASI has a statutory interface and a seal obligation, but the authorization part stays a free choice	open	Constraints, ADR-0029, ADR-0037, ADR-0041, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
F-81	Since August 2026 PuB-EAA issuance falls under the same standard as QEAA issuance, with designation, registration, and its own certificate profile	open	EUDI wallet channel, PuB-EAA provider, Identity and trust, Constraints, ADR-0023, ADR-0028, EUDI issuance: the PuB-EAA route
F-82	An issuer must track changes in the source, but GBO only supports queries	open	PuB-EAA provider, ADR-0018, ADR-0028, Design-level scenarios, EUDI issuance: the PuB-EAA route
F-83	Approval in the wallet is not a legal basis, so the EUDI route and DvTP consent cannot lean on each other	open	EUDI wallet channel, Authorization, Consent, ADR-0018, ADR-0037, Design-level scenarios, EUDI issuance: the PuB-EAA route
F-84	ETSI leaves the security profile of the ASI authorization server open, and conflicts on two points with the norms it refers to	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
F-85	The admission of QTSPs depends on a register and a certificate profile that do not exist	open	ASI provider, Identity and trust, Context and scope, ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
F-86	ETSI requires the identification data in the token, and without encryption the QTSP reads the BSN	open	ASI provider, EUDI wallet channel, Constraints, ADR-0037, Quality requirements, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
F-87	In the ASI route the QTSP is not an FSC participant, and the generic chain starts behind the ASIP	open	Component catalog, ASI provider, EUDI wallet channel, Building block view, Identity and trust, Context and scope, ADR-0029, ADR-0037, Introduction and goals, ASI verification: a QTSP verifies or retrieves an attribute, Runtime view, Solution strategy
F-88	An identification means must deliver the mandatory identification data, or the data must come from elsewhere	open	ASI provider, ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
F-89	ETSI lets a response name one authentic source, so an ASIP for several sources offers one data service per source	open	ASI provider, ADR-0038, ASI verification: a QTSP verifies or retrieves an attribute, Solution strategy
F-90	Field keys are unique only within one schema, so a rule without a service binding applied on every service	resolved in demo	Component catalog, Authorization in GBO Basis, Authorization, ADR-0009, Quality requirements
F-91	ETSI requires the authorization-server metadata in the contract, but gives no field for it	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
F-92	Annex IV of CIR 2026/1735 makes the value optional, but keeps the requirement for fuzzy matching	open	ASI provider, ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
F-93	Nothing links the citizen who logs in at the QTSP to the citizen who logs in at the source's authorization server	open	ASI provider, EUDI wallet channel, ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
F-94	The NL PID has no place of birth, while the implementing regulation makes it mandatory	open	ASI provider, ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
F-95	ETSI binds an ASI token only per operation, so a binding per attribute needs its own extension	open	ADR-0042, ASI verification: a QTSP verifies or retrieves an attribute
F-96	ETSI does not name RFC 9207, so a QTSP that verifies at several ASIPs has no defense against mix-up	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
F-97	FR-22 to FR-24 name the same statuses with different words, and the rationale of FR-23 contradicts its criteria	open	Consent, Constraints, DvTP: the citizen views and revokes consents
F-98	FR-DvTP v0.9 contradicts decisions and its own criteria on four points, and PSA S02 is ambiguous on one point	open	Pseudonymization, Constraints, ADR-0040

Open questions

ID	Title	Status	Explained in
Q-01	Which pseudonym form does the system use?	partly answered	DvTP channel, Pseudonymization, ADR-0005, ADR-0033
Q-02	Central authorization server or distributed PDP (per bronhouder)?	answered	GBO Basis, Policy lifecycle, ADR-0004, Policy distribution
Q-03	Atomic consent or field level: what is lawful and understandable?	answered	—
Q-04	Is consent single-use or repeatable within a validity period?	answered	Consent facility, Consent
Q-05	Who is authoritative for revocation and expiry, and what is the propagation SLA?	answered	Consent, ADR-0006, ADR-0007, ADR-0032, DvTP: the consumer queries a source under consent
Q-06	Authentication means for private parties: eHerkenning, PKI certificate, or both?	answered	Identity and trust, ADR-0023
Q-07	PKIoverheid scope as trust anchor (also EUDI Access CA?)	answered	Identity and trust, ADR-0023
Q-08	What belongs in the LDV (processing log), and who holds the retention duty?	open	Records: decisions, processing, transport, Logging, audit and traceability, Context and scope, ADR-0026, ADR-0036, ADR-0043, Deployment view, Risks and technical debt, Policy distribution
Q-09	How does the FSC grant (org permission) relate to consent (legal basis)? Can one be missing?	answered	ADR-0004
Q-10	Which functions must really be central, and which are decentral at each bronhouder?	answered	GBO Basis, Building block view, ADR-0004
Q-11	Transformation between source schema and canonical model: where and how?	answered	OOTS channel, ADR-0001
Q-12	Role of integrators: pass-through, and can they see data?	answered	ADR-0034
Q-13	Who sets the validity period of a consent?	open	Consent facility, DvTP channel, Consent, ADR-0032, Risks and technical debt, DvTP: the citizen gives consent
Q-14	Query enforcement model: how does the PDP model fields, recursion, and arguments?	open	PuB-EAA provider, Authorization in GBO Basis, Generic source access, Authorization, ADR-0001, ADR-0009, ADR-0012, ADR-0013, ADR-0018, EUDI issuance: the PuB-EAA route
Q-15	How does the Manager decide which access-basis path applies to a (consumer x scope) combination?	answered	Authorization, ADR-0014, ADR-0030, ADR-0031
Q-16	AuthZEN/OpenFTV conformity: which profile does GBO follow, and is GBO at the working-group table?	answered	Authorization, ADR-0002
Q-17	EUDI issuance architecture: who owns the issuance server and the adapter?	open	PuB-EAA provider, Source configuration, Building block view, Identity and trust, Source onboarding, ADR-0016, ADR-0023, ADR-0028, ADR-0041, Deployment view, EUDI issuance: the PuB-EAA route
Q-18	EUDI flow security: phishing, certificate management, data processing in the adapter, PID verification	open	EUDI wallet channel, PuB-EAA provider, ADR-0018, EUDI issuance: the PuB-EAA route
Q-19	Where do adapter parameters come from? Boundary of the thin adapter and catalog coupling	answered	Source configuration, Source onboarding, ADR-0016
Q-20	SD-JWT VC claim shape for related-person data: flat display strings or structured objects?	closed	ADR-0017
Q-21	Who can manage and publish the policy of a bronhouder, and how is that authority set federatively?	answered	Policy rules and their management, Policy lifecycle, ADR-0021, Introduction and goals, Risks and technical debt, Policy distribution, Solution strategy
Q-22	Who runs the admission register, on which grounds, and what legal protection has a refused party?	answered	Authorization, ADR-0015, Admission and activation
Q-23	Through which interface does a source get the consent status, and how does the register know who asks?	closed	ADR-0006
Q-24	Must a private consumer record its processing according to LDV?	closed	ADR-0026
Q-25	How can a reader find the step from the decision at the source to the consent log?	open	Records: decisions, processing, transport, Logging, audit and traceability, ADR-0026, ADR-0036
Q-26	Can the consent facility become a recognized BSNk party, and in which role?	open	Pseudonymization, Constraints, ADR-0005, ADR-0040, DvTP: the citizen gives consent
Q-27	Under what does a consumer without an identifier name the data subject in its processing log?	open	Records: decisions, processing, transport, Logging, audit and traceability, Pseudonymization, ADR-0026, DvTP: the consumer queries a source under consent
Q-28	Who designates the PuB-EAA issuer and the ASI intermediary of the Netherlands, and who supervises?	open	ASI provider, EUDI wallet channel, PuB-EAA provider, Identity and trust, Constraints, ADR-0028, ADR-0037, ADR-0041, Deployment view, Introduction and goals, ASI verification: a QTSP verifies or retrieves an attribute, Design-level scenarios, EUDI issuance: the PuB-EAA route
Q-29	Is there a legal basis to verify attributes for private QTSPs, and does the ASI return the value on a match?	open	ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
Q-30	On which trust list are PuB-EAA issuers: LoTE or the trusted lists?	open	PuB-EAA provider, Identity and trust, ADR-0023, ADR-0028, Deployment view, Design-level scenarios, EUDI issuance: the PuB-EAA route, Runtime view
Q-31	Who registers the Dutch verification points in the catalogue of attributes?	open	ASI provider, Source configuration, Source onboarding, ADR-0037, ADR-0039, ASI verification: a QTSP verifies or retrieves an attribute
Q-32	In which format does an ASIP seal the verification result, so a QTSP can validate every ASIP the same way?	open	ASI provider, Identity and trust, ADR-0041, Architecture decisions, ASI verification: a QTSP verifies or retrieves an attribute, Solution strategy
Q-33	Does the Netherlands impose per-attribute authorization for ASI requests under art. 9(5)?	open	ASI provider, ADR-0042, Architecture decisions, ASI verification: a QTSP verifies or retrieves an attribute, Solution strategy
Q-34	What happens to admitted QTSPs if the register is unreachable during a re-check, and how often is it checked?	open	Component catalog, ASI provider, ADR-0037, Deployment view, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
Q-35	Which identifier links a QTSP's access certificate to its register entry?	open	Identity and trust, ADR-0037, Deployment view, ASI verification: a QTSP verifies or retrieves an attribute
Q-36	Which identification means does a Dutch ASI authorization server accept, and where does the identification data come from?	open	ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
Q-37	What is GBO's role in the ASI: designated intermediary, technical supplier to bronhouders, or authentic source itself?	open	Context and scope, ADR-0037, ADR-0038, Introduction and goals, ASI verification: a QTSP verifies or retrieves an attribute
Q-38	How does an authentic source connect to the ASIP: by code, by configuration, or by a description it publishes itself?	partly answered	Component catalog, ASI provider, Source configuration, Source onboarding, ADR-0016, ADR-0017, ADR-0039, Admission and activation, ASI verification: a QTSP verifies or retrieves an attribute, Solution strategy
Q-39	How does a data service contract name the authorization server, so a QTSP finds every ASIP the same way?	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
Q-40	Must the citizen logging in at the QTSP provably be the same as the one logging in at the source's authorization server, and who checks?	open	ASI provider, ADR-0037, Risks and technical debt, ASI verification: a QTSP verifies or retrieves an attribute
Q-41	What happens to the tokens of a QTSP whose right is revoked?	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
Q-42	When is a consent "retrieved", and how does the register learn that?	open	Consent facility, Consent, DvTP: the citizen views and revokes consents
Q-43	For what purpose is a citizen's refusal recorded, and in which form?	partly answered	Consent, DvTP: the citizen gives consent
Q-44	What does the return redirect give back to the consumer, and how does the consent proof reach it?	partly answered	Consent, DvTP: the citizen gives consent
Q-45	Does the consent facility enforce the minimal mandatory set, and who decides which sets are mandatory?	open	Consent
Q-46	Is the integrator in the consent proof, or only in the register?	open	DvTP channel, Consent, ADR-0032, ADR-0034, DvTP: the consumer queries a source under consent
Q-47	Which volumes must the chain handle, at start and later?	open	Consent facility, Consent, ADR-0032, Quality requirements, DvTP: the citizen views and revokes consents
Q-48	Does the register record when a consent was revoked?	open	Consent, DvTP: the citizen views and revokes consents
Q-49	Are the consent register and the consent portal backend one system, and who is the BSNk participant?	open	Consent facility, DvTP channel, Consent, Pseudonymization, Constraints, ADR-0040, Architecture decisions, Risks and technical debt, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent, Solution strategy
Q-50	How does the consent portal backend inside MijnOverheid get the verified citizen identity?	open	Pseudonymization, ADR-0040, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent
Q-51	Must it be provable which information the citizen saw when giving consent?	open	Consent, DvTP: the citizen gives consent
Q-52	In which format does the citizen export the overview of consents?	open	DvTP: the citizen views and revokes consents
Q-53	Within which time and by which mechanism does suspension of a consumer take effect?	open	Authorization, Identity and trust, ADR-0003, ADR-0015, Admission and activation, DvTP: the consumer queries a source under consent
Q-54	Which durability and recovery requirements apply to the register storage?	open	Consent
Q-55	Where is the signing key of the consent proof, and how is it rotated and retired?	open	Consent facility, Consent, ADR-0032, Deployment view
Q-56	How do citizen references follow a rotation of the portal HMAC key?	open	Pseudonymization, ADR-0040, DvTP: the citizen views and revokes consents, DvTP: the citizen gives consent
Q-57	Which protection do the stored polymorphic values get?	open	Pseudonymization, ADR-0040
Q-58	Must the register authenticate the consent portal backend, or is network isolation enough?	open	Consent facility, ADR-0040, Deployment view, Risks and technical debt, DvTP: the citizen views and revokes consents
Q-59	Which security requirements apply to the portal UI inside MijnOverheid?	open	Consent
Q-60	If name, purpose, return address, and status come from the registration, must the origin of the initiation request be provable?	open	DvTP: the citizen gives consent
Q-61	What must MijnOverheid deliver or allow for the portal UI and the link to the consent facility?	open	Consent
Q-62	What must the management organization record or deliver for the consent process?	open	Consent
Q-63	How long are consents, polymorphic values and citizen references kept?	open	Pseudonymization, ADR-0040
Q-64	Must a Dutch ASIP also offer clause 6.2 (ISO 15000) besides clause 6.1, and with it deferred responses?	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
Q-65	Must the ASI support requests on behalf of another person (representation)?	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
Q-66	Which security profile does the authorization server of a Dutch ASIP get?	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
Q-67	How do Dutch data services get into the Discover Interface, and who registers them?	open	ADR-0037, ADR-0038, ASI verification: a QTSP verifies or retrieves an attribute
Q-68	Can policy read the FSC Peer ID as the OIN of the consumer, or must that link come from the register?	open	Component catalog, Consent, Identity and trust, ADR-0023, ADR-0034, Admission and activation
Q-69	Must the consent proof bind the purpose, so that the PDP checks it?	open	Consent, ADR-0032, DvTP: the citizen gives consent
Q-70	Which normalization applies in fuzzy matching per kind of value, and who sets it?	open	ADR-0039
Q-71	Which form do address and name get as attributes, until the EU catalogue of attributes fixes it?	open	ADR-0039
Q-72	Do GBO components write attributes outside the LDV core, and if so under which extension?	open	Logging, audit and traceability, ADR-0026
Q-73	Whose consent is a consent given by an authorized representative, and what does the register record?	open	Consent
Q-74	Does GBO build the registration and onboarding facility for service providers, or the management organization?	open	ADR-0015, ADR-0027, Architecture decisions, Admission and activation
Q-75	Does every source response get one seal, regardless of channel (DvTP, EUDI, ASI)?	open	ADR-0028, ADR-0041, Risks and technical debt
Q-76	Does the validity period apply per consent or per source within the consent?	open	Consent
Q-77	What is a change of a consent: a new consent or an amendment of the existing one?	open	Consent
Q-78	How does the reference policy show that it is not tied to one policy language or engine?	open	Policy rules and their management, Policy lifecycle
Q-79	Does GBO build the OOTS adapter, or does the OOTS-V operator extend its facility with the GBO interface?	open	OOTS channel, Context and scope, ADR-0020, ADR-0024, Design-level scenarios, Runtime view

Standards feedback items

ID	Title	Status	Explained in
E1	No field for the authorization-server metadata in the contract	open	ASI verification: a QTSP verifies or retrieves an attribute
E2	Value optional after Annex IV of 2026/1735, but the fuzzy-matching requirement stays	open	ASI verification: a QTSP verifies or retrieves an attribute
E3	A response names one authentic source	open	ADR-0038, ASI verification: a QTSP verifies or retrieves an attribute
E4	No seal format for the verification result	open	ADR-0041, ASI verification: a QTSP verifies or retrieves an attribute
E5	A token binds per operation and has no binding per attribute	open	ADR-0042
E6	Identification by the QTSP and by the authorization server are not linked	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
E7	Identification data is readable for the QTSP in the token	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
E8	Security profile left open, with conflicts on PAR and RS256 against the norms it references	open	ADR-0037
E9	RFC 9207 (iss in the authorization response) is missing	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute
E10	The meaning of a revoked right for issued tokens is not defined	open	ADR-0037, ASI verification: a QTSP verifies or retrieves an attribute

Not explained

Every open finding and every open question is cited by at least one TO page or decision.