2026-07-01
This CAB meeting was be held on July 1, 2026 at 15:00 CET. If you would like to be invited for these meetings, or if you would like to add a topic to the agenda, please reach out to us through available channels.
Agenda
Welcome + introduce new participants
Update on the implementation of RFCs on the RFC board
RFC prioritisation: discuss priority on the RFC board
Wrap up and outlook to next quarter
Release 4.0
With the work on flavours, the next framework release is a major release and will be tagged 4.0. It covers the framework and the specifications; reference software follows on a best effort basis. The current target date is the end of November 2026. Older versions remain active; release and version management, including the support window and deprecation, is addressed in RFC048 and requires member input.
Currently marked for release 4.0: RFC048, RFC072, RFC068, RFC070, RFC044, RFC063, RFC049, RFC073, RFC043, RFC032 and RFC067, subject to the decisions below. Newly approved RFCs can only be added by rescoping the release or by moving the target date.
Work Items
RFC050: Allow Service Provider to retrieve delegation evidence without Service Consumer's client assertion The original restriction exists for privacy reasons, to prevent an Authorisation Registry from being queried without an active, authorised consumer request. The impact is expected to be limited, since Service Provider is an optional attribute in a policy and only policies naming a Service Provider could be returned. CAB advises to approve the RFC for impact analysis, with the remark that the outcome may be to keep the current behaviour as a recommendation and leave the choice to the data space or the participants. CAB considers this a nice to have and gives it a lower priority.
RFC039: EBSI compliance EBSI is becoming less relevant in current projects, while eIDAS2 and verifiable credentials have become the relevant direction. The RFC also covered alignment with Gaia-X, which is a separate activity that does not currently require an RFC. CAB advises to cancel this RFC. A new RFC can be raised if EBSI becomes relevant again.
RFC066: Additional header fields for licenses Raised to align iSHARE with the additional license fields specified in the DSGO framework, so that interoperability is not affected once data services start using them. CAB advises to approve the RFC for impact analysis, which should also establish how the fields are best included in requests and responses given that licenses are referenced as URLs, and whether a normative specification update is required.
RFC063: Remove JSON wrapper in API request and response Discussed earlier in a co-creation session and confirmed by several participants that the change does not add value at this moment. CAB advises to cancel this RFC.
RFC049: Signing the HTTP payload. Further analysis and the current flavours proposal indicate that payload signing is required for the qualified flavour (level 4), where the highest level of assurance, full legal coverage and non-repudiation are claimed. CAB advises to retain the RFC and to continue it as a sub-RFC under RFC073 (flavours), where the applicable flavours will be determined. It can still be dropped later if it proves not to be relevant.
Advice on newly incoming (Proposed) RFCs
RFC078: Structured 'also known as' identifiers The field is currently a string array without a type per identifier, which makes it difficult and potentially inconsistent for a consumer to determine whether a value is an EORI, KvK, DUNS or LEI number, and difficult and potentially inconsistent for a Participant Registry to validate it. The proposal is to change it to a structured array with an id and a type. Existing connections do not break, but parties parsing the party token will need to update their implementation. CAB advises to approve this RFC with high priority, as a candidate for release 4.0 or earlier. RFC071: DSGO proposals to improve roles and authorisations In practice most participants do not build their own connections but use an IT party, while the framework only recognises Data Provider, Data Consumer and Data Rights Holder. CAB advises to approve this RFC into requirements definition. The outcome is expected to include one or more knowledge base articles clarifying when an intermediary must become a member of the data space and how it should be authorised, and possibly additional role definitions. CAB advises not to include this RFC in the release 4.0 scope and to target it at release 4.1 in the first half of next year.
RFC074: eSeal via remote HSM. CAB recognises the proposal as good practice from a security perspective, but considers it a software implementation matter rather than a framework requirement; mandating it would raise the entry barrier for participants. Use of an HSM is in any case implied at level 4, since a qualified certificate cannot be issued without one. CAB advises to reject this RFC. The subject will be picked up on a separate software track.
RFC075: Allow PKIOverheid certificate The cost of an eIDAS certificate, approximately €1,200 per year, is a significant entry barrier, and for many data services the qualified level and non-repudiation are not required. The original reason for requiring eIDAS was European interoperability together with legal coverage and non-repudiation; under the flavours model a lower assurance level can be allowed explicitly at the lower levels, with a clear upgrade path to level 3 and 4. CAB advises to approve this RFC for intake and to analyse it as a sub-RFC within the flavours work. Level 2 is expected to be a fit; applicability to level 3 and above depends on further analysis, including whether such certificates are accepted for identification outside the Netherlands.
RFC076: NIS2 vs ISO 27001 impact analysis The Assessment Framework currently requires ISO 27001 certification, which participants find costly and difficult to obtain, and which is blocking data services from going live. Raised was that NIS2 is regulation rather than a certification scheme, so it is not clear how a company demonstrates compliance to a counterparty, or who verifies it. CAB advises to approve this RFC. The first step is an impact analysis establishing whether NIS2 and ISO 27001 are equivalent, complementary, or whether one can substitute for the other at certain levels. DSGO offers input and support for the analysis. This RFC has high priority for CAB; inclusion in release 4.0 is subject to the effort involved and the impact on the planning.
RFC077: Complete v3.0 Identity Broker specification and Developer Portal documentation The Identity Broker role is defined in the framework but has no getting started pages or specification in the Developer Portal, so the role cannot be implemented today. Its relevance is also questionable, as the role originates from the eHerkenning model and a broker that takes on onboarding responsibilities effectively becomes an Identity Provider under the framework definition. CAB advises to approve this RFC, covering both the relevance of the role and, if it is retained, its technical specification. CAB advises to add the RFC to the backlog and to exclude it from the release 4.0 scope, to avoid delaying the release.
Last updated