Edit

2025-07-09

This CAB meeting was held at July 9, 2025 at 15:00 CET.

Agenda

  1. Welcome + introduce new participants

  2. Framework's flexibility and adaptability in different contexts

  3. Update on the implementation of RFCs on the RFC board

    1. Suggestion to cancel RFC057: Legal Interoperability - International trade and B2G scenario's. Priority has been reconsidered by requestor + new licenses in RFC037 cover most of it.

  4. Advice on the implementation of RFCs

    1. RFC043: Introduce role of "Certification Body"

    2. RFC041: Optimise delegation path discovery

    3. RFC040: Verifiable Credentials support

    4. RFC046: Define Dataspace Self Description to improve discoverability

    5. RFC032: Framework legal changes

    6. RFC049: Signing the HTTP payload

    7. RFC054: Define what can be overwritten and what not in the framework

    8. RFC056: AR per application / data service

    9. RFC060: Revise Assessment Framework

    10. RFC059: Publish OpenAPI (Swagger) definitions under MIT license

    11. RFC058: Introduce the concept of optional features in the framework

    12. RFC067: More flexibility in JSON Web Token attributes

    13. RFC064: Improve portability and maintainability of clients in multiple data spaces

    14. RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'

  5. Input/review required

  6. Advice on newly incoming RFCs

    1. RFC072: Authentication Assurance Levels

    2. RFC071: DSGO proposals to improve roles and authorisations

    3. RFC068: Flip the model for non-repudiation

    4. RFC070: Using WWW-Authenticate header as an access token endpoint discovery mechanism

    5. [CANCELLED] RFC069: Support different levels of conformance testing for Authorisation Registry

  7. RFC prioritisation: discuss priority on the RFC board

  8. Wrap up and outlook to next quarter

Meeting notes

The participation of iSHARE based initiatives was limited. The formulated outcome of the meeting will be shared with al other participants and they have the possibility to provide their insights and thoughts after the meeting, which may lead to organising an extra CAB meeting.

As for the advice on the implementation of the RFCs, two possible outcomes have been defined:

  1. Advise to accept and start implementation.

  2. Advise to conditionally accept, start implementation, but validate further details with CAB when available. This outcome can be applicable to RFC proposals which are prepared, but with limited implementation details.

Meeting notes:

  1. A proposal was discussed to raise an RFC that overarches existing RFCs (particularly RFC068, RFC070, RFC071, RFC072) and provides a direction and structure to create a more flexible framework that could apply to more implementation scenario's, including scenario's where a lower level of trust is required than iSHARE currently bring.

  2. a. The requesting party of RFC057 has reconsidered and does not require it anymore. Furthermore most points that are addressed in it are already covered in for example RFC037 (Licenses). CAB advises to cancel RFC057.

  3. The following RFCs are discussed:

    1. 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.

    2. 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.

    3. 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.

    4. 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.

    5. 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.

    6. 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.

    7. RFC054: Define what can be overwritten and what not in the framework CAB advises to approve this RFC.

    8. 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.

    9. RFC060: Revise Assessment Framework CAB advises to conditionally approve this RFC. - The following RFCs were not discussed due to time constraints and feedback will be gathered using email -

    10. RFC059: Publish OpenAPI (Swagger) definitions under MIT license

    11. RFC058: Introduce the concept of optional features in the framework

    12. RFC067: More flexibility in JSON Web Token attributes

    13. RFC064: Improve portability and maintainability of clients in multiple data spaces

    14. RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'

Last updated