<!-- review-site:start --> > [!important] Documentation change package > The proposed documentation changes of RFC044 are ready for review: **[open RFC044 on the review site](https://preview.ishare.eu/rfc/RFC044.html)** <!-- review-site:end --> # **Background and rationale** Some data spaces do not wish to implement a Participant Registry that is connected to a distributed ledger. Reasons include technical complexity, independent nature of data spaces and adoption improvement. The distributed ledger already is not part of the iSHARE Trust Framework. Functional requirements per role define the Participant Registry by its onboarding processes, service levels, level of assurance, AR discovery obligation and registration, with no reference to a backend technology. The ledger is however a property of the reference implementation. The documentation does not fully and consistently reflect that. The Developer Portal Participant Registry introduction states that the registry "is built on a Distributed Ledger across all data spaces" and ties cross-data-space interoperability to that fact. The Trust Framework service-level reporting section takes a different position, treating a standalone registry "(disconnected from the distributed ledger)" as a recognised but exceptional case. The current parties-and-claims model supports operation without a ledger. RFC061 (released in 2.2) added optional write operations on parties and claims, with a signed iSHARE JWT in the request body and an OPTIONS method so a registry can declare which methods it supports. RFC064 (released in 3.0) split participant information into base party information plus claims, so that a registry other than the registering one can add data space membership, roles, agreements and AR selection. Party lifecycle management is therefore already specified as an API and governance matter. RFC064 also records a limitation. The exchange of claims between Participant Registries is expected to run over the distributed ledger. A registry not connected to the ledger cannot expose claims registered by other Participant Registries, and non-connection may lead to duplicate records for the same party. The residual ledger dependency is therefore not in the normative framework text. It sits in the documentation wording, in the reference implementation, and in cross-registry claim exchange. ## **Proposed change** ### **Purpose** Confirm that the iSHARE Trust Framework permits a Participant Registry without a distributed ledger, correct the documentation where a ledger is presented as a required architectural property, and add the operational controls a non-ledger registry must meet. ### **Scope** In scope: framework, developer and supporting documentation wording; operational requirements for a registry operating without a ledger; conformance expectations; the operating profile of the Foundation-operated registries. Explicitly out of scope: 1. **Interoperability between non-ledger based data spaces.** This RFC does not solve cross-registry claim exchange for registries without a ledger. It documents the limitation so parties can make an informed choice. A solution requires a separate RFC (see Recommended next step). 2. **Development of a (reference) implementation of a non-ledger Participant Registry.** The Foundation reference implementation uses blockchain to distribute party information and stays ledger-based. Parties choosing a non-ledger model must source or build their own implementation. ### **Description and principles** **Principles applied** 1. The Participant Registry is defined by its role, its APIs and its governance requirements, not by its backend architecture. 2. Within a data space, interoperability rests on the framework, the parties-and-claims model, the discovery logic and the VC flows, not on shared backend state. 3. Where trust was associated with distributed replication, it must be stated explicitly in terms of governance, audit and verifiable records. 4. Consequences of choosing a non-ledger implementation must be stated openly rather than presented as equivalent. 5. No breaking changes. Ledger-backed operation stays valid and remains the reference implementation. **Documentation changes required** | Source | Location | Change | | ----- | ----- | ----- | | Developer Portal | Participant Registry → Getting started | Replace the distributed ledger sentence. State that the backend is an implementation choice and that within a data space interoperability follows from the framework, the APIs and the claim model. Replace the word ‘Node’ which seems to reference ledger-architecture. | | Developer Portal | Reference → Claims models | Under verificationHash for Framework Agreement Claim and Dataspace Agreement Claim it is mentioned that the agreementsare not stored in the ledger. | | Trust Framework | Service levels for Certified Parties → Reporting | Reword the reporting condition neutrally. Both models are valid, so state the reporting distinction on its own terms | | Trust Body of Knowledge | Zero Trust → Zero Trust in the iSHARE Trust Framework | Already states that the registry may be operated independently of a distributed ledger. Align status and tense once RFC044 is approved | | Trust Body of Knowledge | New article | Implementation scenarios with and without a distributed ledger, how to choose, and what a non-ledger choice means for cross-registry claims and party portability. Address possible solution directions such as synchronization, including its pros and cons, without fully specifying how to implement. Cons being: PR is liable for providing participant information, may include risks if synchronization is not working properly. | | Trust Body of Knowledge | Change existing texts that reference the ledger | Under [https\://trustbok.ishare.eu/apply-ishare/technical-faqs\#can-participants-be-transferred-between-different-participant-registries](https://trustbok.ishare.eu/apply-ishare/technical-faqs#can-participants-be-transferred-between-different-participant-registries) and [https\://trustbok.ishare.eu/understand-ishare/general-faqs\#how-is-the-participant-registry-in-the-ishare-network-unique](https://trustbok.ishare.eu/understand-ishare/general-faqs#how-is-the-participant-registry-in-the-ishare-network-unique). | | OpenAPI | Update agreement schema | Remove reference to ledger. | | GitHub | Participant Registry deployment folder and scripts | Update text that presents HLF deployment as the baseline. State that the reference implementation is ledger-based and make explicit that this is an implementation choice, not a framework requirement. | | Conformance Test Tool | No changes | No changes | | Schemas | Update framework and dataspace agreement schema | Remove reference to ledger. | ### **Example use cases** **A data space deploys a registry without a ledger.** A data space stands up a Participant Registry fully compliant with iSHARE specifications. It exposes the required endpoints, registers participants with the mandatory claims (frameworkMembership, frameworkAgreement, frameworkRole and a certificate or IdP assertion), and passes conformance testing on party and claim correctness. The PR is however not connected to a ledger. Participants in that data space resolve parties and claims through the same endpoints they would use for a ledger-backed registry. **A governance body corrects a wrongly registered claim.** A data space governance body finds a frameworkRole claim was registered in error. The registry sets the claim status to revoked through PATCH /parties/{partyId}/claims/{claimId}, logs the change and retains the supporting evidence. Correctness rests on the audit trail and the governance decision, not on ledger history. The integrity of the audit trail forms a formal basis for any potential future disputes. **A data space weighs the two models during design.** A governance body reads the new supporting article, sees that a non-ledger registry lowers deployment complexity but does not exchange claims with registries in other data spaces, and decides on that basis. The framework gives it the information to choose rather than a single prescribed backend. ## **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\* | Yes. More attention to who may register or update AR claims on the party's behalf. Registration may be in multiple Participant Registries (duplicate entries). Also accounts for other roles. | | Authorization Registry | No\* | No | | Identity Provider | No\* | No | | Identity Broker | No\* | No | | Data Space Administrator (Data Space Governance Body) | No\* | Yes. Admission discipline, change control, delegated administration and dispute handling gain weight. The body must choose a registry model in the knowledge that a non-ledger choice limits cross-registry claim exchange. It also brings added responsibility in terms of audit trails. | | Participant Registry | Yes. A non-ledger registry must implement the optional write operations for party maintenance and cannot rely on ledger propagation. No interface changes | Yes. Admission, participant maintenance, auditability, reporting, reconciliation and incident handling gain weight. An operating profile must be published | No breaking changes to interfaces. Existing ledger-backed implementations and all existing integrations stay valid. \* While interfaces remain the same, it must be noted that parties that wish to query participants from other dataspaces at one PR, are not automatically able to do so if that PR is not connected to the ledger. ## **Impact iSHARE Foundation (Scheme Owner)** | Artefact | Impact | | ----- | ----- | | iSHARE Trust Framework | Yes. Reword the service-level reporting condition. | | Developer documentation | Yes. Rewrite the Participant Registry introduction. Describe both models and their consequences | | OpenAPI definitions | Yes. In the agreement schema under verificationHash the ledger is mentioned. | | Schema documentation | Yes. In the schema for framework agreement and dataspace agreement under verificationHash the ledger is mentioned. | | Postman collections | No | | Trust body of knowledge | Yes, under [https\://trustbok.ishare.eu/apply-ishare/technical-faqs\#can-participants-be-transferred-between-different-participant-registries](https://trustbok.ishare.eu/apply-ishare/technical-faqs#can-participants-be-transferred-between-different-participant-registries) and [https\://trustbok.ishare.eu/understand-ishare/general-faqs\#how-is-the-participant-registry-in-the-ishare-network-unique](https://trustbok.ishare.eu/understand-ishare/general-faqs#how-is-the-participant-registry-in-the-ishare-network-unique) the text must be rephrased. | | Participant Registry reference implementation (GitHub) | Yes, documentation only. The implementation stays ledger-based. Update the deployment folder and scripts, which read as HLF-focused, and state that a non-ledger model requires an own implementation *(repository content to be verified)* | | eSEAL guide, iSHARE.NET, python-ishare, code snippets, AR reference implementation, SP reference implementation | No | | Foundation-operated registries (sat.ishare.eu, sat.uat.isharetest.net) | No | | Public website | No | | Internal documentation | Yes. Onboarding and participant maintenance procedures | | Authorisation Registry test implementation | No | | Conformance Test Tool | No | | iSHARE test Participant Registry (scheme.isharetest.net) | No | | iSHARE test certificate authority | No | | Change Management documentation | No | The work is documentation, governance and tooling alignment. It is not an interface change. ## **Implementation** ### **Release schedule** The API groundwork is already released: the optional write operations in 2.2 and the revised party-and-claims model in 3.0. What remains for RFC044 is documentation and operational requirements, so no coordinated implementation window is needed for participants. It can be released in the next framework release together with the supporting Trust Body of Knowledge article. *Target release: 4.0* ### **Communication** | Topic | Audience | Means | | ----- | ----- | ----- | | The Participant Registry role is backend-neutral; ledger-backed and non-ledger operation are both valid | All participants, prospective Participant Registries | Release notes, CAB session | | What a non-ledger registry means for cross-registry claims and party portability, and that this is not solved by this RFC | Prospective Participant Registries, data space governance bodies | Trust Body of Knowledge article | ## **Risks and attention points** **Known limitation on cross-registry claims.** A non-ledger registry cannot expose claims registered by other Participant Registries, and duplicate party records may appear. This is out of scope here, so the mitigation is transparency: state it in the framework, the Developer Portal and the supporting article, and raise a follow-up RFC. The risk of leaving it undocumented is that parties choose a non-ledger model without knowing what they give up. **Weaker perceived trust.** Removing ledger wording without adding operational requirements would let participants read a non-ledger registry as less trustworthy. Mitigation is procedural: explicit governance rules, audit and evidence requirements, disciplined claim management, and conformance focused on APIs and claims. **Documentation inconsistency.** Present today across the Developer Portal, the Trust Framework reporting section and the Trust Body of Knowledge. Resolving it is the core of this RFC. **No non-ledger reference implementation.** Adopters expecting a ready non-ledger deployment will not find one. Set that expectation in the documentation and in DIL communication. ## **Recommended next step** Create a new RFC to research interoperability between data spaces that are not connected through the distributed ledger. **Why.** The revised party-and-claims model lets a Participant Registry add claims to a party registered elsewhere, but assumes the ledger carries those claims between registries. RFC044 permits registries without a ledger and documents the resulting limitation without solving it. The open question is how participants in data spaces served by non-ledger registries discover and verify each other's claims and authenticate each other's participants. **Suggested scope** * How a non-ledger registry exposes or obtains claims registered by another Participant Registry, including registry-to-registry retrieval over the existing /parties and /claims endpoints. * Whether Verifiable Credentials remove the need for cross-registry claim propagation, since the party can hold and present its Participant and Participant Claim Credentials directly. * How to prevent or reconcile duplicate party records across registries. * Trust and governance conditions on accepting claims issued by a registry in another data space. * What conformance should verify for a registry that is not ledger-connected. **Input available.** DSGO has stated support for a Participant Registry without distributed ledger and has designed part of a solution, covering updates to dataspace roles by a third-party Participant Registry and requests for data space enrolment. That work is a useful starting point.