# iSHARE Change Management Welcome to the documentation of iSHARE's Change Management process. * For more information regarding iSHARE, please refer to iSHARE's [website](https://www.ishare.eu) * For more information about the change management process as part of the [iSHARE Trust Framework](https://framework.ishare.eu) refer to [this page](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/change-management) The change management process is the responsibility of the Scheme Owner (iSHARE Foundation), working together with the Change Advisory Board. Please review the pages about the [RFC process](/change-management-process) and the [impact analysis procedure](/impact-analysis-procedure) to understand more about the process. All documentation about the organised meetings (CAB and Co-Creation Meetings) is kept in [Co-Creation and CAB Meetings](https://changes.ishare.eu/v/cab-and-deepdive-meetings). Impact analysis of RFCs are kept [here](https://changes.ishare.eu/v/rfc-impact-analysis-1). A complete overview of all RFCs, their status and priority, is kept is as [Gitlab issue board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards). # RFC Process ## Scope of the change management process This change management process is designed to be used for changes that impact the [iSHARE Trust Framework](https://framework.ishare.eu). Trivial changes (such as typo's or the addition of extra clarifications) are out of scope of this process. ## Change management process and RFCs The change management process is designed around Request For Changes (RFCs). The following diagram describes the change management process. ![Change management process diagram](https://2722076483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjX3oz4uYOaBvoUHfiSwe%2Fuploads%2Fgit-blob-3acef2701bbf9b654bd03c24cf412775f4c2c8b0%2FChange%20Management%20Process.png?alt=media) If any required additional changes arise after implementing an RFC, a new RFC must be raised. An RFC cannot be *reopened*. ### Roles in the change management proces The following roles are recognised in the change management process: * Participant: any party involved in iSHARE as a participant, as defined in [Framework and Roles](https://framework.ishare.eu/is/framework-and-roles) * Change Manager: the person responsible on behalf of the Scheme Owner for managing changes. The Change Manager: * Maintains the [RFC backlog](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) * Maintains the [RFC template](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Template.md) * Facilitates the process * Communicates the process outcomes * Change Advisory Board (CAB): a group that is open to (potential) iSHARE participants, which advises on RFC's. * Change Advisory Board chair: the chair of the Change Advisory Board. The chair responsible for organising CAB meetings. * Executive Board: responsible for handling first line escalations (see [escalation procedure](#escalation-procedure)) * Council of Participants: responsible for handling second line escalations (see [escalation procedure](#escalation-procedure)) ### Escalation procedure If one of the parties involved in the process is unsatisfied with the process's outcome, the following escalation path should be followed: 1. Escalate to the Executive Board of iSHARE Foundation (acting as Scheme Owner). 2. Escalate to the Council of Participants of the iSHARE Foundation. ## The change management process as implemented using Gitlab Various features of Gitlab support the change management process, as described below using the phases of the change management process. ### Proposing a change Any (potential) participant can propose a required change. The proposed change must be registered in Gitlab, using a [Gitlab issue](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/new). The RFC Template should be used as a reference for providing the required information. The RFC must be labelled "RFC Proposed". The Change Manager will evaluate the requested change. If the requirements are not clear enough to start an impact analysis, the RFC will be labelled "RFC requirements definition". ### Requirements definition Before an impact analysis can be performed, it is vital to have a solid understanding of the requirements that have led to the RFC. This is usually a process in which iSHARE can participate, but will not lead. If the requirements are clear, the Change Manager can discuss the RFC in the Change Advisory Board and assign an RFC number to it, or reject it. After assigning an RFC number the RFC will be labelled "RFC Impact Analysis" or "RFC Rejected". ### Impact analysis Next step in the change management process is performing an impact analysis. This will result in a more detailed description, possibly combined with other assets in a subfolder per RFC in the [/RFC Documents](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Documents/README.md) folder. Impact Analysis is considered a collaborative effort, in which each (potential) iSHARE participant is invited to take part in. For more information on contributing to RFC impact analysis, please refer to the \[Contribution procedure]\(/Impact Analysis Procedure.md). After performing impact analysis, the RFC will be discussed (again) in the Change Advisory Board. The Change Advisory Board will advice on the implementation or rejection of the RFC, after which the Change Manager will make a formal decision to implement the RFC or reject it. The RFC will then be labelled "RFC Approved and ready for implementation" or "RFC Rejected". ### Implementation When implementation is started, the RFC will be labelled "RFC implementation" and remain so until implementation is finished, after which the RFC will be labelled "RFC Implemented". ## Gitlab repository This respository should be considered the single source of truth, where all latest RFCs are published. The following file and directory structure is maintained: | File/directory | Remark | | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | [/Assets](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/Assets/README.md) | Support folder containing general assets | | [/CAB Meeting Documents](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/CAB%20Meeting%20Documents/README.md) | Contains preperations for CAB meetings and meeting notes | | [/RFC Documents](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Documents/README.md) | Contains subfolder per RFC in which all relevant RFC documents and assets are stored per folder | | [Change Management Process.md](/change-management-process) | This file | | [RFC Template.md](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Template.md) | Holds the RFC Template and should only be edited by the change manager | The RFC backlog is managed using [Gitlab Issues](https://gitlab.com/ishare-foundation/cab/rfc/-/issues). # Impact Analysis Procedure This document describes how impact analysis is considered a collaborative effort within the iSHARE Change Management process and how this is implemented using Gitlab. ## Start of impact analysis After an RFC has been discussed in the Change Advisory Board and approved by the Change Manager, work on impact analysis can start. The RFC is given an RFC number by the Change Manager and moved on the [board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) from "RFC Identified" to "RFC Impact Analysis" (or given the corresponding labels). ## Using Gitlab to collaborate on RFCs If you are familiar with using Gitlab: the general approach is to fork the project, commit to the fork and then do a merge request to the upstream repository. In the steps below, this procedure is explained. ### 1. Fork the project * Make sure you have a Gitlab account and login into Gitlab * Go to the projects [fork page](https://gitlab.com/ishare-foundation/cab/rfc/-/forks) * Click on "Fork" (upper right) to fork the project * Execute the steps and create your fork ### 2. Editing and committing Use one of the the following methods for editing. After editing you need to *commit* changes to you fork. This can be considered as saving. In order to prevent conflicts, it's advisable to choose one of the following methods and stick to it. #### Local IDE Using a local IDE (for instance Visual Studio Code). This requires a local install of Git and some knowledge of Git. Commit using your local Git (or as integrated in the IDE). #### Online IDE Using the online IDE provided by Gitlab. [This image](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/Assets/WebIDE.png) shows where to open the online IDE. After editing commit your changes as shown in [this image](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/Assets/Commit%20in%20WebIDE.png). #### Single file For small changes, consider editing the single file. [This image](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/Assets/Single%20file%20edit.png) shows how to edit a single file. After you are done editing, press the Commit button to save your changes. ### 3. Propose your changes by a merge request When you are done editing and committing your contribution to the RFC impact analysis, you can request the Change Manager to review and accept your changes. This is done by doing a Gitlab *merge request* (in Github this is called a *pull request*). * Open your fork on Gitlab.com * In the menu, under "Code", click on "Merge requests" * Click on the button "New merge request" * Make sure that: -- On the left side under Source branch your fork is selected, with the branche you have been working on (usually "main") -- On the right side under Target branche ishare-foundation/cab/rfc, branch main is selected * Click "Compare branches and continue" * Describe the changes you have made using the title and description * Click on "Create merge request" The changes you have made are then propsoed to the Change Manager and integrated in the RFC if they are accepted. ## Suggested file structure of an RFC folder When writing an RFC, please conform to the following rules: * All documents regarding an RFC should be stored in a subfolder in [/RFC Documents](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Documents/README.md) named RFC###, where ### is the number of the RFC that was assigned to the RFC by the change manager * Write the RFC by copying the [RFC Template.md](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Template.md) to the RFC folder, renaming it to **index.md** # Co-Creation Sessions {% hint style="success" %} If you would like to be a part of one or more RFC deep dive meetings, please [reach out to us](https://ishare.eu/home/contact/). {% endhint %} The iSHARE Change Management Co-Creation Sessions are collaborative events where you can share ideas, shape improvements, and help develop the iSHARE Trust Framework, a framework built by and for the community. ## What are Co-creation Sessions? They interactive online meetups where we: * Discuss and co-develop impact analysis of a proposed RFC * Review RFCs (Requests for Change) * Opportunity to discuss your idea/contributions with a larger community * Provide feedback on proposed solutions and recommendations * Keep up-to-date with latest changes potentially coming in the near future, so you are better informed and prepared for new releases. * Explore ways to improve the iSHARE Trust Framework * Discuss upcoming updates that keep the iSHARE future-ready You can follow along anytime via our public documentation: — including all RFCs, analyses, and outcomes. ## What can you expect? * Open, online sessions * Every two weeks (dates & agendas shared monthly) * 1.5 hours of focused collaboration * All you need: add to your calendar and participate ## How is the outcome processed? The outcome of the deep dive meetings is added to the discussed [RFC issues on Gitlab](https://gitlab.com/ishare-foundation/cab/rfc/-/boards). # CAB Meetings The Change Advisory Board meetings are part of the [iSHARE Governance](https://framework.ishare.eu/is/governance-framework): * The Change Advisory Board consists of subject matter experts (legal/ operational/ functional/ technical) delegated by the participants and data spaces. * The Change Advisory Board advises the Scheme Owner on changes to the specifications of the iSHARE Trust Framework. About the CAB Meetings: * Discuss proposed RFCs * Advice on proposed RFCs * Proceed with impact analysis or reject * Advice on impacted RFCs * Proceed with implementation or reject * Quarterly on Wednesday afternoon # 2023 # 2023-09-06 This meeting is part of the quarterly RFC meeting schedule. The documentation for the CAB meeting that was held at September 6, 2023, is available here: . # 2023-12-06 This meeting is part of the quarterly CAB meeting schedule. This page concerns the CAB meeting held at December 6, 2023 at 15:00 CET. ### Agenda 1. Welcome + introduce new participants 2. Evaluate new RFC process 3. Advice on implementation of RFCs: * [ ] RFC034: Define standard policy creation endpoint for AR * [ ] RFC031: Alternatives to EORI identification * [ ] RFC045: Introduce zero-trust network * [ ] RFC042: Harmonise terminology (tentative) * [ ] RFC044: RFC044: Accomodate iSHARE Satellite without distributed ledger (tentative) 4. Advice on newly incoming RFCs: * [ ] [Improve change and release management proces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/17) * [ ] [Publish licenses machine readable](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/18) * [ ] [Signing the HTTP payload](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/16) * [ ] [Generalisation of the capabilities endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/15) 5. RFC prioritization: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 6. Wrap up and outlook to next quarter # 2024 # 2024-03-06 This meeting is part of the quarterly CAB meeting schedule. This page concerns the CAB meeting held at March 6, 2024 at 15:00 CET. ### Agenda 1. Welcome + introduce new participants 2. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 3. Advice on the implementation of RFCs 4. Input/review required: * [x] [RFC047: Generalisation of the capabilities endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/15)\ General approach described in impact analysis - detailed specifications will be defined in implementation. * [x] [RFC048: Improve change and release management process](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/17) 5. Advice on newly incoming RFCs: * [x] [Allow service provider to retrieve delegation evidence on which it is mentioned without service consumer's client assertion](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/19) * [x] [Revert to standard OAuth authentication flows](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/20) * [x] [Applicability of SLAs under Adhering parties contract should be applicable only to parties providing services](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/21) * [x] [None-API-consuming-Service Consumers to be onboarded without the PKI certificate (like eIDAS)](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/22) * [x] [Define what can be overwritten and what not in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/23) * [x] [Allow conditional delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24) 6. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 7. Wrap up and outlook to next quarter ### Decisions A transcription of the meeting is available upon request. * [RFC047: Generalisation of the capabilities endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/15): will be scheduled for a next deep dive, where iSHARE Foundation will provide a detailed suggestion of the new endpoint definition. They will take into account proper versioning (looking at semver.org for inspiration), minimal mandatory fields and a flat structure. * [RFC048: Improve change and release management process](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/17): input can be provided through the regular channels and the RFC will be scheduled for a deep dive session. * [Allow service provider to retrieve delegation evidence on which it is mentioned without service consumer's client assertion](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/19): CAB supports this request and suggests to use the current feature of specifying the Service Provider environment. * [Revert to standard OAuth authentication flows](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/20): CAB advises to review new OAuth specification proposals regarding JWTs to be implemented in the standard. Rajiv highlights the legal aspects of the current specification (vs standard OAuth) and the upcoming implementation of verifiable credentials as an alternative. The CAB sees this as an opportunity to look at the additional standards/amendments proposed under the main RFC to see if it has better alignment possibility with iSHARE. * [Applicability of SLAs under Adhering parties contract should be applicable only to parties providing services](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/21): CAB advises to take this up as an RFC. * [No API consuming Service Consumers to be onboarded without the PKI certificate](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/22): CAB advises to take this up as an RFC. * [Define what can be overwritten and what not in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/23): CAB advises to take this up as an RFC and suggests to use the concept of prevalence and making parts optional to achieve a more simple implementation. * [Allow conditional delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24): CAB advises to take this up as an RFC, but to make sure that the actual implementation remains simple and backwards compatible, as the existing policy evidence structure is already comprehensive and gather feedback in a deep dive session. * Priority is determined to be by the order on the board: the higher the RFC card is on the column, the higher the priority of the RFC. # 2024-06-05 This meeting is part of the quarterly CAB meeting schedule. This page concerns the CAB meeting held at Jun 5, 2024 at 15:00 CET. ### Agenda 1. Welcome + introduce new participants 2. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 3. Advice on the implementation of RFCs * [ ] [RFC047: Respecification of the capabilities endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/15) * [ ] [RFC055: Allow conditions in delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24) * [ ] [RFC052: Applicability of service levels under Adhering parties contract should be applicable only to parties providing services](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/21) 4. Input/review required * [ ] RFC042: Harmonise terminology - we have reconsidered naming and would like to inform you on the [naming that we will be implementing with this RFC](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/1-rfc042-harmonise-terminology/RFC%20Documents/RFC042/README.md?ref_type=heads) * [ ] RFC031: Preperation of [iSHARE DID method](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/11-rfc031-introduce-ishare-id-and-allow-multiple-identifiers-using-did/RFC%20Documents/RFC031/Implementation/did-spec.md?ref_type=heads). The method name will probably be changed. * [ ] We expect to publish a new version of the framework and development documentation with the next release. This will impact all existing direct links to parts of the framework. The update is required to improve version handling and change management. Demonstration will be given in the meeting. 5. Advice on newly incoming RFCs * [ ] [AR per application / data service](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25) * [ ] [Legal Interoperability - International trade and B2G scenario's](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/26) 6. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 7. Wrap up and outlook to next quarter ### Advise from CAB More detailed meeting notes are available upon request. 3. Advice on the implementation of RFCs * [RFC047: Respecification of the capabilities endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/15): CAB advises to start implementation of the prepared RFC and impact analysis. * [RFC055: Allow conditions in delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24): CAB advises to not start implementation, but instead spend more time in deep dives, specifically on the interoperability concerns between data spaces and the value that the RFC brings compared to the impact on complexity. Ideally owners of the business value are present at the deep dive meetings. * [RFC052: Applicability of service levels under Adhering parties contract should be applicable only to parties providing services](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/21): CAB advises to start implementation of the prepared RFC and impact analysis. 4. Input/review required * [RFC042: Harmonise terminology](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/1): CAB suggests to add mapping to IDSA and provide extra information on the conclusion that a one-on-one mapping with terminology used in other initiatives is not possible. Also producing a supporting document that explains the mapping would help the community to better understand meaning and comparison of the mapping. * [RFC031: Introduce iSHARE-ID and allow multiple identifiers using DID](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/11), preparation of [iSHARE DID method](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/11-rfc031-introduce-ishare-id-and-allow-multiple-identifiers-using-did/RFC%20Documents/RFC031/Implementation/did-spec.md?ref_type=heads): CAB advises to organise more in depth sessions on this topic, focusing on how the iSHARE DID method would work outside iSHARE and inviting more experts to address the topic and assess the created iSHARE DID method. 5. Advice on newly incoming RFCs * [AR per application / data service](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25): CAB advises to start impact analysis. * [Legal Interoperability - International trade and B2G scenario's](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/26): CAB advises to start impact analysis. 6. Prioritisation has been done on the board. 7. Other topics that were addressed during the meeting: * Owners of a use case or the business value that has led to the creation of an RFC should preferably take part in the deep dive sessions, to make them more practical and less theoretical. * All feedback to RFCs must be provided in Gitlab to make things more transparent. * iSHARE Foundation will make sure that summaries of deep dive discussions (or possibly transcripts) will be made available through Gitlab. * iSHARE Foundation will look into ways of making the last version of an impact analysis more easily accessible, without requiring in depth knowledge of Gitlab. * RFC040: Verifiable Credentials support was discussed and decided to put on on hold, awaiting input from the Eclipse Data Space Working Group. # 2024-10-09 This meeting is part of the quarterly CAB meeting schedule. The next CAB meeting will be held at October 9, 2024 at 15:00 CET. If you would like to be invited for this meeting, or if you would like to add a topic to the agenda, please reach out to us through available channels. ### Agenda 1. Welcome + introduce new participants 2. Updated framework release process and structure\ \- Asynchronous release of documentation and supporting IT components -> to be included in [RFC048](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/17)\ \- Introduction of optional features (per role) 3. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards)\ We expect a next release of the framework in December 2024, which is expected to include following RFCs:\ \- [RFC031: Introduce iSHARE-ID and allow multiple identifiers using DID](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/11)\ \- [RFC045: Introduce zero-trust network](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/12)\ \- [RFC042: Harmonise terminology](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/1)\ \- [RFC052: Applicability of service levels under Adhering parties contract should be applicable only to parties providing services](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/21)\ \- [RFC036: Decommision of PKIOverheid certificates](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/8)\ \- [RFC034: Define standard policy creation endpoint for AR](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/9) (implement as optional feature)\ \- [RFC047: Respecification of the capabilities endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/15)\ Please note that release of the framework documentation precedes releases of supporting IT components such as the CTT and the iSHARE Satellite reference implementation.\ The final scope of the release will be determine shortly before the release and shared through the usual channels. 4. Advice on the implementation of RFCs\ \- [RFC055: Allow conditions in delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24) (implement as optional feature for AR)\ \- [RFC051: Revert to standard OAuth authentication flows](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/20)\ \- [RFC053: Allow Service Consumers without PKI certificate](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/22) 5. Input/review required Any of the above RFCs if not concluded, then Input/Review is required for the same. 6. Advice on newly incoming RFCs\ \- [Evaluate if eIDAS 2.0 affects the Assessment Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/27)\ \- [Publish OpenAPI (Swagger) definitions under MIT license](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/28)\ \- [Introduce optional features in Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/29) 7. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 8. Wrap up and outlook to next quarter\ \- Next CAB session on December 4, we suggest to host it at our office and request members to plan it in their agenda to visit our office. ### Meeting results 2. About the asynchronous release of documentation. After questions from CAB it is clarified that within six months of the framework release, the IT components will be updated, unless there are reasons or circumstances to deviate from this. This is to be included in RFC048. iSHARE Foundation will update RFC048.\ \ About the introduction of optional features (per roles). CAB suggests to refrain from using optional features too much, so the consistency throughout the framework is affected as less as possible. It should be a balance between impact on participants and consistency / interoperability across participants and data spaces. These things must be detailed out in the RFC impact analysis of introducing optional features. 3. CAB was provided insight into the expected scope of the next release. 4. Advice on the implementation of the RFCs:\ \- RFC055 was discussed in depth. Although it is recognised that the RFC increases complexity, it is also recognised that it brings a relevant extension to the framework. It was decided that implementation as an optional feature, allowing for both scenario's (scenario C) is the preferred implementation scenario. The optional part of it will be part of the dataspace definition (whether to use it or not). CAB advices to start implementation.\ \- RFC051 was discussed. CAB advices to clarify more clearly what implementation scenario is selected and then to start implementation. It will not affect the formal specifications, but will lead to the creation of supporting documents.\ \- RFC053 was explained and CAB advices to start implementation. 5. \-- 6. \- [Evaluate if eIDAS 2.0 affects the Assessment Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/27) -> OK to take on as RFC. CAB advices to also look at eHerkenning's updated assessment framework (which is probably in line with eIDAS 2.0) and DSGO's assessment framework.\ \- [Publish OpenAPI (Swagger) definitions under MIT license](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/28) -> CAB agrees to develop this as an RFC and would like to see progress on this on a short term.\ \- [Introduce optional features in Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/29) -> as discussed earlier, OK to create. 7. RFCs we re-prioritised on the board 8. All are invited to come to the iSHARE Rotterdam office for the next CAB, scheduled on December 4, 2024.\ We will organise a meeting on the open source projects that iSHARE is involved in, or add it to the agenda of next CAB.
# 2024-12-04 The next CAB meeting will be held at December 4, 2024 at 15:00 CET. If you would like to be invited for this meeting, or if you would like to add a topic to the agenda, please reach out to us through available channels. ### Agenda 1. Welcome + introduce new participants 2. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 1. Preview of release 2.1 3. Advice on the implementation of RFCs 4. Input/review required 5. Advice on newly incoming RFCs 1. Add CRUD operations to Parties endpoint 6. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 7. Wrap up and outlook to next quarter ### Meeting results The slides used are available [here](https://docs.google.com/presentation/d/1FvXSHW4pZASzPXnV3_w3C_JD3EGZ0DU2Mt77fXXxEiY/edit?usp=sharing). 2. The upcoming 2.1 release was extensively discussed and demoed. The anticipated impact is mostly in RFC031, which is about introducing identifiers. CAB requests to explain in more detail how backwards compatibility is designed, particularly on RFC031. 3. No RFCs were discussed. More impact analyses are expected to be prepared for approval for the next CAB session. 4. No RFCs were discussed. 5. CAB advises positively on the RFC about CRUD operations on the Parties endpoint. A deep dive session will be organised on the topic to start gathering requirements. 6. RFC priority was discussed, no changes were made. RFC on CRUD operations has a high priority. 7. The development of the reference onboarding portal was shown as a preview. Everyone is invited to the next CAB, which will be held in the ishare office on March 5, 2025! # 2025 # 2025-03-05 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 [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 1. Update on release 2.1 3. Advice on the implementation of RFCs 1. [Tentative: RFC037: Redefine licenses, add licenses and make them machine readable](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/7) 2. [Tentative: RFC061: Add CRUD operations to Parties endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/30) 4. Input/review required 5. Advice on newly incoming RFCs 1. [Remove JSON wrapper in API request and response](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/31) 2. [Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32) 3. [Extend iShare assessment framework based on DSGO input](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/33) 4. [Additional header fields for Licenses](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/34) 5. [More flexibility in JSON Web Token attributes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/35) 6. [party\_info object alignment between DSGO and iSHARE](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/36) 7. [Remove possibility for parties with partial compliance](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/37) 8. [Support different levels of conformance testing for Authorisation Registry](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/38) 6. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 7. Wrap up and outlook to next quarter ### Meeting results The slides used are available [here](https://docs.google.com/presentation/d/1lsp5pmcwtvhxL2eCnLBU0sr-OwqB5KW8yLOf-HEbHNY/edit?usp=sharing). 2. Version 2.1 is expected to be released this week. It contains [several RFCs](https://gitlab.com/ishare-foundation/cab/rfc/-/boards?label_name\[]=Release%202.1) and further improvements in the quality of documentation. 3. 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. 4. Participants are invited to support in the analysis of requirements and impact of RFCs. 5. The incoming RFCs are discussed. 1. [Remove JSON wrapper in API request and response](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/31): Positive response from CAB. Possibly use content negotiations as a way of maintaining backwards compatibility. 2. [Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32): Positive response from CAB. This RFC is an opportunity to look at the modelling of the party object. 3. [Extend iShare assessment framework based on DSGO input](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/33): 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. 4. [Additional header fields for Licenses](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/34): 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. 5. [More flexibility in JSON Web Token attributes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/35): 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. 6. [party\_info object alignment between DSGO and iSHARE](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/36): CAB advises to merge this RFC into "[Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32)". 7. [Remove possibility for parties with partial compliance](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/37): 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. 8. [Support different levels of conformance testing for Authorisation Registry](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/38): 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? 6. 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. 7. iSHARE Foundation will update everyone when version 2.1 is available. # 2025-04-30 (extraordinary CAB) This CAB still needs to be scheduled. The CAB has special focus on two impact analysis that have been drafted for the next release. ### Agenda 1. Welcome + introduce new participants 2. Advice on the implementation of RFCs 1. [RFC037: Redefine licenses, add licenses and make them machine readable](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/7) 2. [RFC061: Add CRUD operations to Parties endpoint](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/30) 3. Release 3.0 update 1. RFC044 and RFC049 have been added to the release 3.0 4. Any other business ### Meeting notes 2. Cab advices to accept the impact analysis and start implementation, towards a 2.2 release. 3. CAB advices to accept to scope increase of release 3.0 # 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](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 1. Suggestion to cancel [RFC057: Legal Interoperability - International trade and B2G scenario's](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/26). 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"](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/3) 2. [RFC041: Optimise delegation path discovery](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/4) 3. [RFC040: Verifiable Credentials support](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/5) 4. [RFC046: Define Dataspace Self Description to improve discoverability](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/13) 5. [RFC032: Framework legal changes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/14) 6. [RFC049: Signing the HTTP payload](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/16) 7. [RFC054: Define what can be overwritten and what not in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/23) 8. [RFC056: AR per application / data service](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25) 9. [RFC060: Revise Assessment Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/27) 10. [RFC059: Publish OpenAPI (Swagger) definitions under MIT license](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/28) 11. [RFC058: Introduce the concept of optional features in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/29) 12. [RFC067: More flexibility in JSON Web Token attributes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/35) 13. [RFC064: Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32) 14. [RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/37) 5. Input/review required 6. Advice on newly incoming RFCs 1. [RFC072: Authentication Assurance Levels](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/42) 2. [RFC071: DSGO proposals to improve roles and authorisations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/41) 3. [RFC068: Flip the model for non-repudiation](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/40) 4. [RFC070: Using WWW-Authenticate header as an access token endpoint discovery mechanism](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/39) 5. \[CANCELLED] [RFC069: Support different levels of conformance testing for Authorisation Registry](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/38) 7. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 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: 2. 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. 3. 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. 4. The following RFCs are discussed: 1. [RFC043: Introduce role of "Certification Body"](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/3)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/4)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/5)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/13)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/14)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/16)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/23)\ CAB advises to approve this RFC. 8. [RFC056: AR per application / data service](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/27)\ 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](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/28)
11. [RFC058: Introduce the concept of optional features in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/29)
12. [RFC067: More flexibility in JSON Web Token attributes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/35)
13. [RFC064: Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32)
14. [RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/37) # 2025-09-26 This CAB meeting was held at September 26, 2025 at 14:00 CET. ### Agenda 1. Welcome + introduce new participants 2. Update and advice on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 1. Update on approved RFCs 1. [RFC041: Optimise delegation path discovery](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/4)\ 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. 2. [RFC046: Define Dataspace Self Description to improve discoverability](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/13)\ 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. 3. [RFC054: Define what can be overwritten and what not in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/23)\ CAB advises to approve this RFC. 4. [RFC056: AR per application / data service](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25)\ 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 5. [RFC055: Allow conditions in delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24)\ Approved in CAB Q2 2025. 2. Update on conditionally approved RFCs 1. [RFC040: Verifiable Credentials support](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/5)\ 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. 2. [RFC060: Revise Assessment Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/27) ([Link to the Assessment Framework](https://docs.google.com/spreadsheets/d/1y_luXfLA2G0dFDFUD1MJot5Jnoj24iHPmqQh7oBveEc/edit?gid=1517602205#gid=1517602205))\ CAB advises to conditionally approve this RFC. 3. 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. 1. [RFC059: Publish OpenAPI (Swagger) definitions under MIT license](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/28)\ 2. [RFC058: Introduce the concept of optional features in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/29)\ [https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/\~/diff/\~/changes/52/authorisation-registry-role/delegation-policy](broken://spaces/8M1G8Jl0iPw8PoUkeIir/pages/wI0Nz1Srpaok04new1On) 3. [RFC067: More flexibility in JSON Web Token attributes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/35)\ [https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/\~/diff/\~/changes/50/reference/ishare-jwt/\~/overview](broken://spaces/8M1G8Jl0iPw8PoUkeIir/pages/obPErkiUPKrlqzJgjcVX) 4. [RFC064: Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32)
5. [RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/37)\ [https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/VzDPr66OfjJMnoD3PTZn/\~/diff/\~/changes/40/detailed-descriptions/operational/operational-processes/admission](broken://spaces/VzDPr66OfjJMnoD3PTZn/pages/vSNbYLlYNxG21YWAy6px) 4. Descoped from version 3.0 1. [RFC032: Framework legal changes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/14)\ 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. 2. [RFC049: Signing the HTTP payload](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/16)\ 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. 3. [RFC043: Introduce role of "Certification Body"](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/3)\ 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.* 3. Advice on newly incoming RFCs 1. [RFC072: Authentication Assurance Levels](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/42) 2. [RFC071: DSGO proposals to improve roles and authorisations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/41) 3. [RFC068: Flip the model for non-repudiation](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/40) 4. [RFC070: Using WWW-Authenticate header as an access token endpoint discovery mechanism](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/39) 5. \[CANCELLED] [RFC069: Support different levels of conformance testing for Authorisation Registry](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/38) 4. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 5. Wrap up and outlook to next quarter ### Meeting notes 2. Update and advice on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards). The preview of version 3.0 is available on . 1. The following approved RFCs are included: 1. [RFC041: Optimise delegation path discovery](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/4) () 2. [RFC046: Define Dataspace Self Description to improve discoverability](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/13) 3. [RFC054: Define what can be overwritten and what not in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/23)\ Discussed was that an RFC may be raised to declare certain parts of the framework optional. 4. [RFC056: AR per application / data service](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/25)\ 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. 5. [RFC055: Allow conditions in delegations](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/24) 2. The following RFCs were conditionally approved and are not part of the provided preview version, but will be part of the final release: 1. [RFC040: Verifiable Credentials support](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/5)\ The [final impact analysis](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/2b899a3e9100cce19020acd7dae1834113ef7a91/RFC%20Documents/RFC040/README.md) 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. 2. [RFC060: Revise Assessment Framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/27)\ 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. 3. The following RFCs were not discussed in the previous CAB. Since the last CAB dicsussions have taken place online and in co-creation meetings. 1. [RFC064: Improve portability and maintainability of clients in multiple data spaces](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/32)\ The [final impact analysis](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/9f324005a1bc12e8bbad0133bf0a1c61c87d02df/RFC%20Documents/RFC064/README.md) was discussed. The RFC is approved and will be implemented in version 3. 2. [RFC059: Publish OpenAPI (Swagger) definitions under MIT license](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/28)\ \ Participants will look and raise objection if not approved. 3. [RFC058: Introduce the concept of optional features in the framework](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/29)\ [https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/\~/diff/\~/changes/52/authorisation-registry-role/delegation-policy](broken://spaces/8M1G8Jl0iPw8PoUkeIir/pages/wI0Nz1Srpaok04new1On)\ Discussed and approved. 4. [RFC067: More flexibility in JSON Web Token attributes](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/35)\ [https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/\~/diff/\~/changes/50/reference/ishare-jwt/\~/overview](broken://spaces/8M1G8Jl0iPw8PoUkeIir/pages/obPErkiUPKrlqzJgjcVX)\ Discussed and approved. 5. [RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/37)\ [https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/VzDPr66OfjJMnoD3PTZn/\~/diff/\~/changes/40/detailed-descriptions/operational/operational-processes/admission](broken://spaces/VzDPr66OfjJMnoD3PTZn/pages/vSNbYLlYNxG21YWAy6px)\ 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. 4. The descoped RFCs are explicitely not cancelled, but will be part of a next release. 3. 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: {% file src="/files/209Tr85w5L8QUv9rYhdC" %} {% file src="/files/4hGwD6lCkCqqlWjhfieB" %} # 2025-12-03 This CAB meeting will be held at December 3, 2025 at 15:00 CET. If you would like to be invited for this meeting, or if you would like to add a topic to the agenda, please reach out to us through available channels. ### Agenda 1. Welcome + introduce new participants 2. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 3. Advice on the implementation of RFCs 4. Input/review required 5. Advice on newly incoming RFCs 6. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 7. Wrap up and outlook to next quarter # 2026 # 2026-01-28 This CAB meeting will be held on January 28, 2026 at 10:00 CET. If you would like to be invited for this meeting, or if you would like to add a topic to the agenda, please reach out to us through available channels. ### Agenda 1. Welcome + introduce new participants 2. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 1. Walk through of the [Release 3.0](https://framework.ishare.eu/) 2. Walk through of the Releases [2.1.1](https://framework.ishare.eu/version-2.1.1) and [2.2](https://framework.ishare.eu/version-2.2) updates 3. Work Items 1. [RFC032](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/14): Framework legal changes 2. [RFC049](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/16): Signing the HTTP payload 3. [RFC063](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/31): Remove JSON wrapper in API request and response 4. [RFC048](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/17): Improve change and release management process 5. [RFC044](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/2): Accommodate iSHARE Satellite without distributed ledger 4. Advice on newly incoming (Proposed) RFCs 1. RFC073: iSHARE framework flavours 2. RFC070: Using WWW-Authenticate header as an access token endpoint discovery mechanism 3. RFC068: Non-repudiation improvements 4. RFC071: DSGO proposals to improve roles and authorisations 5. RFC072: Authentication Assurance Levels 5. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 6. Wrap up and outlook to next quarter # 2026-07-01 This CAB meeting will be held on July 1, 2026 at 15:00 CET. If you would like to be invited for this meeting, or if you would like to add a topic to the agenda, please reach out to us through available channels. #### Agenda 1. Welcome + introduce new participants 2. Update on the implementation of RFCs on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 3. Work Items 1. [RFC039](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/6): EBSI compliance 2. [RFC049](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/16): Signing the HTTP payload 3. [RFC063](https://gitlab.com/ishare-foundation/cab/rfc/-/issues/31): Remove JSON wrapper in API request and response 4. Advice on newly incoming (Proposed) RFCs 1. [RFC071](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/41): DSGO proposals to improve roles and authorisations 2. [RFC074](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/44): eSeal via remote HSM 3. [RFC075](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/45): Allow PKIOverheid certificate 4. [RFC076](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/46): NIS2 vs ISO 27001 impact analysis 5. [RFC077](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/47): Complete v3.0 Identity Broker specification and Developer Portal documentation 5. RFC prioritisation: discuss priority on the [RFC board](https://gitlab.com/ishare-foundation/cab/rfc/-/boards) 6. Wrap up and outlook to next quarter # RFC Impact analysis These pages contain finalised impact analysis for the requested RFCs. Draft impact analysis are available as [merge requests](https://gitlab.com/ishare-foundation/cab/rfc/-/merge_requests) or [branches](https://gitlab.com/ishare-foundation/cab/rfc/-/branches) on Gitlab. # RFC031 | Document property | Value | | ------------------------------ | ----- | | Issue reference | #11+ | | Document status \[draft/final] | Final | ## Background and rationale Currently iSHARE uses [EORI numbers](https://taxation-customs.ec.europa.eu/customs-4/customs-procedures-import-and-export-0/customs-procedures/economic-operators-registration-and-identification-number-eori_en) as a method for identifying [Participants](https://ishareworks.atlassian.net/wiki/spaces/ETA/pages/2733605361/Framework+and+roles). iSHARE does not provide it's own identifier to participants. The prescribed use of EORI number has limitations: * It is not actively used by many organisations (usually only in the context of international trade, when dealing with customs) * It is only available to European economic operators * It does not allow data spaces to use their own identification number, while in existing cooperations / industries an industry-specific standard is usually widely available This feels like a barrier for participants to join iSHARE, which is why this has led to requests to support additional identifiers then EORI. This RFC responds to these requests. ## Proposed change ### Purpose To reduce the barrier for participants to join iSHARE, by means of allowing them to join using any identifier they already have, there is a need for allowing the usage of other identifiers. This RFC researches options and proposes an implementation for allowing other identifiers to be used. ### Description and principles At first we have researched candidates that could be an alternative to or be used next to or as an alternative to the EORI-number. #### Considered candidates In our research we have drafted the following list of known identifiers (from a Dutch/international perspective): **Public sector identifiers** * Identifiers of legal entities registered in business registers - Chamber of Commerce, VAT, Tax Identification Number, RSIN, NTR, etc. * ISO 20275: 2017 Entity Legal Form (ELF) * ISO 17442: 2020 Legal Entity Identifier (LEI) * ISO 5009: 2021 Official Organizational Roles (OOR) * Traders Identification Number (TIN) * Economic Operators Registration Identification Number (EORI) * The European Unique Identifier (EUID) * EU VAT Identification Number (IOSS) * EuroGroups Register (EGR) * Global Groups Register (GGR) **Private sector identifiers** * Global Location Number (GLN) * ISO 6523:1998 Identification of Organizations Identifications Schemes * D-U-N-S Number * PermID * ISO 9362: 2014 Business Identification Number (BIC) This list is probably far from complete, as industries often use their own specific identifiers. We have researched two options as a possible alternative to EORI-numbers. **Option 1:** [**D-U-N-S Number**](https://www.dnb.com/duns-number.html) * DUNS number is used worldwide in many industries by many organisations, however market reach and acceptance is still to be ascertained * This is operated by a private company based in US and is profit oriented. This is against our principle of federated/distributed/open standards based * There are costs involved for participants to procure this number * This number is only available for businesses *Conclusion: not viable* **Option 2:** [**GLEI (global Legal Entity Identifier)**](https://www.gleif.org/en/about-lei/gleif-management-of-the-global-lei-system) * This is an initiative the Group of Twenty (G20) called on the Financial Stability Board (FSB) has endorsed * Market reach and acceptance is still to be ascertained * There are costs involved for participants to procure this number * This number is only available for businesses *Conclusion: not viable* The overall conclusion of our market research is that there is no identifier that is commonly used internationally and that has a sufficient reach. The EORI number still seems to be the best fit from that perspective. #### Solution principles Considering the requirements of data spaces and the iSHARE ambition to allow data spaces to be interoperable in IAA, the following solution (principles) is considered to be the best fit: * Each iSHARE Satellite (Data Space Authority) must define which identifier(s) must be used for identification of participants in the data space. *The use of a* [*DID-method*](https://www.w3.org/TR/did-spec-registries/#did-methods) *is advised, but self-defined methods are also allowed.* * The identification (number/string) must be unique for each participant * There will be no predefined list of approved identifiers published by the Scheme Owner * Each participant of a data space that is connected to the iSHARE network, must be provided with an iSHARE-ID * The iSHARE-ID will be provided in the form of a [DID](https://www.w3.org/TR/did-core/) * The ID uniquely identifies an iSHARE participant across data spaces * The ID must be provided to the participants by the first iSHARE Satellite where a party onboards * The iSHARE-ID will be equal to the organization identifier in an attribute of PKI certificate of the participant. This organization identifier has been validated and input by the Certificate Authority (CA) issuing the certificate after following a due diligence process. For example, when Participant is onboarded using and eIDAS certificate, the identifier in the Subject of the eIDAS certificate is in the ASN.OID - "2.5.4.97" or commonly known as OrganizationIdentifier (issued by a Trust Service Provider (TSP)), with the format of this field described in [ETSI EN 319 412-1 V1.5.1, paragraph 5.1.4](https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.05.01_60/en_31941201v010501p.pdf). Using these principles parties can use an unlimited number of identifiers across an unlimited number of data spaces. The common identifier method for all participants all across will be iSHARE-ID at minimum, thereby ensuring interoperability and discoverability. The iSHARE-ID should always be derived from a PKI certificate (currently eIDAS, in the future additionally other such certificates that will be trusted across framework). This also makes sure that this ID is always verifiable programatically which enhances the trust value. We have considered using the proposed ELSI method ([1](https://www.etsi.org/deliver/etsi_gr/CIM/001_099/018/01.01.01_60/gr_CIM018v010101p.pdf), [2](https://data-spaces-business-alliance.eu/wp-content/uploads/dlm_uploads/Data-Spaces-Business-Alliance-Technical-Convergence-V2.pdf)) instead of iSHARE-ID. This method is however not yet registered and limited to usage in Europe, which is why we decided to use an iSHARE defined DID method instead. Usage of this method is ofcourse not prohibited. The DID-Method Specific Identifier will be equal for both an ELSI method and an iSHARE method. #### Using DID to store multiple identifiers Based on the discussions we had in past CAB meetings and evaluations of various options we recommend to use [Decentralized Identifiers (DIDs)](https://www.w3.org/TR/did-core/) as the format for identifiers. This has added advantage of being aligned with other initiative like GAIA-X, IDS, EBSI, etc. * DID formats have “[methods](https://www.w3.org/TR/did-core/#dfn-did-methods)”, which determine how the identifier must be interpreted. Methods can be used by data spaces to define a type of identification number that will be registered for a participant. * One method will be defined by the Scheme Owner: this will be the iSHARE-ID method. * Each satellite must be able to resolve the iSHARE DID method to a DID document. An example of a party identifier is: ```json [ did:ishare:NTRNL-12345678, did:elsi:LEIXG-724500AZSGBRY55MNS59, did:web:example.com dataspace_selfdefined_identifier:123456 ... ] ``` In this example: * DID method "ishare" refers to the method defined by the Scheme Owner as the iSHARE-ID and to be registered as DID method. * DID method "elsi" refers to the not yet registered ELSI method. * DID method "web" refers to the registered DID method [web](https://w3c-ccg.github.io/did-method-web/). * "dataspace\_selfdefined\_identifier" is an identifier define by a data space and only used in that data space and other data spaces that have decided to trust this identifier. #### How does this affect interoperability * Each participant that wishes to operate in multiple data spaces connected to the iSHARE network should at least have an iSHARE-ID. * Participants in other data spaces can discover this participant by using it's iSHARE-ID. * Other data spaces can append identifiers to the DID array and thus provide better discoverability in their own data space (if a different ID is predominantly used in this data space). * By using other DID-methods for participants, interoperability and discoverability can further be enhanced. * Self defined identifiers are only trusted within a data space that supports these, and in data spaces that explicitly trust these identifiers. ### Example use cases Consider the following scenario: * An iSHARE Satellite (Data Space Authority) has selected KvK-number to be accepted as an identifier within it's data space. * An onboarding procedure has been established by the satellite in which it is determined how proof should be presented for registration of this KvK-number: authentication with eHerkenning level 3+. * The satellite is part of the iSHARE network. This impacts the data space in the following way: * When onboarding a participant (other then Entitled Parties), the participant should 1. Present an eIDAS certificate, from which the iSHARE-ID will be derived and 2. Authenticate with eHerkenning level 3+, from which the KvK-number will be copied. * When a Service Consumer requests a service from a Service Provider * The Service Provider can check the adherence of the Service Consumer with the iSHARE Satellite using either the iSHARE-ID, or the KvK-number, or both. * The Service Provider can provide delegation evidence using the iSHARE-ID or the KvK-number. ## Impact on the ecosystem The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role). | Formal role | Technical impact | Business / legal / functional / operational impact | | ------------------------ | ---------------- | -------------------------------------------------- | | Service Consumer | Yes | Yes | | Service Provider | Yes | Yes | | Entitled party | Yes | Yes | | Authorization Registry | Yes | Yes | | Identity Provider | Yes | Yes | | Identity Broker | Yes | Yes | | Data Space Administrator | Yes | Yes | | Satellite | Yes | Yes | ## Impact iSHARE Foundation (Scheme Owner) * The Trust Framework must reflect the changes in this RFC, specifically on * [The page about EORI identification](https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70221905/Identification+by+EORI) * [The glossary](https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70222187/Glossary) * [The Admission process](https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70222125/Admission) * [The JWT example payload](https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70221964/JSON+Web+Token+JWT) * The developer documentation (as an extension of the iSHARE Trust Framework): will be changed extensively, since the current identification number EORI is used widely. This especially accounts for the /parties and /party endpoints of the iSHARE Satellite. * Example implementation in [Postman Collections](https://dev.ishare.eu/demo-and-testing/postman.html) must be changed. * The iSHARE Satellite reference codebase as developed on: must be changed. * The implementation of the iSHARE Satellite for iSHARE as the Scheme Owner on and must be changed. * Authorization Registry test implementation: must be changed to accept different identifiers. * The Conformance Test Tool: , tests listed on must be changed. * iSHARE test satellite (used for conformance testing): must be changed. * iSHARE foundation * Will propose ishare as an official DID method ## Implementation ### Release schedule The impact of this RFC is large and it is hard to provide backwards compatability. An implementation plan must be drafted and discussed with stakeholders. ### Communication \[ ] TODO Describe required communication topics and means. # RFC034 | Document property | Value | | ------------------------------ | ----- | | Issue reference | #9+ | | Document status \[draft/final] | Draft | ## Background and rationale Currently iSHARE certified Authorization Registries (see [functional requirements](https://framework.ishare.eu/is/functional-requirements-per-role#Functionalrequirementsperrole-AuthorizationRegistryAuthorizationRegistry) or [general information](https://ishare.eu/about-ishare/authorization-registry/)): * Can hold information on delegations to other entities by Entitled Parties; * Have a process in place allowing for the registration, update and revocation of delegations; * Can check, on the basis of this information, whether a legal entity is authorized to take delivery of a service; * Can, after a request in the form of a "delegation mask" is presented, confirm whether this is the case by either: * Providing delegation evidence to the Service Consumer, which then can present the evidence to the Service Provider; * Providing delegation evidence to the Service Provider. There is no prescribed API endpoint to request creating, updating and deleting delegations. An Authorization Registry provider is free to design the process for registration, update and revocation of delegations (for instance by providing a user interface, an API, a manual process, connections with existing software, or any other method). iSHARE currently only defines the /delegation endpoint for an Authorization Registry. The basic structure is: * [/delegation endpoint](https://dev.ishare.eu/delegation/endpoint.html) * [Request](https://dev.ishare.eu/delegation/endpoint.html#request) contains a [delegationRequest (Delegation Mask)](https://dev.ishare.eu/delegation/delegation-request.html) * Which contains [policySets](https://dev.ishare.eu/delegation/policy-sets.html#refpolicysets) * Which contain [policies](https://dev.ishare.eu/delegation/policy-sets.html#refpolicies) * [Response](https://dev.ishare.eu/delegation/endpoint.html#refdelegationresponseexample) contains a JWT delegation\_token, containing [delegation evidence](https://dev.ishare.eu/delegation/delegation-evidence.html) * Which contains [policySets](https://dev.ishare.eu/delegation/policy-sets.html#refpolicysets) * Which contain [policies](https://dev.ishare.eu/delegation/policy-sets.html#refpolicies) ## Proposed change ### Purpose This RFC aims to stimulate the registration of fine grained authorizations by creating the possibility for a machine-to-machine delegation policy request that is automatically approved based on a ruleset provided by an entitled party. ### Description and principles As an Entitled Party I want to delegate the right to request (to create) delegation policies to a delegated party. I provide the Authorization Registry with a ruleset on which these requests are evaluated. The delegated party can then request the creation of delegation policies on behalf of me, which are evaluated on the ruleset that I have provided and then automatically added as delegation policies. Principles: * The party to which the right is delegated is called the “Delegation Policy Requestor”. * The ruleset used to delegate the right to create and manage delegations on which delegation policy requests are evaluated, is called “authorisation rules”. * The “Delegation Policy Requestor” can request delegations using an API offered by the Authorization Registry. * The “Delegation Policy Requestor” can only request delegations at the Authorization Registry at which the authorisation rules are stored (i.e. the Authorization Registry of the Entitled Party). * The requests may be automatically (dis)approved based on the authorisation rules that are defined by the Entitled Party. * A wildcard (“\*”) authorisation rule, essentially allowing the “Delegation Policy Requestor” to request and manage all of the Entitled Party’s delegations, is not allowed. * Authorization Registries should follow principles on overlapping policies (see [Authorisation Rules specification](/rfc-impact-analysis-1/rfc034/authorisation-rules-specification)). Note that it remains possible to create, update and delete delegations by the Entitled Party itself, making this change fully backwards compatible. > ***NOTE:*** For ease of reading, this RFC assumes that delegation policies are stored and managed as such, however this is not a requirement. It could be that an Authorization Registry uses a different method to store delegations (not with policies, but for example using business rules or transaction data). Upon receival of a delegation evidence request the delegation evidence is produced and return. This RFC requires a process in reverse order: a delegation policy request (having a similar structure as delegation evidence) is presented, which must be translated back into the chosen method for storing delegations. > ***NOTE:*** The implementation of the described endpoint by the Authorization Registries is mandatory from the iSHARE Framework version in which it is introduced (expected in 2.1), though not mandatory for older versions. ### Example use cases By implementing the changes in this RFC multiple scenarios will benefit from this. These are best explained using examples. This first example use case describes a situation where an entitled party uses a service provided by a third party. The entitled party registers a generic delegation at his Authorization Registry, setting the boundaries (rules) for delegations that are provisioned from a software solution (for instance an eCMR) that already contains fine grained delegations. The delegations are proactively provisioned from the 3rd party software/service provider, after which the service can be consumed based on these delegations. In this example we use the following entities (all of them are iSHARE participants): * `[Banana & co]`: the Entitled Party * `[eCMR]`: the 3rd party software/service provider used by the Entitled Party * `[Authorization Registry]`: the Authorization registry * `[Warehouse 13]`: a Service Provider * `[ABC Trucking]`: a Service Consumer (acting as a Delegation Policy Requestor) ![Delegations creation flow](https://599143963-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWxuDM1F2jjgSCGdZ0spz%2Fuploads%2Fgit-blob-8031961ddbf5c4ab4cd259bc1acc1be8a69bbe86%2FDelegation%20creation%20flow.png?alt=media) 1. The Entitled Party (`Banana & co`) creates the authorisation rules at Authorization Registry (using an interface provided by the Authorization Registry), determining the scope of delegations that can be created based on the authorisation rules. The rules could for instance contain a list of containers, or a timeframe (all containers in the coming month) and the Service Provider (`Warehouse 13`) where the data is stored. 2. The Entitled Party (`Banana & co`) requests the 3rd party software/service provider (`eCMR`) to provision the Authorization Registry with delegation policies. 3. The 3rd party software/service provider (`eCMR`) requests the creation of fine-grained delegations-policies at the Authorization Registry, based on the authorisation rules and the existing knowledge of fine-grained within the 3rd party software/service provider. 4. The Authorization Registry evaluates the request for creation of the delegation policies with the authorisation rules. If the required delegation falls within the authorisation rules, the delegation is created. 5. *This step is outside the scope of iSHARE.* The Entitled Party requests a service from a party (`Banana & co`) (requires ABC Trucking to pick up a container). The party (`ABC Trucking`) requires data that belongs to the Entitled Party (`Banana & co`) from a Service Provider (`Warehouse 13`) and will therefore act as a Service Consumer. It needs a delegation in order to access this data at the Service Provider (`Warehouse 13`) where the data is stored. 6. The Service Consumer (`ABC Trucking`) requests delegation evidence from the Authorization Registry. The delegation evidence is provided based on the fine grained delegation policies that are stored in the Authorization Registry. 7. With the delegation evidence the Service Consumer (`ABC Trucking`) can request data from the Service Provider (`Warehouse 13`). 8. *This step is outside the scope of iSHARE.* The requested service from the Service Consumer (`ABC Trucking`) is delivered to the Entitled Party (`Banana & co`). **Other examples** for using the proposed changes in this RFC are: * An entitled party could delegate the management of delegation-policies to the Service Consumer. The Service Consumer requests the creation of a delegation policy based on the authorisation rules just before accessing a service provided by the Service Provider. * A party could request a delegation from the Entitled Party by requesting this delegation at the Authorization Registry. The Authorization Registry informs the Entitled Party that a certain delegation is requested, after which the Entitled Party can approve this. This is depicted in the diagram below. ![Delegations creation flow alternative](https://599143963-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWxuDM1F2jjgSCGdZ0spz%2Fuploads%2Fgit-blob-12d388cd2de43582774a8e31bd0eae63291b2a7f%2FDelegation%20creation%20flow%202.png?alt=media) ## Impact on the ecosystem The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role). | Formal role | Technical impact | Business / legal / functional / operational impact | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Service Consumer | Possibly, when it wants to request policy creation | Possibly, when it wants to request policy creation | | Service Provider | No | No | | Entitled party | No | Yes, create authorisation rules, allow fine grained authorizations to be automatically managed | | Authorization Registry1 | Yes, provide a way to manage authorisation rules and provide an API endpoint for delegation policy request. | Yes, provide operational and functional process to support this as well define the legal boundaries on policies created based on rule sets, if the Authorization Registry chooses to implement the endpoint. | | Identity Provider | No | No | | Identity Broker | No | No | | Data Space Administrator | No | No | | Satellite | No | No | 1 This change is fully backwards compatible with current implementations of Authorization Registries. Current delegations are therefore not affected. This RFC introduces a non-formal role of a party called “Delegation Policy Requestor”. Any party can fulfill this role, as long as this party is enrolled as a participant in the data space and can therefore be identified when registering the authorisation rules. | Non-formal role | Technical impact | Business / legal / functional / operational impact | | --------------------------- | ----------------------------------------------- | -------------------------------------------------------------------- | | Delegation Policy Requestor | Yes, implement AR delegation policy request API | Yes, support Entitled Party in providing fine grained authorizations | ## Impact iSHARE Foundation (Scheme Owner) ### iSHARE Trust Framework The RFC will require changes in the iSHARE Trust Framework (as published [here](https://framework.ishare.eu/)). The following changes are foreseen: * A new basic data [license](https://framework.ishare.eu/is/licenses) will be defined, which forms the legal basis for requesting the creation of delegation policies. First draft: ``` 9996 Request the creation of delegations on behalf of the Entitled Party, bound to defined authorisation rules, liability lies with Delegation Policy Requestor. 9997 Request the creation of delegations on behalf of the Entitled Party, bound to defined authorisation rules, liability lies with Entitled Party. 9998 Request the creation of delegations on behalf of the Entitled Party, bound to defined authorisation rules, liability is subject to conditions or bilateral agreements. ``` * This license may not be sufficient in all cases and participants are expected to add more definitions of licenses to be included in the licenses list and this way contribute to iSHARE framework. * In the [structure of delegation evidence](https://framework.ishare.eu/is/structure-of-delegation-evidence) under “Policy” the definition of “type” should indicate that the use of “ISHARE.DELEGATION” is reserved. * The [functional description per role](https://framework.ishare.eu/is/functional-requirements-per-role) (paragraph Authorization Registry) must be amended. * [Secondary use cases](https://framework.ishare.eu/is/secondary-use-cases) must be amended. Since changes are required in the iSHARE Trust Framework this RFC requires a new version of the iSHARE Trust Framework to be drafted, discussed, approved and published. ### Technical documentation Changes in the technical documentation () are required, specifically in the Delegations section. The following changes are foreseen: * The specifications under AUTHORISATION REGISTRY ROLE on will be appended with a specification for the “Policy Creation Request Endpoint”. For the purpose of this RFC the API requirements are specified as OpenAPI 3 specifications and will form an integral part of the technical requirements to an iSHARE certified Authorization Registry. The proposed API specification is hosted [on Swaggerhub here](https://app.swaggerhub.com/apis/GERARDHUISINTVELD_1/policy-management_api/2.1). The structure of the delegationPolicyRequestToken is defined in the [Policy request endpoint](/rfc-impact-analysis-1/rfc034/policy-request-endpoint) section of the developer portal. * Under the REFERENCE section a page will be created holding requirements to the authorisation rules. A first version of the intended page is provided in [Authorisation Rules specification](/rfc-impact-analysis-1/rfc034/authorisation-rules-specification). ### Conformance test tool The conformance test tool must be amended with testing of the newly API endpoint. This is a test that is relevant for testing Authorization Registries. Detailed test cases will be defined and shared before they are implemented in CTT. ### Other documentation Other documentation to be changed: * * * * In reference implementations of an Authorization Registry it would make sense to make a note about the new requirement. ## Implementation ### Release schedule To be decided after discussion in the Change Advisory Board. ### Communication To be defined. # Authorisation Rules | Property | Value | | ------------------------------ | ----- | | Issue reference | #9+ | | Document status \[draft/final] | Draft | > ***NOTE:*** This page will become part of . iSHARE certified Authorization Registries should support the creation of authorisation rules if they choose to implement the policy request endpoint. Authorisation Rules are created by an Entitled Party and contain rules based upon which incoming delegation requests (using the policy creation endpoint /policies) are evaluated and automatically created or refused. There are no technical specifications on how the Entitled Party should be provided with the possibility of managing authorisation rules. However the following principles should be followed: * The authorisation rules must use a data license (9998 + additional licenses as applicable) to limit liability on automatically created policies. * The authorisation rules may use ISHARE.DELEGATION as a resource type. * The authorisation rules may implement the iSHARE concept of actions that can be performed on the delegations. Action names here are not prescribed, but as a best practice we suggest to use "ISHARE.CREATE", "ISHARE.READ", "ISHARE.UPDATE" and "ISHARE.DELETE" to improve interoperability between Authorization Registries. * The authorisation rules must be limited with rules that work the same as described in . An extra requirement for these authorisation rules is that at least one rule limiting the scope of kind of delegation to be created via this mechanism should be present, preventing “\*” authorisation rules. The Authorization Registry should provide clear information on how the authorisation rules are processed if they overlap. Refer to the guidance section below for further information. > ### Guidance > > The following is not not part of the specifications, but provided as guidance for implementation. > > #### Logic when requesting the creation of delegation policies > > The Authorization Registry should contain logic for handling delegation policy requests when there are overlapping authorisation rules in place. > > An example of a principle that could be followed is: > > * If multiple authorisation rules are present, the most recently added authorisation rules takes precedence over older. > > #### Logic when requesting delegation evidence > > An Authorization Registry should contain logic for handling delegation evidence requests when there are overlapping delegation policies in place. Since the creation of delegation policies can be automated, it becomes more likely that overlapping policies will occur. > > Example of delegation policies can be considered: > > * Directly provided by the Entitled Party (direct delegation policies) > * Provided based on authorisation rules (indirect delegation policies) > > Example of principles that could be followed are: > > * Directly provided policies take precedence over policies created based on authorisation rules. > * If multiple delegation policies are present, the most recently added delegation policies takes precedence over older. > * Within a policy rules should be evaluated in a deny-override manner, allowing a Permit only if all of the rule elements evaluate to Permit. # Policy Creation Request Endpoint | Property | Value | | ------------------------------ | ----- | | Issue reference | #9+ | | Document status \[draft/final] | Draft | > ***NOTE:*** This page will become part of . The Delegation policy request endpoint is an API endpoint that receives policy creation requests. The POST body accepts a JWT token: the Policy Creation Request Token. The implementation of this endpoint is not mandatory. ## Request ### Request HTTP methods * POST ### Request headers | Name | Type | Description | | ------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authorization | String | OAuth 2.0 authorization based on bearer token. MUST contain "Bearer " + access token value. How to retrieve the access token can be found at Access Token Endpoint section. | | Content-Type | String | Defines request body content type. MUST be equal to *application/jwt*. | ### Request body The body contains a JWT. ### Request example ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ > Content-Type: application/jwt POST /delegationPolicy { "delegationPolicyRequestToken": "eyJ4NWMiOlsiTUlJRWx6Q0NBbitnQXdJQkFnSUlKWGdMMHBKK0lvQXdEUVlKS29aSWh2Y05BUUVMQlFBd1NERVpNQmNHQTFVRUF3d1FhVk5JUVZKRlZHVnpkRU5CWDFSTVV6RU5NQXNHQTFVRUN3d0VWR1Z6ZERFUE1BMEdBMVVFQ2d3R2FWTklRVkpGTVFzd0NRWURWUVFHRXdKT1REQWVGdzB4T1RBeU1UVXhNVFEyTWpaYUZ3MHlNVEF5TVRReE1UUTJNalphTUZneEt6QXBCZ05WQkFNTUltbFRTRUZTUlNCVVpYTjBJRUYxZEdodmNtbDZZWFJwYjI0Z1VtVm5hWE4wY25reEhEQWFCZ05WQkFVVEUwVlZMa1ZQVWtrdVRrd3dNREF3TURBd01EUXhDekFKQmdOVkJBWVRBazVNTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUF4KzlvQUxqam9sMitMeVl3TnlSekpqZ0IyWlIxaUtQVzRiMHRmL041ZnkyZUFPS3dFTElOTkRxNlU5M00vdlVxWXBkVlVqV1VVZjQrZ3ZxTW00UGUwdUZhWDlXTEJ6WWQvMGNQcUlmd3l5ZDgzeGhlMk1MeEExSHpPUjJOQUQ1b0oxR1RoRXpWRzQybVlGc0hyVEJRaXcrUHNrNXBWM1B1QlNXc0Q2SUxNOUlBU3BpZlcwSmR0dDdDQU5VeVkvc3l2dmx2ejlKdXhQbjNsc01pT25tLys1ZnpRMFZTS1ZtTEVjUWgyeTBmd0FySWtiQkYxQTNaeG5LWHJLUUVZTllIZmlqVk11VkZVOVQ3QjVTVmFsUVJDUjY0ZUdNeTA5Rm53ZGJWOEVUZTMwYnhsamx6QjAzeWhNbFllS3BnY3ZkRlBHN1BkNzZIKyszS3JDdnJxS0FuZFFJREFRQUJvM1V3Y3pBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkJZODV5RHAxcFR2SCtXaThiajh2dXJmTERlQk1CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRkJ3TUJNQjBHQTFVZERnUVdCQlNwcmZuMnVvWUNTRC9rMUhURit6YnpPdU9UN3pBT0JnTlZIUThCQWY4RUJBTUNCYUF3RFFZSktvWklodmNOQVFFTEJRQURnZ0lCQUxxaURza0c3RXczelloVTJSUXBOUU50MEtocy9tZDFmUDVMYzFxTUQvVlhVSWFpaC9DM3daRVF2UjhoaFFYTGVNNzlxSDNIeDhUSjJ0eDBubUU1N1FnV3pVdjBINEMrbGYyak93eExyZytwVksyVzRxUmEzNmZiSkdMd2FONW9CVnJEejhuT0F2RXFZUVZ0ckdsVlVNbGFYNkF6dVpJT2J1cW9RNHdQNTdrV1ZHdTdaUitYdzlxYk5qK2RNNjEzOUxGSGV4MHlDeXg5NHF1Q2ZaM254eEVnN3ZjaTUvS3ErMEFSZjJxbG1RdlozSm14dXdEMEZTQS9TVi9QWkhLcFk1NVl4M0hFR01oeVVyT0Z3OVY2d015TllUTWIyUmVRUzJyQ0h1UXhTcGg0eVErZTNEc0dkcWxTM01JYS9hYzN6SXRCR2RDVXZGQ092cHdBOUpxNHJNV3Q4Ulh2ZUNQYkNuM0ZteUsrSFpTV001M0VCM1pFUk9lK0FJMWN5NnhhbGxac21iRUY1MHFXeVh3UEJ6WExpNU1ZcmNXUmZYOFI0RUxWYnRxTWR2YWIyN2JtR0Z4UVBuTmIxOElSd05BNjVrMkFrbVc1Tjd0dXFoZGNaSnl4Uk84MDJUTDJ0V3dxRStzQjdIQS9ReXRZb0wxOUticnUvbHg2a2FwVEdrWldzSHhERVBMOUNIaDZNS3VUY3dFMWcwbkJ2OUwwbGhGQWFkWmU2QlpEbWdJak1tbW54aGszc1lLTW5Lc2Yrc083WlUrOSt3dER6U3E0UTNMUlJmNUpJQWdRZU9rMjBjejRjdkVKbEgyMHUrL3hEeGpoL1BWVW4vS1h0UVJRY2ZMNk1OV2JoSExUTmpPenBLZGw2OGJCMXVseDF3MHJMUStLRTRWR1pYMFB1MTM2IiwiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0RFFwTlNVbEdZMVJEUTBFeGJXZEJkMGxDUVdkSlNWTkdVa3AzUjBGQmVXcFZkMFJSV1VwTGIxcEphSFpqVGtGUlJVeENVVUYzVWtSRlZrMUNUVWRCTVZWRkRRcEJkM2ROWVZaT1NWRldTa1pXUjFaNlpFVk9RazFSTUhkRGQxbEVWbEZSVEVSQlVsVmFXRTR3VFZFNGQwUlJXVVJXVVZGTFJFRmFjRlV3YUVKVmExVjREUXBEZWtGS1FtZE9Wa0pCV1ZSQmF6Vk5UVUkwV0VSVVJUUk5SR041VFhwRk1VMVVVWGhOTVc5WVJGUkplazFFWTNsTmFrVXhUVlJSZUUweGIzZFRSRVZhRFFwTlFtTkhRVEZWUlVGM2QxRmhWazVKVVZaS1JsWkhWbnBrUlU1Q1dERlNUVlY2UlU1TlFYTkhRVEZWUlVOM2QwVldSMVo2WkVSRlVFMUJNRWRCTVZWRkRRcERaM2RIWVZaT1NWRldTa1pOVVhOM1ExRlpSRlpSVVVkRmQwcFBWRVJEUTBGcFNYZEVVVmxLUzI5YVNXaDJZMDVCVVVWQ1FsRkJSR2RuU1ZCQlJFTkREUXBCWjI5RFoyZEpRa0ZRZFdWU1dGVkhVMVZuZFRkeGNFRlhTbXBCVmtnNWVqTXhPVmh1ZFVac1pWWmxUeTlZZUdKS05sVTBhWGhZVWt0MlZ6aDJTMVJXRFFveFpGSmpabEZsUTNGWWF6ZDFZUzlhYzNGT2NuRTRPVVY0T1RWaU1HNXhSMVYyTVU1dlN6SlVPSGxGUVd0UmVubDZXVnB3VnpSak1sbE5RMk5uTldGdERRcFNkME5tV1dGb1NIUktiVmhLVjNGU1JXVjJUVFZyU205UFlXTkxTQzlIVldKelpXMVVPVFJDTUV0WVUwNVJOa2xYWTBwNWFuQjFZVzlFY0dJMlYyUTVEUW8zVkRKc2RWQXhTVkUxWjJ0bWQxVXpPRU5hU2t0V2EySlpNMlZLYTB4c1QzZDNkRVp6UmxCUU1rMDBaamgxTkRjNVQydE5WWEkxTDIwcmVHNDNNMHBoRFFwYVUwcEdUMGgyU1U0MlJFWndRV3h6TW1GNE4wSm9WVk5zWWt0Tk0xbEZkVTVpTUU4MGIwODFlVzVFUmtoMmJXeHNjRFpPZFRCR01saHZNRUoxTUZBdkRRcDFjV0l2TURoWWRsWlhibVUzZDJOM1YxcFNPU3RrTnpoeEswOXNaa012YlN0M1FYZEJjVzFSU0VWeU9HaEtUblpTTmxNdk9EUklRV3BWWkUxNVIyTlpEUXBVZG05Mk1IUmlNRnAzTDBGTGQwUm5PRkJET1ZWR1VsbGlNR05DY2pBckwwZG1aMjFLVURWUlRVRm1USEZyV0cxYWQxbFJVMW94Um1GdFRteEtiRzE0RFFvd2MxbGFVVk5oZFdSSE1DdFlhMk01T1RFclduY3ZlRGgxVjFwcE9YRlJXbVZDVDJSM2Jra3llR1l2U0VwWVNFcHpZVnBtUkhaVWNEVnBPR2xXVURjMURRb3hjbWhwYm5kTWFUSmtXbTV0VTNOUk9UWm5kblJVVVVKdk5FbzFRWFpHSzNNNVNXd3JWSFZyWlV4MGJFdEJRbUZ2VFhkNk9IZFpRa051Wmt0MlZYUnJEUXB3TjBwVk5XbHFhbGxHWVhGUmMwWlNNMUp3VDBoWVkwZ3ZjM0JhVkZsSWRWTnpNVTl3U0ZaaWNqQXZZMFowVjFwd2RqUjBVMUZyYkZCeFEycGtaRk5CRFFwVFNEbHJNMDlDUVdoNFpXNTVXRXhyYmpsVk9VRkJTVE0wY0ZwaVJsWXJiV3R6UjBkeVRqZDFhMnMwYjJKVGRFazNlaTgxUVdkTlFrRkJSMnBaZWtKb0RRcE5RVGhIUVRGVlpFVjNSVUl2ZDFGR1RVRk5Ra0ZtT0hkSWQxbEVWbEl3YWtKQ1ozZEdiMEZWY21FelMzTlVibFZXYmxrNFMxaG5iREJTYVdsUlFuUnZEUXBMUlhkM1NGRlpSRlpTTUU5Q1FsbEZSa0paT0RWNVJIQXhjRlIyU0N0WGFUaGlhamgyZFhKbVRFUmxRazFCTkVkQk1WVmtSSGRGUWk5M1VVVkJkMGxDRFFwb2FrRk9RbWRyY1docmFVYzVkekJDUVZGelJrRkJUME5CWjBWQlpVbEtkekZ1Ym05UGNuTmhiWFZsVnpSaldsQk1lbkp1ZFVoVFJYWjJNVk5GVERGaURRcG1RalpHTnpOaGJtMTRZbkU1SzA5WlZ6WnhiMnBvZUhadmNraFVSbnB2VVhsdWMxQnRZbk52TjNRMFlqTklRWFJYWVU5c2NETkVTMXBWVkhCNlQyeE1EUXB1VVRsbmMwUkVaa1JXVTBwelNqVnFlR2RzUkVaYWJUQkJNRGRNWkRORGVGcG9ibnBYWmpsQk1GRm5UbkZPTldoRFkwOXpjbXcwZFVSTmRscDZLMDA1RFFwclRDOXBhM05EZURSWU1ITnZNazlUYlRGUllXdHlZVUZTTTNWdFVHTXliMjlCWVdOUWMwRldRMnhzWld0WVJrbzVSRVpxU2pWVmRpdHlaemhhUzBoSURRcE1SM0pRTVRsdkwwRnpXRXBaY0V0UUwzUjBhelYwUW5WQk5FcENNakJoVTJoaVkwTTFNemx5UVN0Ull5dHJSRWg1VW01TU1HRktlVkpaWlVKbldURnBEUXBCZEhWNldIcE5UMnMxTTFoV0syRktiMmRFY0ROblJqY3pjekZqTVZsNVNWSklkRGR2WmxGSEx6QmFiSGRqTHpReFEzaFBSQ3RzZVhwSE16UlNhMmRKRFFwVlR6WlZabXBwUjBOR1VHMWFVVEpJYTNCTGVYRk1hV1p5WVZKa2NYSklXRTlvYjFaa04waHBaRmxKYVdodVdrdEVhMHhwTVdObVpXOHliWG80ZEZkcERRcFZla0VyWkZCamFHRkpSV3h3VVVwUVZHcFRZa3hxUmpKSk1UbFJlVUk0Wm5WUVlYcFFaazVKYWtoeVdHRkxiR0ZUTTJ4MVMyTkdhWEZQV1dkamQxZG1EUXBrV20xRWVuaEpWVFpRV1RKaWVuZ3ZVMFJOYjFVeU5ISkJWbE4xUjBGWlFrbEJiSGRtTW5CNGJYUk1ZMkpOUVRaaVdYSTBkSEp0VVdaaVNuSk5PR1k0RFFwS1dtZEhVVzlKZEhKd2VuSkxha0pLTW1kR1VuUXJNRFkxVGsxVVRtdENOWEozT0ZoeU5UWnFOV1JxYTNGQ01DOXhTRWxqUmpKVWFWa3ZheTg0TVZKdERRcFVRMWw0Y2xaSWVrMHhZM3BvV0VoWVdYcDJibVF5U213eGQwcFllV0ZqVjJ3M1JtbFFZV2RuZHpCWlVXbGtWMGhIVFdSSmRFVjFSQzg0VTFocFExaHNEUW94VDBsMmRtbGpQUTBLTFMwdExTMUZUa1FnUTBWU1ZFbEdTVU5CVkVVdExTMHRMUTBLIiwiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0RFFwTlNVbEdZbFJEUTBFeFYyZEJkMGxDUVdkSlNVaHFhbVpVZFZOcVJtcE5kMFJSV1VwTGIxcEphSFpqVGtGUlJVeENVVUYzVWtSRlZrMUNUVWRCTVZWRkRRcEJkM2ROWVZaT1NWRldTa1pXUjFaNlpFVk9RazFSTUhkRGQxbEVWbEZSVEVSQlVsVmFXRTR3VFZFNGQwUlJXVVJXVVZGTFJFRmFjRlV3YUVKVmExVjREUXBEZWtGS1FtZE9Wa0pCV1ZSQmF6Vk5UVUkwV0VSVVJUUk5SR041VFhwRk1VMUVWWGhOTVc5WVJGUkpORTFFWTNsTlJFVXhUVVJWZUUweGIzZFNSRVZXRFFwTlFrMUhRVEZWUlVGM2QwMWhWazVKVVZaS1JsWkhWbnBrUlU1Q1RWRXdkME4zV1VSV1VWRk1SRUZTVlZwWVRqQk5VVGgzUkZGWlJGWlJVVXRFUVZwd0RRcFZNR2hDVld0VmVFTjZRVXBDWjA1V1FrRlpWRUZyTlUxTlNVbERTV3BCVGtKbmEzRm9hMmxIT1hjd1FrRlJSVVpCUVU5RFFXYzRRVTFKU1VORFowdEREUXBCWjBWQk5FaEpVVEpsUjFoVFVEQmljV2RQY3paSlluSjRWSGN2TUhVMldIbFNhVFZJTDFvcmFqaG9VSHBHWlZNdmJqZFZZMFJ6S3pRNFIxbFRaMFZPRFFveFkwbEVRa0ZIVjJwdWQwNU5OblUwVW5CUmFVYzRlR3czV1hScVYzbHRkMHR0TkVoWWRFeEJVWEYwTnpKaGNsa3pOMUJUUmpNd1dHazJWbEJDWVc1MERRcFFWR1JoWVNzNWVrTlZPRU41Um01RldqSm1TMVJyTVZOMVp6TTJaelpHTms5cVpHZERRMGRyYW1Sd2NFdFdlVTVKYkRWUFZ5dHJha1p4TWtFNVIzWjBEUXBDVWtkRmQxSXlaWFJ2ZEV0MGMwbElTUzluTkdOWVQwWmFhblJEUTNSUWIwVnRhbEUyTm1aVGQyRTNRV3B2YkhCQ1lqSlFZM056UTFad1lqVmpObk5CRFFwbWNESXdTazV1T0RSclJGRkZiMGhxWlc5NVRrRnhZM1JDUlVselVscEdOR3R3Vkc0MFdXaFRXSEV3VkVndmExSjBSVVZtVGtWdGVreEZUMU5oUkZkUURRcDVURGh4U2twd2VERmhVRUY1WlRCbWEwZG1TbWsxTVdOSFVuSkdlR1kzYW1aT09UbFVhbVJtTTNsNGQzUlVMM2xSY1hWWFRIQTJWa3hrY1dwS1RHczVEUXBpZEVkckswSnBVemxwVm5SM05ERkZZeko1YzFndk0yY3dlR1ZXVmtaSGRIbERkMEZEVjNCNVNYZ3JVVzA0TUV0cVZsaHJXVVI0YUVkcFRGRnFVVWw2RFFwV2IyeFFSVlpWUkVGYWJuY3JURU50WnpOUFdUbEplVEJRV0ZSV01IZ3pRMHRJVFN0RE0zVnJXbGRyVXpGa00wTlRaMFJXYkRFclkzQklTbFEwYlRabURRcExibTVqVHpjM2VWWlBNSGx5VnpVeU1UaFZSMkZaUVV4UGFEaFFTRzkzTXpabE9XTkNNbU13WWxReVpERkRTRkpsYTFOc05DdENlQ3Q0VVUxSGQzTlFEUXA1ZG1WSFozQnJTR2xrV25SWlVrUlFORVV2U0hoT1Mza3JkMlpDZVZGbFUzVTBXV05WWXpoRlNIaDVPWEY2ZUdGbE1qaFJabHB1TjNNME4xWXZVR3BCRFFwck1HUk1XbmxSUkc5dVJUbFJNVEJQYTAxV01UVkVjRGxRVjBkbFExRktjbWsxU21SUGJuSXJhVVE0UkdSSWMwTkJkMFZCUVdGT2FrMUhSWGRFZDFsRURRcFdVakJVUVZGSUwwSkJWWGRCZDBWQ0wzcEJaa0puVGxaSVUwMUZSMFJCVjJkQ1UzUnlZM0Y0VDJSU1YyUnFkM0JsUTFoU1IwdEtRVWN5WjI5VVJFRmtEUXBDWjA1V1NGRTBSVVpuVVZWeVlUTkxjMVJ1VlZadVdUaExXR2RzTUZKcGFWRkNkRzlMUlhkM1JHZFpSRlpTTUZCQlVVZ3ZRa0ZSUkVGblIwZE5RVEJIRFFwRFUzRkhVMGxpTTBSUlJVSkRkMVZCUVRSSlEwRlJRa05IV1U1c0x6RklSbGRXYUVSdlVHMXJjRlp4YlRNd2NubHhaalprVjNneGNuaFVWekZzYXpsaERRcFdWVTlzVWpsSlVraFFjREY2TDBZdk5HWmlObTFKV0VacVJsbDNOV3hWTW1aaFNGWTViM0EwY2s1MVIzRlNVbE5NYVZGUVZuWlBXSGhFYkhoeFFUWkVEUXB0Y1hwcFVrVjJkSFJITUhWTVdpOUdUM2xqUzFrMU0zQlhSa042UnpKclpYRTJUMGxrT1VwVGNFWnRVVVJQYVVZM1YxTjFhV1pRVEhWM1FVUnJWWGNyRFFwdldsbEhaMWR0WW5kUlR6QnNXSFIzTjFoUGJua3pOMjVNV210WmJEZzVZbEpvU1djdk4yWmlLMWh1WWpnNU1UUlRUWFl3YTBkc2F6RnJRMlY1VERaR0RRcFlaRmhTVkdGaGREVmpPVmhzU25JNWVYcFBWVWxFYmpVMFlsa3hRa3RVTmxsMGFYbEtablpEVG1GMkwwWmlNalIyTldWeE1sbzViVUprV2pjd1EyTTVEUW8xWjFCcWNYRjRUVnBWWjBwdk5UZFpkbWhNWmxoRWQzaGlWMXBYV1VNclYyTlNPRzVJYTFrcmRGcENiRWxwYURKRFdFaHpUMkZ5Tlc5SU5tUnlUV1IwRFFwTlNWcDZNMVZhU2k5RGVFWkhNWFV5TTFWNk1XcENabTB2UldkblpFdG9UMVp1VkRabFpISjFWbTkwWlZkWFEwUkNPVWhrYUhoNk9GSkJWbGx1TldSeERRcFZhbXRxVW5FMFZ6bFJRV1pLZFhOeVVGcEhRbTVrVkRkNVRtRlpMMFpJV1V0SmNTdDFWR0Z5VjJsaWFtUjRkR1JaUTJ4aFZIZFBlR3MxU1hGTFRrWTVEUXBsUTB0aVVHMTRjekZ0YkZweVUweHFUVkZHV1ROVk9WSnJkbnBKS3pOSmJFRkdhMk4wVldWaFluQnJiVmg0Ym5WWFYxTldNa1pLVHpsYWNrOU9UVmQxRFFwMGR5czFOamRRU3pWbmVrMHdSbkZSZG1JM2MwTjRXblZSUkd3MVEzUTJXbGRzZEhNeVdUY3lkRFp3VUdwU1NURTNLMU00S3l0aE1uWlJaSGhDWTA1UkRRb3dlRVl5ZEdwMmVsUjJhVm96UXpWRmNVbGxZWHBYWkdkSldtdHhabGRhYTFNNGRpc3dUVUYyVGxwWksySmllQ3QyVTNkTVQyOUlVVmR5Wmk5UFEwdzNEUXBCVVQwOURRb3RMUzB0TFVWT1JDQkRSVkpVU1VaSlEwRlVSUzB0TFMwdERRbz0iXSwiYWxnIjoiUlMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJFVS5FT1JJLk5MMDAwMDAwMDA0Iiwic3ViIjoiRVUuRU9SSS5OTDAwMDAwMDAwMSIsImp0aSI6ImQ4YTdmZDc0NjU3NTRhNGE5MTE3ZWUyOGY1YjdmYjYwIiwiaWF0IjoxNTkxOTY2MjI0LCJleHAiOjE1OTE5NjYyNTQsImF1ZCI6IkVVLkVPUkkuTkwwMDAwMDAwMDEiLCJkZWxlZ2F0aW9uRXZpZGVuY2UiOnsibm90QmVmb3JlIjoxNTQxMDU4OTM5LCJub3RPbk9yQWZ0ZXIiOjIxNDc0ODM2NDcsInBvbGljeUlzc3VlciI6IkVVLkVPUkkuTkwwMDAwMDAwMDUiLCJ0YXJnZXQiOnsiYWNjZXNzU3ViamVjdCI6IkVVLkVPUkkuTkwwMDAwMDAwMDEifSwicG9saWN5U2V0cyI6W3sibWF4RGVsZWdhdGlvbkRlcHRoIjowLCJ0YXJnZXQiOnsiZW52aXJvbm1lbnQiOnsibGljZW5zZXMiOlsiSVNIQVJFLjAwMDEiXX19LCJwb2xpY2llcyI6W3sidGFyZ2V0Ijp7InJlc291cmNlIjp7InR5cGUiOiJHUzEuQ09OVEFJTkVSIiwiaWRlbnRpZmllcnMiOlsiMTgwNjIxLkNPTlRBSU5FUi1aIl0sImF0dHJpYnV0ZXMiOlsiR1MxLkNPTlRBSU5FUi5BVFRSSUJVVEUuRVRBIiwiR1MxLkNPTlRBSU5FUi5BVFRSSUJVVEUuV0VJR0hUIl19LCJlbnZpcm9ubWVudCI6eyJzZXJ2aWNlUHJvdmlkZXJzIjpbIkVVLkVPUkkuTkwwMDAwMDAwMDMiXX0sImFjdGlvbnMiOlsiSVNIQVJFLlJFQUQiLCJJU0hBUkUuQ1JFQVRFIiwiSVNIQVJFLlVQREFURSIsIklTSEFSRS5ERUxFVEUiXX0sInJ1bGVzIjpbeyJlZmZlY3QiOiJQZXJtaXQifV19XX1dfX0.mdnNbj4b7u6YmCbzxk0Sn2wvceo9dG_7mikMcpxUG4JLf3Yd4dovUL10y_OaqLmSgxe7yYtacV5PPeOvZX4DFXv-aMxF_ueBTgqm1A8GCMfxd5gBO848tUmp0KAJJ-VlRGUDjxZIZ_CEvW8iAXjUhVsbwMDOrzRKvg6O3bBEfiqCowumygOk7oGaYwQP0eF21VvKiGyNAOOm6mw6a9WyCVmFSg3imjbF2H60HI8abnr3-0xGmRo4IuNSX57BplcaKo1GXrJTaTkOTF9vzKKXdrxvoBpnx2VcZqfI69UBGQHZOs4WA7noF3kEyhZR2pP3_8XGvClEExjn_R496m0aaQ" } ``` ## Response ### Response headers | Name | Type | Description | | ------------ | ------ | ------------------------------------------------------------------------ | | Content-Type | String | Defines response body content type. MUST be equal to *application/json*. | ### Response body The body consists of a JSON containing a message and a code. #### Response HTTP status codes / responses Response body does not contain policy information, only the result of the request. 200 OK: The requested policy is created. 401 Unauthorized: When `Authorization` header is either missing, invalid or token has already expired. 403 Forbidden: This error message is return when a policy creation request could not be processed after rules evaluation. The requested policy does not comply with the rules as set by the Entitled Party. 500 Server Error: When the Authorization Registry was unable to process the request **Example:** ```json { "message": "string", "code": 401 } ``` ## Policy Request Token This is a description of the delegationPolicyRequestToken, used in the POST request to the /delegationPolicy endpoint to request creation of a delegation policy. The JWT must conform to the [iSHARE JWT specifications](https://dev.ishare.eu/reference/jwt.html). The structure of the token is very similar to the structure of the [delegation evidence token](https://dev.ishare.eu/delegation/delegation-evidence.html), which is presented in the response of a delegation evidence request. ````json { "iss": "EU.EORI.NL000000004", "sub": "EU.EORI.NL000000001", "jti": "d8a7fd7465754a4a9117ee28f5b7fb60", "iat": 1591966224, "exp": 1591966254, "aud": "EU.EORI.NL000000001", "delegationPolicyRequest": { "notBefore": 1541058939, "notOnOrAfter": 2147483647, "policyRequestor": "EU.EORI.NL000000010", "policyIssuer": "EU.EORI.NL000000005", "target": { "accessSubject": "EU.EORI.NL000000001" }, "policySets": [ { "maxDelegationDepth": 0, "target": { "environment": { "licenses": [ "ISHARE.0001" ] } }, "policies": [ { "target": { "resource": { "type": "GS1.CONTAINER", "identifiers": [ "180621.CONTAINER-Z" ], "attributes": [ "GS1.CONTAINER.ATTRIBUTE.ETA", "GS1.CONTAINER.ATTRIBUTE.WEIGHT" ] }, "environment": { "serviceProviders": [ "EU.EORI.NL000000003" ] }, "actions": [ "ISHARE.READ", "ISHARE.CREATE", "ISHARE.UPDATE", "ISHARE.DELETE" ] }, "rules": [ { "effect": "Permit" } ] } ] } ] } } ``` ```` # RFC042 | Document property | Value | | ------------------------------ | ----- | | Issue reference | #1+ | | Document status \[draft/final] | Draft | ## Background and rationale With [RFC028](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/main/RFC%20Documents/RFC028/README.md) iSHARE has move to a federated model. This has led to changes in terminology being used for roles throughout the iSHARE Trust Framework and other iSHARE documentation or assets. Additionally, other initiatives like [IDSA](https://internationaldataspaces.org/) and the [DSSC](https://dssc.eu/),and new regulations like the [Data Governance Act](https://digital-strategy.ec.europa.eu/en/policies/data-governance-act) have introduced terminology as well. ## Proposed change ### Purpose This RFC aims to clarify the terminology used for [roles in iSHARE](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) and map its alignment to the terminology used with other initiatives and regulations. It proposes the renaming of two iSHARE roles and proposes changes to align and clarify documentation. ### Description and principles It’s important to acknowledge that iSHARE provides a role framework that can be applied to legal entities. The roles should not be confused with the naming of technological solutions that are required to fulfill those roles. The iSHARE Framework does provide specifications on which technological aspects a role should implement (security requirements, API requirements), but it doesn’t specify what solution(s) should fulfill those. The following table presents the current names of iSHARE roles, in the second column in *bold* roles that will be renamed with the implementation of this RFC and in further columns a comparison with other initiative. When drafting this impact analysis, we concluded that it was not possible to create a one-on-one mapping between iSHARE defined roles and roles used in other initiatives. This is caused by the fact that all initiatives have a different approach and look on the topic. Nevertheless the community involved in data space in general and trust in particular would benefit from an overview of how the different initiatives use roles as a concept, what the particular roles mean in all frameworks and how they are related to each other. The following table can form a starting point for such an analysis. #### Adhering roles | [Current name in iSHARE](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) | New name | Other names currently in use for this role | In [IDSA](https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4/layers-of-the-reference-architecture-model/3-layers-of-the-reference-architecture-model/3-1-business-layer/3_1_1_roles_in_the_ids) | In [Dataspace Protocol](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/overview/model) | In [Data Governance Act](https://digital-strategy.ec.europa.eu/en/policies/data-governance-act-explained) | In the [DSSC Blueprint](https://dssc.eu/space/BVE/357073672/DSSC+Glossary) | | -------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Service Consumer | Service Consumer | Data Consumer, Data User, Data Recipient | Data Consumer | Participant, fulfilling their technical requirements using a ParticipantAgent | *Data user* | [Data product consumer](https://dssc.eu/space/bv15e/766062077/5+Data+Products+and+Transactions) | | Service Provider | Service Provider | Data Provider, Data Node | Data Provider | Participant, fulfilling their technical requirements using a ParticipantAgent | *Data holder* | Can be [Data product owner](https://dssc.eu/space/bv15e/766062077/5+Data+Products+and+Transactions) or [Data product provider](https://dssc.eu/space/bv15e/766062077/5+Data+Products+and+Transactions) | | Entitled Party | Entitled Party | Data Owner, Data Holder | Data Owner | *Not present* | Can be *Data subject* or *data holder* | Can be [Data product owner](https://dssc.eu/space/bv15e/766062077/5+Data+Products+and+Transactions) or [Data rights holder](https://dssc.eu/space/BVE/357073819/6+Data+products+and+transactions) | #### Certified roles | [Current name in iSHARE](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) | New name | Other names currently in use for this role | In [IDSA](https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4/layers-of-the-reference-architecture-model/3-layers-of-the-reference-architecture-model/3-1-business-layer/3_1_1_roles_in_the_ids) | In [Dataspace Protocol](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/overview/model) | In [Data Governance Act](https://digital-strategy.ec.europa.eu/en/policies/data-governance-act-explained) | In the [DSSC Blueprint](https://dssc.eu/space/BVE/357073672/DSSC+Glossary) | | -------------------------------------------------------------------------------------------------------------------- | ------------------------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity Provider | Identity Provider | Human Identity Provider | *Not present* | *Not present* | *Not present* | Not explicitly mentioned, but can be seen as a [Trust anchor](https://dssc.eu/space/BVE/357073860/9+Identity+and+trust) | | Identity Broker | Identity Broker | -- | *Not present* | *Not present* | *Not present* | *Not present* | | Authorisation Registry | Authorisation Registry | -- | *Not present* | *Not present* | Part of a data intermediation service | Not explicitly mentioned, but can be seen as a [Participant Agent Services](https://dssc.eu/space/bv15e/766061973/4+Data+Space+Services) | | Satellite | **Participant Registry** | -- | *Not present* | Not present, this role will likely fulfill it’s technical requirements by using a Dataspace Registry (similar to the iSHARE Satellite reference implementation) | *Competent Authorities* for both *data intermediation services* and *data altruism organisations* | A combination and/or parts of [Data Space Registry, Registry, Validation & Verification Service, Compliance Service, Notary, Intermediary, Federation Services, Data Space Intermediary, Conformity Assessment Body, Common Intermediary](https://dssc.eu/space/bv15e/777333342/Alphabetical+List+of+All+Defined+Terms+in+Blueprint+v1.5) | #### Other relevant roles These roles are necessary in the framework and data spaces context however, they are not necessarily registered as participants. The roles will still be essential to enable trusted data sharing and governance around it. | [Current name in iSHARE](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) | New name | Other names currently in use for this role | In [IDSA](https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4/layers-of-the-reference-architecture-model/3-layers-of-the-reference-architecture-model/3-1-business-layer/3_1_1_roles_in_the_ids) | In [Dataspace Protocol](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/overview/model) | In [Data Governance Act](https://digital-strategy.ec.europa.eu/en/policies/data-governance-act-explained) | In the [DSSC Blueprint](https://dssc.eu/space/BVE/357073672/DSSC+Glossary) | | -------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Scheme Owner | Scheme owner | -- | *Not present* | *Not present* | *Not present*\* | [(Data Space) Support Organisation](https://dssc.eu/space/bv15e/777333342/Alphabetical+List+of+All+Defined+Terms+in+Blueprint+v1.5) | | Satellite Administrator | **Participant Administrator** | -- | Certification Body And Evaluation Facilities | *Not present, this role will likely fulfill it’s technical requirements by using a Dataspace Registry (similar to the iSHARE Satellite reference implementation)* | Operational part of Competent Authorities | [Validation & Verification Service, Compliance Service, Notary, Intermediary, Federation Services, Common Intermediary](https://dssc.eu/space/BVE/357073860/9+Identity+and+trust) | | Satellite | **Data Space Governance Body** | Data Space Coordinator, Scheme Satellite, Data Space Governance Authority | Dataspace Authority | Dataspace Authority | May be considered equivalent to European Data Innovation Board (EDIB) | [(Data space) governance authority](https://dssc.eu/space/BVE/357073747/2+Core+Concepts) | \* In context of Data Governance Act European Commission could be considered Scheme owner (of Data Governance) ## Impact on the ecosystem This RFC: * Renames the current role of `iSHARE Satellite` to **Participant Registry (certified role)**. This role is fulfilled by the legal entity that is responsible for the operational processes as defined in a data space. This is a certified role and the `Participant Registry` must be certified by the `Scheme Owner`. * Introduces the role of **Data Space Governance Body (other role)**. This is a role (currently assumed to be taken by the `Satellite`) which is responsible for data space, including the defining, evolving & maintaining and governing of participant lifecycle processes. This role can be fulfilled by a legal entity or by a non legal entity (a group of parties with a certain governance). For reference, the definition of data spaces can be based on the [iSHARE Data Space Template](https://template.ishare.eu/) and this body is responsible for defining, evolving and governing the building blocks there in. Legal entities can have both roles simultaneously, or a `Data Space Governance Body` could use (contract) a legal entity to fulfill the role of `Participant Registry`. To clarify that this role is not a formal part of the trust framework (although a relevant role), the role will be labeled as `Other relevant role`. To align with the deprecation of the term `Satellite`, the role of `Satellite Administrator` will be renamed to: * **Participant Administrator (other role)**: This can be a party (contractually) working under `Participant Registry`, facilitating the operational process execution. Note this is not a formal role, however, a `Satellite/Participant Registry` may choose to outsource parts of their execution responsibilities to a 3rd party: the `Participant Administrator`. From the framework perspective, the Participant Registry remains liable and responsible even for the outsourced parts. These changes will be reflected in relevant documentations and communications going forward. Impact on the assets maintained by iSHARE Foundation is given in the next section. Participants are requested to adopt the updated naming conventions in their documentations and communications. ## Impact iSHARE Foundation (Scheme Owner) iSHARE Foundation will review all current assets and work on consistent use of roles as defined in this RFC. As the roles are heavily used throughout all of the documentation, the overall impact of this RFC is large. The following assets are impacted: * The [iSHARE Trust Framework](https://framework.ishare.eu) * The [developer documentation](https://dev.ishare.eu) (as an extension of the iSHARE Trust Framework) * The OpenAPI definitions on [Swaggerhub](https://app.swaggerhub.com/search?owner=iSHARE) * Example implementation in [Postman Collections](https://dev.ishare.eu/demo-and-testing/postman.html) * Code that is published on Github: * [iSHARE Satellite reference implementation](https://github.com/iSHAREScheme/iSHARESatellite) * [iSHARE.NET service consumer core components](https://github.com/iSHAREScheme/iSHARE.NET) * [Python iSHARE package](https://github.com/iSHAREScheme/python-ishare) * [iSHARE code snippets](https://github.com/iSHAREScheme/code-snippets) * [Reference implementation for Authorization Registry](https://github.com/iSHAREScheme/AuthorizationRegistry) * [Reference implementation for Service Provider](https://github.com/iSHAREScheme/ServiceProvider) * The implementation of the iSHARE satellite for iSHARE as the Scheme Owner on and * The [public website](https://www.ishare.eu) * Internal documentation * [Authorization Registry test implementation](https://ar.isharetest.net/) * The [Conformance Test Tool](https://ctt.isharetest.net/admin/account/login), tests listed on * iSHARE test satellite (used for conformance testing): * iSHARE test certificate authority: [EJBCA Public Web](https://ca7.isharetest.net:8442/ejbca/) * [Support site](https://support.ishare.eu): a document will be created to explain the relationship between roles models of different initiatives The following assets are NOT impacted: * Code that is published on Github: * [eSEAL certificate procurement guide](https://github.com/iSHAREScheme/eSEALsGuide) * [iSHARE Change Management documentation](https://changes.ishare.eu) ## Implementation ### Release schedule The expected implementation time is around 2-3 months after deciding on the implementation of this RFC. ### Communication The implementation of this RFC will be actively communicated with the community. # RFC045 | Document property | Value | | ------------------------------ | ----- | | Issue reference | #12+ | | Document status \[draft/final] | Final | ## Background and rationale One of iSHARE's main principles is that organisations can become participant of a data space based on the iSHARE framework. Once an organisation is a participant, organisations are trusted by other data spaces that are also based on the iSHARE framework. Data spaces can optionally require additional trust requirements for their participants. Members of a data space can communicate with participants of all data spaces within the iSHARE network, based on the trust that is provided by the iSHARE Trust Framework. To support interoperability, the iSHARE Satellites are currently connected using a distributed ledger. This leads to better discoverability of participants and easier onboarding for participants in multiple data spaces. This technology however, is not part of the iSHARE Trust Framework itself. Closely related to this RFC are the following RFCs: * RFC044: #2+ * RFC040: #5+ * RFC031: #11+ ## Proposed change ### Purpose This RFC started with the requirement to accommodate an approach where the trust perimeter is less strict: a perimeterless approach, i.e. a zero-trust network. Organisations can interact with other organisations based on a more specific level of trust. Level of trust requirements could for instance be membership of an iSHARE based data space, membership of a specific data space, or other credentials (such as a certain certification, or a recommendation by a data space member). In principle, iSHARE already accommodates this approach. With this RFC however, we want to further clarify how to implement this scenario with iSHARE and identify possible improvements in the iSHARE Trust Framework. This RFC supports the goals of iSHARE and complies with all [guiding principles](https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70222189/Guiding+principles), strengthening international orientation (principle 6). ### Description and principles To accommodate the idea of a zero-trust network, Verifiable Credentials **may** be used. This change is covered in RFC040: #5+. In general, the following logic will take place when **a Service Consumer requests a service from a Service Provider**, based on a Verifiable Credentials approach. * The Service Consumer provides it's identity (either via the existing way, or via a Verifiable Credential (see RFC040: #5+)) * The Service Provider decides if there is a need for additional credentials and if so, requests this from the Service Consumer (using a [Verifiable Presentation Request](https://w3c-ccg.github.io/vp-request-spec/)) * The Service Consumer provides the additional credentials (using Verifiable Credentials) * The Service Provider decides if the service can be provided * The Service Provider fetches the required delegation evidence from the Authorisation Registry, or the Service Consumer provides the delegation evidence * If all required delegation evidence is present, the service is provided The current iSHARE specification is also able to solve this. Irrespective of which method is chosen, the iSHARE Trust Framework provides legal coverage. Existing iSHARE data spaces are not affected by this change, which makes this change backwards compatible. ### Example use cases > **Example implementation: nested data spaces** > > This RFC supports the idea of data space *branches*. Let's take the following example. > > * Consider the data space `Inland Shipping NL`, where > * `Inland Shipping NL` is a branch of `Shipping NL`, and > * `Shipping NL` is a branch of `Logistics NL` > > Example of nested data spaces diagram > > A Service Provider (member of `Inland Shipping NL`) receives a request to consume a service by a Service Consumer. The Service Provider could decide *on behalf of the Entitled Party* to deliver it's service with a following logic: > > * If the Service Consumer is also member of `Inland Shipping NL` (Service Consumer A) AND the correct Authorizations from the Entitled Party are present, the service can be delivered > * If the Service Consumer is not member of `Inland Shipping NL`, but is member of `Shipping NL` (Service Consumer B), the Service Provider requires extra credentials AND requires the correct Authorizations, after which the service can be delivered > * If the Service Consumer is not member of `Inland Shipping NL`, but is member of `Logistics NL` (Service Consumer C), the Service Provider requires even more credentials AND required the correct Authorizations, after which the service can be delivered > > This concept helps in achieving trust interoperability. Of course other types of interoperability (specifically technical and semantical) are required to become fully interoperable. > > Extra credentials can be anything, for instance: > > * Membership of an industry organization > * An ISO certification > * Proof of past behaviour (successfull deliveries) > * Etc. Of course this is just an example. The 'nesting' of data spaces is not required. A participant can be member of any number of iSHARE based data spaces and present credentials as and when necessary. These data spaces don't require any relationship other then that they are both based on the iSHARE framework. ## Impact on the ecosystem The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role). | Formal role | Technical impact | Business / legal / functional / operational impact | | ------------------------ | ---------------- | -------------------------------------------------- | | Service Consumer | no | no | | Service Provider | no | no | | Entitled party | no | no | | Authorization Registry | no | no | | Identity Provider | no | no | | Identity Broker | no | no | | Data Space Administrator | no | no | | Satellite | no | no | This change will only impact the framework and documentation maintained by the Scheme Owner. ## Impact iSHARE Foundation (Scheme Owner) A preliminary impact analysis is that the following assets are impacted: * The iSHARE Trust Framework: : prepares it for the approach that is described in this RFC. Other assets are impacted with the implementation of other RFCs (RFC040 and RFC044). * The public website , for providing extra guidance on this approach. * The developer documentation (as an extension of the iSHARE Trust Framework): . We don't expect any changes in for example API endpoints, but clarifying texts might be changed. * The external support documentation on needs to be updated. During implementation it might become clear that other assets are impacted as well. ## Implementation ### Release schedule Work on implementation is not dependant on other RFCs; implementation can be done in a few weeks. ### Communication Changes will be included in regular iSHARE communication. No special communication is required.