2025-09-26
This CAB meeting was held at September 26, 2025 at 14:00 CET.
Agenda
Welcome + introduce new participants
Update and advice on the implementation of RFCs on the RFC board
Update on approved RFCs
RFC041: Optimise delegation path discovery The impact analysis of this RFC has lead to a better understanding of delegation chain scenario's. It was not possible to select a pattern that is clearly a the best pattern in terms of requirements such as privacy and efficiency. The identified patterns do not require changes in the iSHARE specifications at this point. The idea is to add the insights to the knowledge base, but not to change anything on the iSHARE specifications. CAB advises to approve the RFC and to create the knowledge base article as part of the RFC implementation.
RFC046: Define Dataspace Self Description to improve discoverability CAB advises to approve the RFC and validate the attribute level specification of the self description JSON during implementation with CAB. Implementation should not be mandatory in the initial release.
RFC054: Define what can be overwritten and what not in the framework CAB advises to approve this RFC.
RFC056: AR per application / data service CAB advises to approve this RFC, taking into account the remarks that have been made during the latest co-creation session on this topic. The diff for RFC056 will be shared during the release process
RFC055: Allow conditions in delegations Approved in CAB Q2 2025.
Update on conditionally approved RFCs
RFC040: Verifiable Credentials support CAB recognises that more work on this topic is required, while the specifications to implement (such as DCP and OID4VP) are not yet completely finalised. CAB acknowledges that current iSHARE based initiatives will probably not implement it in the very near future. CAB conditionally advises to start implementation and request feedback from CAB during implementation.
RFC060: Revise Assessment Framework (Link to updated Assessment framework) CAB advises to conditionally approve this RFC.
The following RFCs were not discussed in the previous CAB due to time constraints. CAB participants have provided feedback via Gitlab, email and through additional co-creation sessions (for RFC064). Based on that we propose the following implementation.
RFC058: Introduce the concept of optional features in the framework https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/~/diff/~/changes/52/authorisation-registry-role/delegation-policy
RFC067: More flexibility in JSON Web Token attributes https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/~/diff/~/changes/50/reference/ishare-jwt/~/overview
RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation' https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/VzDPr66OfjJMnoD3PTZn/~/diff/~/changes/40/detailed-descriptions/operational/operational-processes/admission
Descoped from version 3.0
RFC032: Framework legal changes CAB advises to postpone the implementation of this RFC to give data space initiatives more time to evaluate the consequences and thereby exclude it from the 3.0 scope.
RFC049: Signing the HTTP payload CAB (particularly DSGO as the creator of this RFC) advises to postpone this RFC and exclude it from the 3.0 scope, to allow for more time to discuss this RFC.
RFC043: Introduce role of "Certification Body" CAB advises to conditionally accept the RFC and RFC impact analysis, including the discussion in the latest co-creation session on the RFC and to start implementation. CAB requests iSHARE to request feedback from CAB during implementation. During further impact analysis / implementation we decided to descope this from version 3.0.
Advice on newly incoming RFCs
RFC prioritisation: discuss priority on the RFC board
Wrap up and outlook to next quarter
Meeting notes
Update and advice on the implementation of RFCs on the RFC board. The preview of version 3.0 is available on https://ishare-3.gitbook.io/3.0-preview.
The following approved RFCs are included:
RFC054: Define what can be overwritten and what not in the framework Discussed was that an RFC may be raised to declare certain parts of the framework optional.
RFC056: AR per application / data service Discussed was that the Entitled Party should not be required to provide a capabilities endpoint. A detailed comparison of all changes applied for this RFC is provided at the bottom of this page.
The following RFCs were conditionally approved and are not part of the provided preview version, but will be part of the final release:
RFC040: Verifiable Credentials support The final impact analysis was presented. It was discussed which party credential should be implemented and conclusion was that participants prefer to implement both and let the adoption decide which of the models is to be preferred. It was also discussed that the RFC should align with eIDAS2. It was also discussed specifications will be based on the Decentralized Claims Protocol (DCP, Eclipse) for M2M credential issuance and OpenID4VC (Open ID) for H2M credential issuance. CAB requests to include the specs as OPTIONAL so that it by default is not needed to be implemented by all iSHARE participants. However, inline with other such specifications, it is expected of participants to implement compliant versions if they choose to implement optional features/specifications. Also to be clearly mentioned is that this implementation is meant as a first version and will be improved along the way. With these remarks the CAB approves the RFC.
RFC060: Revise Assessment Framework It was decided that participants will provide feedback on the revised framework within a week. If there are no issues, the new framework will be published in the 3.0 release. Thereby it is conditionally approved.
The following RFCs were not discussed in the previous CAB. Since the last CAB dicsussions have taken place online and in co-creation meetings.
RFC064: Improve portability and maintainability of clients in multiple data spaces The final impact analysis was discussed. The RFC is approved and will be implemented in version 3.
RFC059: Publish OpenAPI (Swagger) definitions under MIT license https://github.com/iSHAREScheme/openapi/pull/27/files Participants will look and raise objection if not approved.
RFC058: Introduce the concept of optional features in the framework https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/~/diff/~/changes/52/authorisation-registry-role/delegation-policy Discussed and approved.
RFC067: More flexibility in JSON Web Token attributes https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/~/diff/~/changes/50/reference/ishare-jwt/~/overview Discussed and approved.
RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation' https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/VzDPr66OfjJMnoD3PTZn/~/diff/~/changes/40/detailed-descriptions/operational/operational-processes/admission Was discussed and remarked was that it should not only be technical compliance, but compliance in general (including technical) - and an option of Not applicable should be added. Further improved.
The descoped RFCs are explicitely not cancelled, but will be part of a next release.
Incoming RFCs will be discussed in a next CAB
Agreed was that the final preview will be shared with participants and that a week's time will be allowed for any feedback.
Overall the participants ask the iSHARE Foundation to prepare a comparison between the current version and the new proposed version well before CAB, so it allows for better preparation for the meeting.
The complete diffs of the framework and the dev-portal (status as per today) are:
Last updated