iiSHARE RFC Review RFC board ↗
RFC044 · Change · Target release 4.0

Accommodate iSHARE Participant Registry without distributed ledger

ChangeIn implementationFull RFC and impact analysis ↗

The iSHARE Trust Framework already defines the Participant Registry by its role, its APIs and its governance requirements, not by a backend technology. Several documentation pages still present the distributed ledger as a required property. This RFC corrects that wording, states that both ledger-backed and non-ledger Participant Registries are valid, and documents openly what a registry without a ledger cannot do: exchange claims with Participant Registries in other data spaces. There are no interface changes.

Change. Goes live with release 4.0: merged into 4.0-preview after approval, and into the live documentation when release 4.0 is published.
Added textRemoved text Unchanged context Links marked ↗ open the current, live documentation.

Overview of changes

IDDocumentPageChange
RFC044-01Developer PortalGetting startedModified Normative
RFC044-02Developer PortalClaim modelsModified Normative
RFC044-03Trust FrameworkService levels for Certified PartiesModified Normative
RFC044-04Trust Body of KnowledgeZero TrustModified
RFC044-05Trust Body of KnowledgeWith or Without a Distributed LedgerAdded
RFC044-06Trust Body of KnowledgeTable of contentsModified
RFC044-07Trust Body of KnowledgeTechnical FAQsModified
RFC044-09OpenAPI definitionsishare_openapi_spec.yamlModified Normative
RFC044-10Schemasschema.jsonModified Normative
RFC044-11Schemasschema.jsonModified Normative

Developer Portal

Issue #8 · Merge request !64 · Branch
RFC044-01ModifiedNormative

Getting started

participant-registry-role/getting-started.md

Replaces the sentence that the Participant Registry "is built on a Distributed Ledger across all data spaces". The backend is now described as an implementation choice, with the consequences of operating without a ledger. "Every node implementation" becomes "Every Participant Registry implementation".

RFC itemDeveloper Portal – Participant Registry → Getting started
Current version ↗
Getting startedThis section in the current version ↗

The Participant Registry admits members to the data space. The Participant Registry serves as the Trust Anchor for the data space, a crucial aspect in any iSHARE use case. Each participant in the data space can verify in the Participant Registry whether other parties in the data space are trusted and compliant. These are prerequisites, however, which is why it does not play a direct role (and is not depicted) in any of the use cases.

To register all participants in the data space and ensure that the coverage by the Framework is digitally verifiable, the Participant Registry is built on a Distributed Ledger across all data spaces, using the iSHARE Trust Framework as the core component. This means all data spaces operating based on the Trust Framework are interoperable by design.

To register all participants in the data space and ensure that the coverage by the Framework is digitally verifiable, the Participant Registry implements the iSHARE APIs and the iSHARE party and claims model. Within a data space, interoperability follows from the iSHARE Trust Framework, these APIs and the claims model, not from a specific backend technology.

The backend of a Participant Registry is an implementation choice. The iSHARE reference implementation uses a distributed ledger to share party information between Participant Registries in different data spaces. A Participant Registry MAY also operate without a distributed ledger. In that case it cannot expose claims that other Participant Registries have registered for a party, and the same party may be registered separately in several Participant Registries. The Trust Body of Knowledge describes both scenarios and their consequences.

With the Participant Registry, data space governance body/administrators can register participants. For participant administration, a web interface (Participant Registry) or APIs for automated registration are available. Automated participant discovery in data spaces is facilitated through defined endpoints that offer key insights for data spaces to operate:

Getting startedThis section in the current version ↗

Parties Endpoint
Retrieve data from a selection of parties available in the data space or in a subset of the data space. It will look like this (example where the iSHARE DID method is used as identifier): /parties/did:ishare:EU.NL.NTRLNL-10000000.

Every nodeParticipant Registry implementation is equipped with API’sthese APIs and with that can serve within the data space as the single source for party information with the performance level of the data space.

The Party model describes a participant. Most information is clustered in claims.

Source diff
line 5
22
33The Participant Registry admits members to the data space. The Participant Registry serves as the Trust Anchor for the data space, a crucial aspect in any iSHARE use case. Each participant in the data space can verify in the Participant Registry whether other parties in the data space are trusted and compliant. These are prerequisites, however, which is why it does not play a direct role (and is not depicted) in any of the use cases.
44
5To register all participants in the data space and ensure that the coverage by the Framework is digitally verifiable, the Participant Registry is built on a Distributed Ledger across all data spaces, using the iSHARE Trust Framework as the core component. This means all data spaces operating based on the Trust Framework are interoperable by design.\
5To register all participants in the data space and ensure that the coverage by the Framework is digitally verifiable, the Participant Registry implements the iSHARE APIs and the iSHARE party and claims model. Within a data space, interoperability follows from the iSHARE Trust Framework, these APIs and the claims model, not from a specific backend technology.
6
7The backend of a Participant Registry is an implementation choice. The iSHARE reference implementation uses a distributed ledger to share party information between Participant Registries in different data spaces. A Participant Registry MAY also operate without a distributed ledger. In that case it cannot expose claims that other Participant Registries have registered for a party, and the same party may be registered separately in several Participant Registries. The [Trust Body of Knowledge](https://trustbok.ishare.eu) describes both scenarios and their consequences.\
68\
79With the Participant Registry, data space governance body/administrators can register participants. For participant administration, a web interface (Participant Registry) or APIs for automated registration are available. Automated participant discovery in data spaces is facilitated through defined endpoints that offer key insights for data spaces to operate:
810
Retrieve data from a selection of parties available in the data space or in a subset of the data space. It will look like this (example where the iSHARE DID method is used as identifier)
1113_Parties Endpoint_\
1214Retrieve data from a selection of parties available in the data space or in a subset of the data space. It will look like this (example where the iSHARE DID method is used as identifier): /parties/did:ishare:EU.NL.NTRLNL-10000000.
1315
14Every node implementation is equipped with API’s and with that can serve within the data space as the single source for party information with the performance level of the data space.
16Every Participant Registry implementation is equipped with these APIs and with that can serve within the data space as the single source for party information with the performance level of the data space.
1517
1618The Party model describes a participant. Most information is clustered in [claims](../reference/claim-models.md).
1719
RFC044-02ModifiedNormative

Claim models

reference/claim-models.md

Under verificationHash of the Framework Agreement and Dataspace Agreement claims, "agreements are not stored in the ledger" becomes "the Participant Registry registers only the hash of the agreement".

RFC itemDeveloper Portal – Reference → Claim models
Current version ↗
Claim models › Framework Agreement ClaimThis section in the current version ↗

Presents the claims for the Accession Agreement and Terms of Use are required at minimum, may have additional agreements. Contains the following attributes:

  • id (Required)
    String. Unique identifier of the claim, must be a UUID.
  • status (Required)
    String (enum). Status of the framework agreement (active, inactive, revoked or suspended).
  • registrarId (Required)
    String. Identifier of the party who registered the claim. This can be any of the Party ID from id (iSHARE ID) or alsoKnownAs attributes of that participant.
  • startDate
    String. UTC timestamp of the start date of the framework agreement claim.
  • endDate
    String. UTC timestamp of the end date of the framework agreement claim.
  • agreementType (Required)
    String. Descriptive type of the agreement. Framework or dataspace may define agreement types.
  • agreementId (Required)
    String. ID that refers to the agreement.
  • title (Required)
    String. The name of the agreement or agreement file
  • verificationHash
    String. The calculated hash of the agreement file that has been uploaded. Note agreements are not stored in the ledger, but only their hashThe Participant Registry registers only the hash of the agreement, not the agreement itself. The verificationHash must be calculated using the SHA256 hashing algorithm.
  • type (Required)
    String(enum). Must contain frameworkAgreement for this type of claim.
  • frameworkId (Required)
    String. ID of the framework the agreement applies to.

Example

Claim models › Dataspace Agreement ClaimThis section in the current version ↗

When a dataspace defines its own agreement for participants, it can be added through this claim. Contains the following attributes:

  • id (Required)
    String. Unique identifier of the claim, must be a UUID.
  • status (Required)
    String (enum). Status of the dataspace agreement (active, inactive, revoked or suspended).
  • registrarId (Required)
    String. Identifier of the party who registered the claim. This can be any of the Party ID from id (iSHARE ID) or alsoKnownAs attributes of that participant.
  • startDate
    String. UTC timestamp of the start date of the dataspace agreement claim.
  • endDate
    String. UTC timestamp of the end date of the dataspace agreement claim.
  • agreementType (Required)
    String. Descriptive type of the agreement. Framework or dataspace may define agreement types.
  • agreementId (Required)
    String. ID that refers to the agreement.
  • title (Required)
    String. The name of the agreement or agreement file
  • verificationHash
    String. The calculated hash of the agreement file that has been uploaded. Note agreements are not stored in the ledger, but only their hashThe Participant Registry registers only the hash of the agreement, not the agreement itself. The verificationHash must be calculated using the SHA256 hashing algorithm.
  • type (Required)
    String(enum). Must contain dataspaceAgreement for this type of claim.
  • dataspaceId (Required)
    String. Identifier of the dataspace of which the participant is a member of.

Example

Source diff
Presents the claims for the Accession Agreement and Terms of Use are required at minimum, may have additional agreements. Contains the following attributes
175175* `title` <mark style="color:red;">(Required)</mark>\
176176 **String**. The name of the agreement or agreement file
177177* `verificationHash`\
178 **String**. The calculated hash of the agreement file that has been uploaded. Note agreements are not stored in the ledger, but only their hash. The verificationHash must be calculated using the SHA256 hashing algorithm.
178 **String**. The calculated hash of the agreement file that has been uploaded. The Participant Registry registers only the hash of the agreement, not the agreement itself. The verificationHash must be calculated using the SHA256 hashing algorithm.
179179* `type` <mark style="color:red;">(Required)</mark>\
180180 **String(enum)**. Must contain `frameworkAgreement` for this type of claim.
181181* `frameworkId` <mark style="color:red;">(Required)</mark>\
When a dataspace defines its own agreement for participants, it can be added through this claim. Contains the following attributes
343343* `title` <mark style="color:red;">(Required)</mark>\
344344 **String**. The name of the agreement or agreement file
345345* `verificationHash`\
346 **String**. The calculated hash of the agreement file that has been uploaded. Note agreements are not stored in the ledger, but only their hash. The verificationHash must be calculated using the SHA256 hashing algorithm.
346 **String**. The calculated hash of the agreement file that has been uploaded. The Participant Registry registers only the hash of the agreement, not the agreement itself. The verificationHash must be calculated using the SHA256 hashing algorithm.
347347* `type` <mark style="color:red;">(Required)</mark>\
348348 **String(enum)**. Must contain `dataspaceAgreement` for this type of claim.
349349* `dataspaceId` <mark style="color:red;">(Required)</mark>\

Trust Framework

Issue #9 · Merge request !51 · Branch
RFC044-03ModifiedNormative

Service levels for Certified Parties

detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite.md

The reporting condition no longer treats a registry "disconnected from the distributed ledger" as the exception. A Participant Registry reports its number of relations unless the Scheme Owner can retrieve its registrations directly; both implementation models are stated to be valid.

RFC itemTrust Framework – Service levels for Certified Parties → Reporting
Current version ↗
Service levels for Certified Parties › ReportingThis section in the current version ↗

Reports are meant to monitor both compliance with the service level agreements and the (growing) use of the iSHARE network, as described in the management reporting process. The following will be reported on (non-exhaustive):

Certified party Participant Registry
Availability Yes Yes
Number of relations with Adhering Parties Yes Only if operating standalone Participant Registry (disconnected from the distributed ledger)
Number of transactions Yes No
Number of transactions per Adhering Party Yes No
Number of incidents. Yes Yes
Certified party Participant Registry
Availability Yes Yes
Number of relations with Adhering Parties Yes Only if the Scheme Owner cannot retrieve the registered parties directly (see below)
Number of transactions Yes No
Number of transactions per Adhering Party Yes No
Number of incidents. Yes Yes

A Participant Registry MAY be implemented with or without a distributed ledger; both are valid implementations of the role. A Participant Registry reports the number of relations with Adhering Parties unless its registrations are directly available to the Scheme Owner, for instance because the Participant Registry shares its party information with the Scheme Owner through a distributed ledger.

All Certified Parties are expected to collect management information for each month: 0:00h on the first day to 23:59h on the last.

Source diff
**Reports** are meant to monitor both compliance with the service level agreements and the (growing) use of the iSHARE network, as described in the [management reporting process](../operational-processes/management-reporting.md). The following will be reported on (non-exhaustive)
8484| | Certified party | Participant Registry |
8585| ----------------------------------------- | --------------- | -------------------------------------------------------------------------------------------- |
8686| Availability | Yes | Yes |
87| Number of relations with Adhering Parties | Yes | Only if operating standalone Participant Registry (disconnected from the distributed ledger) |
87| Number of relations with Adhering Parties | Yes | Only if the Scheme Owner cannot retrieve the registered parties directly (see below) |
8888| Number of transactions | Yes | No |
8989| Number of transactions per Adhering Party | Yes | No |
9090| Number of incidents. | Yes | Yes |
91
92A Participant Registry MAY be implemented with or without a distributed ledger; both are valid implementations of the role. A Participant Registry reports the number of relations with Adhering Parties unless its registrations are directly available to the Scheme Owner, for instance because the Participant Registry shares its party information with the Scheme Owner through a distributed ledger.
9193
9294All Certified Parties are expected to collect management information for each month: 0:00h on the first day to 23:59h on the last.
9395

Trust Body of Knowledge

Issue #1 · Merge request !1 · Branch
RFC044-04Modified

Zero Trust

understand-ishare/zero-trust.md

Describes the Participant Registry by its role, its APIs and its governance requirements instead of by distributed ledger technology.

RFC itemTrust Body of Knowledge – Zero Trust → Zero Trust in the iSHARE Trust Framework
Current version ↗
Zero Trust › Zero Trust in the iSHARE Trust FrameworkThis section in the current version ↗

The iSHARE Trust Framework inherently offers organisations the tools to dynamically set and verify trust levels. To further enable zero trust principles, Verifiable Credentials (RFC040) facilitate context-specific interactions, while multiple identification methods (RFC031) provide flexibility beyond traditional EORI-based verification. Additionally, it enables organisations to engage with others in the network at a more granular trust level, tailored to the specific needs of the data space or organisational standards.

The iSHARE Participant Registry (Satellite) has also been designed to align with Zero Trust, using distributed ledger technology to manage interoperability among data spaces. Now, with RFC044, organisations have the option to operate the Participant Registry independently of a distributed ledger, making it adaptable for more flexible trust assessments aligned with Zero Trust. These existing features underscore how the iSHARE Framework supports trust assessments that adapt dynamically to each interaction.

The iSHARE Participant Registry (formerly Satellite) has also been designed to align with Zero Trust. It is defined by its role, its APIs and its governance requirements, not by its backend technology. These existing features underscore how the iSHARE Framework supports trust assessments that adapt dynamically to each interaction.

Trust Verification in iSHARE-based Data Spaces

Source diff
Data sharing requires a strong foundation of trust, which can be established in two main ways
1818
1919The iSHARE Trust Framework inherently offers organisations the tools to dynamically set and verify trust levels. To further enable zero trust principles, Verifiable Credentials (RFC040) facilitate context-specific interactions, while multiple identification methods (RFC031) provide flexibility beyond traditional EORI-based verification. Additionally, it enables organisations to engage with others in the network at a more granular trust level, tailored to the specific needs of the data space or organisational standards.
2020
21The iSHARE Participant Registry (Satellite) has also been designed to align with Zero Trust, using distributed ledger technology to manage interoperability among data spaces. Now, with RFC044, organisations have the option to operate the Participant Registry independently of a distributed ledger, making it adaptable for more flexible trust assessments aligned with Zero Trust. These existing features underscore how the iSHARE Framework supports trust assessments that adapt dynamically to each interaction.
21The iSHARE Participant Registry (formerly Satellite) has also been designed to align with Zero Trust. It is defined by its role, its APIs and its governance requirements, not by its backend technology. These existing features underscore how the iSHARE Framework supports trust assessments that adapt dynamically to each interaction.
2222
2323#### Trust Verification in iSHARE-based Data Spaces
2424
RFC044-05Added

With or Without a Distributed Ledger

apply-ishare/participant-registry/with-or-without-a-distributed-ledger.md

New article on implementation scenarios with and without a distributed ledger: what stays the same, how to choose, operational controls for a registry without a ledger, and possible solution directions for cross-registry claims (synchronisation, retrieval on demand, Verifiable Credentials) with their pros and cons.

RFC itemTrust Body of Knowledge – New article
New page

With or Without a Distributed Ledger

The iSHARE Trust Framework defines the Participant Registry by its role, its APIs and its governance requirements. It does not prescribe a backend technology. The iSHARE reference implementation uses a distributed ledger (Hyperledger Fabric) to share party information between Participant Registries, but a Participant Registry MAY also be operated without one (RFC044).

This article describes both implementation scenarios, what to consider when choosing between them, and what operating without a ledger means for claims registered elsewhere and for the portability of parties.

Ledger-backed and non-ledger Participant Registries are both valid implementations of the role. Within a data space they expose the same endpoints, use the same party and claims model and are subject to the same conformance testing. The difference lies in what happens between Participant Registries.

What stays the same

Whatever the backend, a Participant Registry:

  • exposes the required Participant Registry endpoints, such as /parties, /parties/{partyId}, /claims, /trusted_list, /dataspaces and /frameworks;
  • registers participants with the mandatory claims (framework membership, framework agreement, framework role and a certificate or IdP assertion);
  • MAY offer the optional write operations (POST and PUT on parties, POST and PATCH on claims), and declares which methods it supports through OPTIONS;
  • MAY issue Participant Credentials as Verifiable Credentials;
  • operates under the service levels and the admission, maintenance and reporting processes of the iSHARE Trust Framework.

Participants in a data space resolve parties and claims through the same endpoints in both scenarios. Within a single data space, interoperability follows from the framework, the APIs, the claims model, the discovery logic and the VC flows, not from shared backend state.

Scenario 1: ledger-backed Participant Registry

In this scenario the Participant Registry is a node in a distributed ledger network shared with Participant Registries in other data spaces. The iSHARE reference implementation and the Foundation-operated registries work this way.

  • Cross-registry claims. A Participant Registry can add claims to a party that was registered by another Participant Registry, such as a data space membership or a data space role. The ledger distributes those claims to all connected registries, so each of them can expose the full set of claims for that party.
  • Party portability. A party is registered once and can become active in several data spaces without being registered again.
  • Shared history. The ledger keeps a replicated, tamper-evident record of registrations and changes.
  • Cost. Joining and operating a ledger node adds technical complexity, such as peer management, channel membership and certificate configuration, as well as a dependency on the governance of the shared network.

Scenario 2: Participant Registry without a distributed ledger

In this scenario the Participant Registry keeps its party information in its own storage, for instance a relational database, and is not connected to other Participant Registries.

  • Lower deployment complexity. No ledger node is needed and the data space has full control over its own registry.
  • No cross-registry claims. The Participant Registry cannot expose claims that other Participant Registries have registered for a party, and other registries cannot see the claims it registers.
  • Possible duplicate records. A party that participates in several data spaces may be registered separately in several Participant Registries, each with its own lifecycle.
  • Party maintenance through the API. The Participant Registry cannot rely on ledger propagation and must maintain parties and claims itself, typically through the optional write operations.
  • Trust through governance. Where trust was associated with replication over a ledger, it now rests on explicit governance, audit and evidence (see Operational controls).

The Foundation reference implementation remains ledger-based. Parties choosing a non-ledger model must source or build their own implementation.

How to choose

Question Points towards a ledger-backed registry Points towards a registry without a ledger
Do participants of this data space also participate in other iSHARE data spaces? Yes, often Rarely or never
Must claims registered by other data spaces (memberships, roles, AR selection) be visible here? Yes No
Is registering a party once and reusing it across data spaces important for adoption? Yes No
Does the data space have the capacity to run and maintain a ledger node? Yes Limited
Does the data space need full, independent control over its registry infrastructure? Less important Important

A data space governance body that chooses a registry without a ledger does so knowing that this limits cross-registry claim exchange. It records that choice, and its consequences for participants, in the operating profile of its Participant Registry.

Operational controls for a registry without a ledger

A Participant Registry without a ledger is expected to make its trustworthiness explicit through governance and operational controls:

  • Admission discipline. Clear, documented admission criteria and evidence requirements for each claim.
  • Change control. Every creation, update and revocation of a party or claim is logged with who made the change, when and on what basis. A wrongly registered claim is revoked (for example through PATCH /parties/{partyId}/claims/{claimId}), not silently removed.
  • Audit trail and evidence retention. The log and the supporting evidence are retained and protected against tampering, so they can serve as a formal basis in case of disputes.
  • Delegated administration. It is defined who may register or update claims on behalf of a party, including Authorisation Registry claims.
  • Reconciliation and incident handling. Procedures exist to detect and correct inconsistent or duplicate records.
  • Reporting. The registry reports to the Scheme Owner as required by the service levels for Certified Parties, including the number of registered parties when these are not otherwise available to the Scheme Owner.
  • Operating profile. The registry publishes an operating profile that describes the above, and states that it is not connected to a distributed ledger.

Possible solution directions for cross-registry claims

Exchanging claims between Participant Registries that are not connected through a ledger is out of scope of RFC044 and requires a separate RFC. The directions below are possible ways forward. They are listed to inform the choice of a data space, not as specifications.

Synchronisation between registries

Registries periodically retrieve parties and claims from each other, for instance over the existing /parties and /claims endpoints, and store a copy.

  • Pros: uses existing APIs; no shared infrastructure needed; each registry stays in control of its own data.
  • Cons: the Participant Registry is liable for the participant information it provides, including copies obtained from others; if synchronisation fails or lags, the registry may expose outdated or incorrect information, such as a revoked role that still appears active; each pair of registries needs a trust and governance agreement on accepting each other's claims; conflicts and duplicates must be reconciled.

Retrieval on demand (federated lookup)

Instead of copying data, a registry or a participant queries the registry that issued a claim at the moment it is needed.

  • Pros: no stale copies; responsibility for a claim stays with the registry that issued it.
  • Cons: depends on the availability and performance of other registries; requires discovery of which registry holds which claims; adds latency to verification.

Verifiable Credentials held by the party

The party holds Participant and Participant Claim Credentials in its own wallet and presents them to verifiers in other data spaces.

  • Pros: reduces or removes the need to propagate claims between registries; the party controls the use of its credentials.
  • Cons: verifiers must trust the issuing registry and check credential status; revocation must be resolvable across data spaces; not every participant uses a wallet yet.

Further reading

Source diff
line 1
1# With or Without a Distributed Ledger
2
3The iSHARE Trust Framework defines the Participant Registry by its role, its APIs and its governance requirements. It does not prescribe a backend technology. The iSHARE reference implementation uses a distributed ledger (Hyperledger Fabric) to share party information between Participant Registries, but a Participant Registry MAY also be operated without one (RFC044).
4
5This article describes both implementation scenarios, what to consider when choosing between them, and what operating without a ledger means for claims registered elsewhere and for the portability of parties.
6
7{% hint style="info" %}
8Ledger-backed and non-ledger Participant Registries are both valid implementations of the role. Within a data space they expose the same endpoints, use the same party and claims model and are subject to the same conformance testing. The difference lies in what happens *between* Participant Registries.
9{% endhint %}
10
11## What stays the same
12
13Whatever the backend, a Participant Registry:
14
15* exposes the required Participant Registry endpoints, such as `/parties`, `/parties/{partyId}`, `/claims`, `/trusted_list`, `/dataspaces` and `/frameworks`;
16* registers participants with the mandatory claims (framework membership, framework agreement, framework role and a certificate or IdP assertion);
17* MAY offer the optional write operations (`POST` and `PUT` on parties, `POST` and `PATCH` on claims), and declares which methods it supports through `OPTIONS`;
18* MAY issue Participant Credentials as Verifiable Credentials;
19* operates under the service levels and the admission, maintenance and reporting processes of the iSHARE Trust Framework.
20
21Participants in a data space resolve parties and claims through the same endpoints in both scenarios. Within a single data space, interoperability follows from the framework, the APIs, the claims model, the discovery logic and the VC flows, not from shared backend state.
22
23## Scenario 1: ledger-backed Participant Registry
24
25In this scenario the Participant Registry is a node in a distributed ledger network shared with Participant Registries in other data spaces. The iSHARE reference implementation and the Foundation-operated registries work this way.
26
27* **Cross-registry claims.** A Participant Registry can add claims to a party that was registered by another Participant Registry, such as a data space membership or a data space role. The ledger distributes those claims to all connected registries, so each of them can expose the full set of claims for that party.
28* **Party portability.** A party is registered once and can become active in several data spaces without being registered again.
29* **Shared history.** The ledger keeps a replicated, tamper-evident record of registrations and changes.
30* **Cost.** Joining and operating a ledger node adds technical complexity, such as peer management, channel membership and certificate configuration, as well as a dependency on the governance of the shared network.
31
32## Scenario 2: Participant Registry without a distributed ledger
33
34In this scenario the Participant Registry keeps its party information in its own storage, for instance a relational database, and is not connected to other Participant Registries.
35
36* **Lower deployment complexity.** No ledger node is needed and the data space has full control over its own registry.
37* **No cross-registry claims.** The Participant Registry cannot expose claims that other Participant Registries have registered for a party, and other registries cannot see the claims it registers.
38* **Possible duplicate records.** A party that participates in several data spaces may be registered separately in several Participant Registries, each with its own lifecycle.
39* **Party maintenance through the API.** The Participant Registry cannot rely on ledger propagation and must maintain parties and claims itself, typically through the optional write operations.
40* **Trust through governance.** Where trust was associated with replication over a ledger, it now rests on explicit governance, audit and evidence (see [Operational controls](#operational-controls-for-a-registry-without-a-ledger)).
41
42{% hint style="warning" %}
43The Foundation reference implementation remains ledger-based. Parties choosing a non-ledger model must source or build their own implementation.
44{% endhint %}
45
46## How to choose
47
48| Question | Points towards a ledger-backed registry | Points towards a registry without a ledger |
49| -------------------------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------ |
50| Do participants of this data space also participate in other iSHARE data spaces? | Yes, often | Rarely or never |
51| Must claims registered by other data spaces (memberships, roles, AR selection) be visible here? | Yes | No |
52| Is registering a party once and reusing it across data spaces important for adoption? | Yes | No |
53| Does the data space have the capacity to run and maintain a ledger node? | Yes | Limited |
54| Does the data space need full, independent control over its registry infrastructure? | Less important | Important |
55
56A data space governance body that chooses a registry without a ledger does so knowing that this limits cross-registry claim exchange. It records that choice, and its consequences for participants, in the operating profile of its Participant Registry.
57
58## Operational controls for a registry without a ledger
59
60A Participant Registry without a ledger is expected to make its trustworthiness explicit through governance and operational controls:
61
62* **Admission discipline.** Clear, documented admission criteria and evidence requirements for each claim.
63* **Change control.** Every creation, update and revocation of a party or claim is logged with who made the change, when and on what basis. A wrongly registered claim is revoked (for example through `PATCH /parties/{partyId}/claims/{claimId}`), not silently removed.
64* **Audit trail and evidence retention.** The log and the supporting evidence are retained and protected against tampering, so they can serve as a formal basis in case of disputes.
65* **Delegated administration.** It is defined who may register or update claims on behalf of a party, including Authorisation Registry claims.
66* **Reconciliation and incident handling.** Procedures exist to detect and correct inconsistent or duplicate records.
67* **Reporting.** The registry reports to the Scheme Owner as required by the service levels for Certified Parties, including the number of registered parties when these are not otherwise available to the Scheme Owner.
68* **Operating profile.** The registry publishes an operating profile that describes the above, and states that it is not connected to a distributed ledger.
69
70## Possible solution directions for cross-registry claims
71
72Exchanging claims between Participant Registries that are not connected through a ledger is **out of scope of RFC044** and requires a separate RFC. The directions below are possible ways forward. They are listed to inform the choice of a data space, not as specifications.
73
74#### Synchronisation between registries
75
76Registries periodically retrieve parties and claims from each other, for instance over the existing `/parties` and `/claims` endpoints, and store a copy.
77
78* **Pros:** uses existing APIs; no shared infrastructure needed; each registry stays in control of its own data.
79* **Cons:** the Participant Registry is liable for the participant information it provides, including copies obtained from others; if synchronisation fails or lags, the registry may expose outdated or incorrect information, such as a revoked role that still appears active; each pair of registries needs a trust and governance agreement on accepting each other's claims; conflicts and duplicates must be reconciled.
80
81#### Retrieval on demand (federated lookup)
82
83Instead of copying data, a registry or a participant queries the registry that issued a claim at the moment it is needed.
84
85* **Pros:** no stale copies; responsibility for a claim stays with the registry that issued it.
86* **Cons:** depends on the availability and performance of other registries; requires discovery of which registry holds which claims; adds latency to verification.
87
88#### Verifiable Credentials held by the party
89
90The party holds Participant and Participant Claim Credentials in its own wallet and presents them to verifiers in other data spaces.
91
92* **Pros:** reduces or removes the need to propagate claims between registries; the party controls the use of its credentials.
93* **Cons:** verifiers must trust the issuing registry and check credential status; revocation must be resolvable across data spaces; not every participant uses a wallet yet.
94
95## Further reading
96
97* [RFC044: Accommodate iSHARE Participant Registry without distributed ledger](https://gitlab.com/ishare-foundation/cab/rfc/-/work_items/2)
98* [Developer Portal: Participant Registry](https://dev.ishare.eu/participant-registry-role/getting-started)
99* [Deployment & Use Cases](deployment-and-use-cases.md)
100
RFC044-06Modified

Table of contents

SUMMARY.md

Adds the new article to the navigation, under Participant Registry.

RFC itemTrust Body of Knowledge – New article
Current version ↗
Table of contents › Understand iSHAREThis section in the current version ↗

Apply iSHARE

Enable iSHARE

Source diff
line 45
4242 * [How It Works](apply-ishare/participant-registry/how-it-works.md)
4343 * [Functional Capabilities](apply-ishare/participant-registry/functional-capabilities.md)
4444 * [Deployment & Use Cases](apply-ishare/participant-registry/deployment-and-use-cases.md)
45 * [With or Without a Distributed Ledger](apply-ishare/participant-registry/with-or-without-a-distributed-ledger.md)
4546* [APIs](apply-ishare/apis/README.md)
4647 * [Capabilities endpoint](apply-ishare/apis/capabilities-endpoint.md)
4748* [Quick walkthroughs](apply-ishare/quick-walkthroughs/README.md)
RFC044-07Modified

Technical FAQs

apply-ishare/technical-faqs.md

"Can participants be transferred between different Participant Registries?" now distinguishes between registries connected through a distributed ledger and registries without one.

RFC itemTrust Body of Knowledge – Change existing texts that reference the ledger
Current version ↗
Technical FAQsThis section in the current version ↗
What is the purpose of the /dataspaces endpoint in the Participant Registry specification?

The /dataspaces endpoint lists registered Data Spaces and their details. It is used by Participants to discover the available Data Spaces. Documentation on its usage is available in the latest iSHARE developer portal.

Can participants be transferred between different Participant Registries?

Yes, in theory, participants can be transferred between different (participant registry) nodes, as they are interconnected through the same Hyperledger Fabric network. Functionality to support such transfers is part of RFC064.

Can participants be transferred between different Participant Registries?

It depends on how the Participant Registries are implemented. Participant Registries that are connected through a distributed ledger, such as the iSHARE reference implementation based on Hyperledger Fabric, share party information. A party registered by one of them can be maintained by another, and other registries can add claims to it, as introduced by RFC064.

A Participant Registry that is not connected to a distributed ledger does not share party information with other registries. Moving a party to or from such a registry means registering it again, and the party may end up with separate records in several registries. See With or Without a Distributed Ledger.

Why might a Participant Registry peer fail to join a Hyperledger Fabric channel with a TLS error?

A “TLS handshake failed” or “certificate signed by unknown authority” error usually indicates that the client does not trust the signer of the server’s TLS certificate. This can happen if the root or intermediate CA certificate is missing or misconfigured. Ensure the client trusts the CA that issued the peer’s certificate and that the certificate chain is properly configured.

Source diff
It depends on how the Participant Registries are implemented. Participant Registries that are connected through a distributed ledger, such as the iSHARE reference implementation based on Hyperledger Fabric, share party information. A party registered by one of them can be maintained by another, and other registries can add claims to it, as introduced by [RFC064](https
320320
321321<summary>Can participants be transferred between different Participant Registries?</summary>
322322
323Yes, in theory, participants can be transferred between different (participant registry) nodes, as they are interconnected through the same Hyperledger Fabric network. Functionality to support such transfers is part of [RFC064](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/ac118179053a9e95513bc3e3f51cc49abf620dfd/RFC%20Documents/RFC064/README.md).
323It depends on how the Participant Registries are implemented. Participant Registries that are connected through a distributed ledger, such as the iSHARE reference implementation based on Hyperledger Fabric, share party information. A party registered by one of them can be maintained by another, and other registries can add claims to it, as introduced by [RFC064](https://gitlab.com/ishare-foundation/cab/rfc/-/blob/ac118179053a9e95513bc3e3f51cc49abf620dfd/RFC%20Documents/RFC064/README.md).
324
325A Participant Registry that is not connected to a distributed ledger does not share party information with other registries. Moving a party to or from such a registry means registering it again, and the party may end up with separate records in several registries. See [With or Without a Distributed Ledger](participant-registry/with-or-without-a-distributed-ledger.md).
324326
325327</details>
326328

OpenAPI definitions

Issue #34 · Merge request !61 · Branch
RFC044-09ModifiedNormative

ishare_openapi_spec.yaml

ishare_openapi_spec.yaml

Removes the ledger reference from the verificationHash description. No interface change.

RFC itemOpenAPI – Update agreement schema
Current version ↗ New specification in Swagger UI ↗
components › schemas › agreement › properties › verificationHash › description
19371937 verificationHash:
19381938 description: >-
19391939 The calculated hash of the agreement file that has been uploaded.
1940 Note agreements are not stored in the ledger, but only their hash.
1940 The Participant Registry registers only the hash of the agreement, not the agreement itself.
19411941 The verificationHash must be calculated using the SHA256 hashing algorithm.
19421942 type: string
19431943 example: aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb

Schemas

Issue #1 · Merge request !16 · Branch
RFC044-10ModifiedNormative

schema.json

v3/claims/framework-agreement/schema.json

Removes the ledger reference from the verificationHash description. No structural change.

RFC itemSchemas – Update framework and dataspace agreement schema
Current version ↗
$defs › FrameworkAgreementClaimSubject › properties › verificationHash › description
150150 },
151151 "verificationHash": {
152152 "type": "string",
153 "description": "The calculated hash of the agreement file that has been uploaded. Note agreements are not stored in the ledger, but only their hash. The verificationHash must be calculated using the SHA256 hashing algorithm.",
153 "description": "The calculated hash of the agreement file that has been uploaded. The Participant Registry registers only the hash of the agreement, not the agreement itself. The verificationHash must be calculated using the SHA256 hashing algorithm.",
154154 "examples": ["aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb"]
155155 }
156156 },
RFC044-11ModifiedNormative

schema.json

v3/claims/dataspace-agreement/schema.json

Removes the ledger reference from the verificationHash description. No structural change.

RFC itemSchemas – Update framework and dataspace agreement schema
Current version ↗
$defs › DataspaceAgreementClaimSubject › properties › verificationHash › description
150150 },
151151 "verificationHash": {
152152 "type": "string",
153 "description": "The calculated hash of the agreement file that has been uploaded. Note agreements are not stored in the ledger, but only their hash. The verificationHash must be calculated using the SHA256 hashing algorithm.",
153 "description": "The calculated hash of the agreement file that has been uploaded. The Participant Registry registers only the hash of the agreement, not the agreement itself. The verificationHash must be calculated using the SHA256 hashing algorithm.",
154154 "examples": ["aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb"]
155155 }
156156 },