iSHARE Change Management
Other Resources
CAB & Co-Creation Meetings
CAB & Co-Creation Meetings
  • Co-Creation Sessions
  • CAB Meetings
    • 2023-09-06
    • 2023-12-06
    • 2024-03-06
    • 2024-06-05
    • 2024-10-09
    • 2024-12-04
    • 2025-03-05
    • 2025-04-30 (extraordinary CAB)
    • 2025-07-02
    • 2025-09-03
    • 2025-12-03
Powered by GitBook
LogoLogo

  • Cookie Policy

  • Privacy Policy

  • Imprint

  • Contact Us

Copyright © 2024 iSHARE Foundation

On this page
  • Agenda
  • Meeting results
Edit on GitLab
  1. CAB Meetings

2025-03-05

Last updated 2 months ago

This CAB meeting was held at March 5, 2025 at 15:00 CET.

Agenda

  1. Welcome + introduce new participants

  2. Update on the implementation of RFCs on the

    1. Update on release 2.1

  3. Advice on the implementation of RFCs

  4. Input/review required

  5. Advice on newly incoming RFCs

  6. RFC prioritisation: discuss priority on the

  7. Wrap up and outlook to next quarter

Meeting results

  1. The impact analysis of both RFC037 and RFC061 have been delayed and cannot be discussed for a final advice. They are urgent however because the community expects them to be released in upcoming summer release. It was decided that iSHARE Foundation organises a extraordinary CAB meeting for discussing these two RFCs only.

  2. Participants are invited to support in the analysis of requirements and impact of RFCs.

  3. The incoming RFCs are discussed.

  4. RFC037 Licenses is put on release 3.0 temporarily. Next extraordinary CAB meeting we should consider if this requires an extra release. RFC044 and RFC049 are requested to be considered as part of 3.0. iSHARE Foundation will check if possible and respond to it in the next CAB meeting.

  5. iSHARE Foundation will update everyone when version 2.1 is available.

The slides used are available .

Version 2.1 is expected to be released this week. It contains and further improvements in the quality of documentation.

: Positive response from CAB. Possibly use content negotiations as a way of maintaining backwards compatibility.

: Positive response from CAB. This RFC is an opportunity to look at the modelling of the party object.

: CAB advises to rename the RFC to 'Revisit assessment framework' so that it can also include eIDAS 2 regulation and any other relevant regulation, next to the input that can be taken from the DSGO normenkader.

: CAB advises to take input from RFC037 about licenses and make sure that this is covered in this RFC. Also note that the /service endpoint that uses LicensePurpose is only an example (best practice) implementation, not a mandatory implementation. It should help interoperability by adding this in the best practice implementation.

: Positive response from CAB. This must be seen as a correction and revisiting of JWT requirements. It was never the intention to limit the possible JWT attributes.

: CAB advises to merge this RFC into "".

: CAB advises to not just remove the section, since the parties endpoint seems to reflect some of it in the attributes legal_adherence and compliancy_verified. These attributes are role related however. This RFC should focus on clarifying how the framework specifies legal and technical compliance. The RFC must be renamed to reflect this as well.

: CAB advises to ask the requestor of the RFC to specify more precisely what is requested in terms of different levels, since the requirements for ARs only include one specific endpoint. What exactly is the point where compliance becomes difficult and costly?

RFC board
Tentative: RFC037: Redefine licenses, add licenses and make them machine readable
Tentative: RFC061: Add CRUD operations to Parties endpoint
Remove JSON wrapper in API request and response
Improve portability and maintainability of clients in multiple data spaces
Extend iShare assessment framework based on DSGO input
Additional header fields for Licenses
More flexibility in JSON Web Token attributes
party_info object alignment between DSGO and iSHARE
Remove possibility for parties with partial compliance
Support different levels of conformance testing for Authorisation Registry
RFC board
here
several RFCs
Remove JSON wrapper in API request and response
Improve portability and maintainability of clients in multiple data spaces
Extend iShare assessment framework based on DSGO input
Additional header fields for Licenses
More flexibility in JSON Web Token attributes
party_info object alignment between DSGO and iSHARE
Improve portability and maintainability of clients in multiple data spaces
Remove possibility for parties with partial compliance
Support different levels of conformance testing for Authorisation Registry