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

Background and rationale

This RFC was raised during discussion of RFC061.

The iSHARE Framework contains specifications for the /parties endpoint, defining how any iSHARE Participant Registry must allow parties to retrieve information of this party. The model of the party roughly consists of:

Identification information (party identifier)
Certificates used by the party for M2M authentication
Data space specific context information (capabilities endpoint, ID of registring Participant Registry)
General information about the party (email, industry, countries of operation, etc.)
Adherence to the framework
Signed agreements including agreements for data space membership
Roles for which the party is onboarded and/or certified
Chosen Authorisation Registry per data space

Registration of all of the above mentioned information is typically handled by a single Participant Registry (formerly called "Satellite"). This single Participant Registry is assumed to register all of the information for all data spaces the participant is a member of. Other Participant Registries cannot register additional information.

iSHARE Foundation maintains a reference implementation of the Participant Registry. This reference implementation uses blockchain to distribute party information across multiple Participant Registries. Registration of a party is still maintained at one Participant Registry. A party can be transferred from one registering Participant Registry to another.

The impact of this implementation is that when an existing party wants to join another data space, it must first be transfered from the original registring Participant Registry, to to Participant Registry that handles onboarding of that data space. This is not a scalable solution.

Proposed change

Purpose

This RFC aims to enhance the portability and maintainability of participants across multiple data spaces within the iSHARE Framework. While doing this, the intention is to simultaniously revise and improve the party model and /parties endpoint.

To promote interoperability and reusage of registration of a party in a Satellite, and at the same time allow other Satellites to maintain membership of a data space of a party, it would help to improve the design of the framework as well as the reference implementation of the satellite.

Considerations and requirements

This RFC is related to the implementation of Verifiable Credentials in the iSHARE Trust Framework, as data space membership can be seen as a 'claim' of a party. The same principle could be applied in the solution design, where PRs can manage claims of participants and a participant is registered through an initial PR. It could work using the distributed ledger, but also without the distributed ledger.

Description and principles

Enhance Interoperability & Reusability – Facilitates the seamless registration and reuse of participant data across multiple Participant Registries, improving efficiency.
Decentralised Membership Management – Enables different Participant Registries to independently manage and maintain a participant’s membership in various data spaces.
Framework & Implementation Improvement – Refines the overall design of the framework and enhances the reference implementation of the Participant Registry, ensuring greater scalability and maintainability.

The following solution pattern has been discussed, in which the existing participant information is split into two components:

Base Participant Information: Includes core details such as participant ID and general participant information, all managed by an initial registrar.
Claims: Represent various attributes (e.g., memberships, roles, compliance certifications) that can be added and managed by different participant registries.

While this scenario relates to the implementation of Verifiable Credentials (in which 'claims' form a core concept), it does not necessarily require immediate implementation of Verifiable Credentials. Claims can be managed independently, with proof mechanisms supporting both long-term and short-term validation (e.g., JWT-like proofs). In fact, this implementation method allows for a better transition into the VC implementation.

What we want to acheive is

Register a new participant
Update (or deactivate/revoke) a existing participant
Add claims to an existing participant
Update (or remove) claims to an existing participant
- Add a role to a participant
- Update (or end) a role of a participant
- Add dataspace membership to an existing participant
- Update (or remove) dataspace membership to an existing participant
- Add other claims/credentials to an existing participant
- Update (or remove) other claims/credentials to an existing participant
Retrieve parties and claims/crednetials from a participant registered in any data space

As a rule, each of the modular record can be created by a Participant Registry and it is he owner and maintainer of the record. The modular approach allows Participant Registry A to register Participant1 while Participant Registry B could create dataspace membership D1 for Participant1 by referring to the existing registration. It gives us:

Participant Registry A can update and maintain the Participant Registration of Participant1
Participant Registry B can update and maintain the Dataspace Membership D1 of Participant1

There are two ways that this can be acheived:

Base Participant info + claims: In this case the base participant info will be a fixed structure and the base default that must be first registered by participant registry for registering a new participant. The claims can be added to this participant by linking it with thier ID.
Everything is a claim including base participant info In this case as well, first participant registry must first register a base participant info claim, however, here the base is just the id of participant while the base info is also a claim

Solution options

All the considered solutions are moved to seperate file for better readablity and only recommended solution is given below:

Scenario 6

This model has Base participant credential and claims attached to it. This model allows the extensibility and supports better portability due to its modular nature. I also allows making many to many, one to many, many to one and one to one relationships between participants and claims. Further due to modular nature it allows different participant registries from different datapsaces to manage their own set of claims for the respective participant. Also due to faltter structure it makes it easier to parse, find, update the information.

Model provided in this file.

API methods based on the model above:

GET /parties

Parties endpoint as it stands today will remain the same (pagination) while the party_info object will contain specific party details as shown in below request. For clarity sake an example is included:

GET /parties/{partyId}

To get a single party details, you simply call the parties endpoint followed by party id. Party id can be anyone of the party id from the id or alsoKnownAs attributes of that participant. Since all participants are automatically allocated the derived ishare did, that id is always an option to search for a participant.

Following is the example of the output of the party endpoint

{
  "aud": "did:ishare:EU.NL.NTRNL-10000001",
  "iss": "did:ishare:EU.NL.NTRNL-10000000",
  "sub": "did:ishare:EU.NL.NTRNL-10000000",
  "exp": 1719321354,
  "iat": 1719321324,
  "jti": "adf2e9ecdb974fd68209c390005b1276",
  "party_info": {
    "id": "did:ishare:EU.NL.NLNTR-12345678",
    "name": "Test Service Consumer",
    "alsoKnownAs": [
      "did:elsi:LEIXG-724500AZSGBRY55MNS59",
      "did:key:z6MkhfrsD3GUMjGvRxTTSamE1WnS9w3nDJLeZzT1KZVrU5tE",
      "did:web:example.com",
      "AS.JA.NTA:1234567890123"
    ],
    "claims": [
      {
        "type": "x509Certificate",
        "id": "5ffb4bb9-2020-4045-a922-3bd84e78f709",
        "subjectName": "C=NL,O=Test Service Consumer,CN=Test Service Consumer,2.5.4.97=NTRNL-10000001",
        "certificateType": "eSeal",
        "enabledFrom": "2025-02-12T00:00:00.000Z",
        "x5c": "MIIGiDCCBHCgAwIBAgIURMIL+omg6v5pU6qFOMFceG1YjDAwDQYJKoZIhvcNAQELBQAwXTEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9Jc3NDQUc0MRkwFwYDVQRhExBOVFJOTC1pU0hBUkVURVNUMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDAeFw0yNDExMDYxNDQ1NDFaFw0yNzExMDYxNDQ1NDBaMGYxCzAJBgNVBAYTAk5MMR4wHAYDVQQKDBVUZXN0IFNlcnZpY2UgQ29uc3VtZXIxHjAcBgNVBAMMFVRlc3QgU2VydmljZSBDb25zdW1lcjEXMBUGA1UEYQwOTlRSTkwtMTAwMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDYSKOvmB6UxEaYOPT7APgU4mauSh9vbPacJtM3a4cdzN8KippjoWSbgr6Jb4Fc7tGvNk6nvWZHlHzADFe0aQIGl8IDhuq1BhXJTxHZ4krw/6AEbC/GRcgtJdcanlc3WkM5rMEsoDRd8gOvNTnL7m52DIWb3RS8bCitVH6qn3hoWSwX9XeeU6JrGu1kp6lfT19u1zJKZuBaB0Ia4uzmM+QSd1kU6PeCXQ+trEfVUQkP8g/rzZGnSH8u7NqiwwUfFSiaUyq9P4Ip+K0JBTtAuQ9xpQ6wQxt0ioFNFb9ipmc3xxekowMRykZzEdoHO/ynY3W4sbTSl2eN4EmfHzQGRLJLAgMBAAGjggI1MIICMTAOBgNVHQ8BAf8EBAMCBkAwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSzGk9CQOnYeJ1r//wksBCxNDzwiTBXBggrBgEFBQcBAQRLMEkwRwYIKwYBBQUHMAGGO2h0dHBzOi8vY2E3LmlzaGFyZXRlc3QubmV0Ojg0NDIvZWpiY2EvcHVibGljd2ViL3N0YXR1cy9vY3NwMBAGA1UdIAQJMAcwBQYDVR0gMB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMFsGCCsGAQUFBwEDBE8wTTATBgYEAI5GAQYwCQYHBACORgEGAjA2BggrBgEFBQcBAwwqVGhpcyBpcyB0ZXN0IGVzZWFsIGNlcnRpZmljYXRlIGZvciB0ZXN0aW5nMB4GBWeBDAMBBBUwExMDTlRSEwJOTAwIMTAwMDAwMDEwgccGA1UdHwSBvzCBvDCBuaCBtqCBs4aBsGh0dHBzOi8vY2E3LmlzaGFyZXRlc3QubmV0Ojg0NDIvZWpiY2EvcHVibGljd2ViL3dlYmRpc3QvY2VydGRpc3Q/Y21kPWNybCZpc3N1ZXI9Q04lM0RlSURBU2VTRUFMT0lEX0lzc0NBRzQlMkNvcmdhbml6YXRpb25JZGVudGlmaWVyJTNETlRSTkwtaVNIQVJFVEVTVCUyQ08lM0RpU0hBUkVUZXN0JTJDQyUzRFhYMB0GA1UdDgQWBBRdyUNPiwe2WprwzYgvyZ+6fC1oNDANBgkqhkiG9w0BAQsFAAOCAgEAsXZrFG5ajsFNgTflnbTfD6aL/W0O9uywQ7VTTurZHboHTxDIIL3Gq9Vj/d0vpJJgrfysnR/MBHC9fXonV9WuwSKho91mHquUc7ytlyFwoAN5ROVIR1RBhUosMG0JgTw5PgW9xXBogAZ+7EFDiM70BJUr+ojqlZ2yYS324IDCpgFe9ySXinzTg8+d3jBsQLE0IXnR/+dNNthHhAl1HLfl6wZ9RbPpZgp0AeCcdKbn1IfUzePYMnRyuDjRgnmQYVYD31Qa68gx5Ys1qb/fYwSSpeER0Zf06S0exPUYShtOwRlYqia2z8LgN4TurdwcDcTijmekE9+/oSSITehFroA2eHLsqYte8jQgFBPEcy2syFw1VFDqTa/GnJJkoFCf8jPnlnAHEFJmkhAZ3xeP1Dag30CP+aoCQVNykhO5Z73V6BpNhdpgaYX4B/QRePUhqUoYbHLefAlyO7SFRahycW+o66K5GueptgtQ2DrrjvCtaCG8EtJczihAjBN0OQZsQWnU8vooLss+Rmfg9MXTR8k85cYT9ZMdU/46zlgAMIaJizv8j4eHaKgfRBB1gw71oW97oW5QKQx861UrR1u0DJmSQSUwNYlopKVRnHvXJWUIreOqLfSSB/1uVQfvq0UzsJKdeOCKRLpXXgxB3w7S2+5KFETS7tcbZ6mIxZlJlh0VRSs=",
        "x5tS256": "4670551451113b19425f8d63c3d6ce444b58de60831101748e9fb97b3e8766f8",
        "status": "Active"
      },
      {
        "type": "frameworkMembership",
        "id": "e1585bdd-a1a9-4bd3-bf7e-7fe64300907b",
        "registrarId": "did:ishare:EU.NL.NTRNL-10000222",
        "capabilityUrl": "",
        "status": "Active",
        "startDate": "2025-02-12T00:00:00.000Z",
        "endDate": "2026-02-13T00:00:00.000Z",
        "frameworkId": "iSHARE",
        "additionalInfo": {
          "description": "description",
          "logo": "https://logo.example.com/",
          "website": "https://www.example.com/",
          "companyPhone": "+310202343458",
          "companyEmail": "info@exmaple.com",
          "publiclyPublishable": "no",
          "countriesOfOperation": [
            "Netherlands",
            "Germany"
          ],
          "sectorIndustry": [
            "Energy"
          ],
          "tags": ""
        }
      },
      {
        "type": "authRegistry",
        "id": "96a9a443-89cc-43a7-a64a-461a4d508713",
        "authRegistryId": "did:ishare:EU.NL.NTRNL-10000004",
        "authUrl": "https://some.server.com/abc",
        "status": "Active"
      },
      {
        "type": "frameworkAgreement",
        "id": "b2be77dc-20c6-4deb-8f2a-855cd34aacca",
        "agreementType": "Terms of Use",
        "agreementId": "tou",
        "title": "Terms of Use",
        "status": "Accepted",
        "signDate": "2025-02-12T00:00:00.000Z",
        "expiryDate": "2026-02-13T00:00:00.000Z",
        "verificationHash": "ae1d7d30f5db9497f21a7984a8a6f359"
      },
      {
        "type": "frameworkRole",
        "id": "369bb9f3-96e0-47b0-8579-a4d1c6749315",
        "roleId": "ServiceConsumer",
        "title": "Service Consumer",
        "status": "Active",
        "startDate": "2025-02-12T00:00:00.000Z",
        "endDate": "2026-02-13T00:00:00.000Z",
        "frameworkId": "iSHARE",
        "loa": "substantial",
        "compliancyVerified": "yes",
        "legalAdherence": "no",
        "registrarId": "did:ishare:EU.NL.NTRNL-10000000"
      },
      {
        "type": "frameworkRole",
        "id": "716e3178-36d2-4658-92cb-e2d078ff7f4e",
        "roleId": "ServiceProvider",
        "title": "Service Provider",
        "status": "Active",
        "startDate": "2025-02-12T00:00:00.000Z",
        "endDate": "2026-02-13T00:00:00.000Z",
        "frameworkId": "iSHARE",
        "loa": "substantial",
        "compliancyVerified": "yes",
        "legalAdherence": "no",
        "registrarId": "did:ishare:EU.NL.NTRNL-10000000"
      }
    ]
  }
}

POST /parties

To create a participant a post request can be made. Note, for iSHARE framework, the following claims will be mandatory when creating a participant:

frameworkMembership Required. Claim with framework value of "iSHARE" proving that participant is compliant to iSHARE framework as validated by the Participant registry.
frameworkAgreement Required. Claims for Accession Agreement and Terms of Use are required at minimum, may have additional agreements.
frameworkRole Required. Claim of any role as defined in iSHARE role model. One role is required at minimum. More roles can be added.
x509Certificate Required if no idpAssertion claim is present. x509Certificate claim must be a valid certificate issued by a Root from the trusted list.
idpAssertion Required if no x509Certificate claim is present. Formerly known as spor. idpAssertion claim is only allowed for "Entitled Party" and "Service Consumer" (non-M2M) roles

{
  "aud": "did:ishare:EU.NL.NTRNL-10000001",
  "iss": "did:ishare:EU.NL.NTRNL-10000000",
  "sub": "did:ishare:EU.NL.NTRNL-10000000",
  "exp": 1719321354,
  "iat": 1719321324,
  "jti": "adf2e9ecdb974fd68209c390005b1276",
  "party_info": {
    "id": "did:ishare:EU.NL.NLNTR-12345678",
    "name": "Test Service Consumer",
    "alsoKnownAs": [
      "did:elsi:LEIXG-724500AZSGBRY55MNS59",
      "did:key:z6MkhfrsD3GUMjGvRxTTSamE1WnS9w3nDJLeZzT1KZVrU5tE",
      "did:web:example.com",
      "AS.JA.NTA:1234567890123"
    ],
    "claims": [
      {
        "type": "x509Certificate",
        "id": "5ffb4bb9-2020-4045-a922-3bd84e78f709",
        "subjectName": "C=NL,O=Test Service Consumer,CN=Test Service Consumer,2.5.4.97=NTRNL-10000001",
        "certificateType": "eSeal",
        "enabledFrom": "2025-02-12T00:00:00.000Z",
        "x5c": "MIIGiDCCBHCgAwIBAgIURMIL+omg6v5pU6qFOMFceG1YjDAwDQYJKoZIhvcNAQELBQAwXTEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9Jc3NDQUc0MRkwFwYDVQRhExBOVFJOTC1pU0hBUkVURVNUMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDAeFw0yNDExMDYxNDQ1NDFaFw0yNzExMDYxNDQ1NDBaMGYxCzAJBgNVBAYTAk5MMR4wHAYDVQQKDBVUZXN0IFNlcnZpY2UgQ29uc3VtZXIxHjAcBgNVBAMMFVRlc3QgU2VydmljZSBDb25zdW1lcjEXMBUGA1UEYQwOTlRSTkwtMTAwMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDYSKOvmB6UxEaYOPT7APgU4mauSh9vbPacJtM3a4cdzN8KippjoWSbgr6Jb4Fc7tGvNk6nvWZHlHzADFe0aQIGl8IDhuq1BhXJTxHZ4krw/6AEbC/GRcgtJdcanlc3WkM5rMEsoDRd8gOvNTnL7m52DIWb3RS8bCitVH6qn3hoWSwX9XeeU6JrGu1kp6lfT19u1zJKZuBaB0Ia4uzmM+QSd1kU6PeCXQ+trEfVUQkP8g/rzZGnSH8u7NqiwwUfFSiaUyq9P4Ip+K0JBTtAuQ9xpQ6wQxt0ioFNFb9ipmc3xxekowMRykZzEdoHO/ynY3W4sbTSl2eN4EmfHzQGRLJLAgMBAAGjggI1MIICMTAOBgNVHQ8BAf8EBAMCBkAwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSzGk9CQOnYeJ1r//wksBCxNDzwiTBXBggrBgEFBQcBAQRLMEkwRwYIKwYBBQUHMAGGO2h0dHBzOi8vY2E3LmlzaGFyZXRlc3QubmV0Ojg0NDIvZWpiY2EvcHVibGljd2ViL3N0YXR1cy9vY3NwMBAGA1UdIAQJMAcwBQYDVR0gMB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMFsGCCsGAQUFBwEDBE8wTTATBgYEAI5GAQYwCQYHBACORgEGAjA2BggrBgEFBQcBAwwqVGhpcyBpcyB0ZXN0IGVzZWFsIGNlcnRpZmljYXRlIGZvciB0ZXN0aW5nMB4GBWeBDAMBBBUwExMDTlRSEwJOTAwIMTAwMDAwMDEwgccGA1UdHwSBvzCBvDCBuaCBtqCBs4aBsGh0dHBzOi8vY2E3LmlzaGFyZXRlc3QubmV0Ojg0NDIvZWpiY2EvcHVibGljd2ViL3dlYmRpc3QvY2VydGRpc3Q/Y21kPWNybCZpc3N1ZXI9Q04lM0RlSURBU2VTRUFMT0lEX0lzc0NBRzQlMkNvcmdhbml6YXRpb25JZGVudGlmaWVyJTNETlRSTkwtaVNIQVJFVEVTVCUyQ08lM0RpU0hBUkVUZXN0JTJDQyUzRFhYMB0GA1UdDgQWBBRdyUNPiwe2WprwzYgvyZ+6fC1oNDANBgkqhkiG9w0BAQsFAAOCAgEAsXZrFG5ajsFNgTflnbTfD6aL/W0O9uywQ7VTTurZHboHTxDIIL3Gq9Vj/d0vpJJgrfysnR/MBHC9fXonV9WuwSKho91mHquUc7ytlyFwoAN5ROVIR1RBhUosMG0JgTw5PgW9xXBogAZ+7EFDiM70BJUr+ojqlZ2yYS324IDCpgFe9ySXinzTg8+d3jBsQLE0IXnR/+dNNthHhAl1HLfl6wZ9RbPpZgp0AeCcdKbn1IfUzePYMnRyuDjRgnmQYVYD31Qa68gx5Ys1qb/fYwSSpeER0Zf06S0exPUYShtOwRlYqia2z8LgN4TurdwcDcTijmekE9+/oSSITehFroA2eHLsqYte8jQgFBPEcy2syFw1VFDqTa/GnJJkoFCf8jPnlnAHEFJmkhAZ3xeP1Dag30CP+aoCQVNykhO5Z73V6BpNhdpgaYX4B/QRePUhqUoYbHLefAlyO7SFRahycW+o66K5GueptgtQ2DrrjvCtaCG8EtJczihAjBN0OQZsQWnU8vooLss+Rmfg9MXTR8k85cYT9ZMdU/46zlgAMIaJizv8j4eHaKgfRBB1gw71oW97oW5QKQx861UrR1u0DJmSQSUwNYlopKVRnHvXJWUIreOqLfSSB/1uVQfvq0UzsJKdeOCKRLpXXgxB3w7S2+5KFETS7tcbZ6mIxZlJlh0VRSs=",
        "x5tS256": "4670551451113b19425f8d63c3d6ce444b58de60831101748e9fb97b3e8766f8",
        "status": "Active"
      },
      {
        "type": "frameworkMembership",
        "id": "e1585bdd-a1a9-4bd3-bf7e-7fe64300907b",
        "registrarId": "did:ishare:EU.NL.NTRNL-10000222",
        "capabilityUrl": "",
        "status": "Active",
        "startDate": "2025-02-12T00:00:00.000Z",
        "endDate": "2026-02-13T00:00:00.000Z",
        "frameworkId": "iSHARE",
        "additionalInfo": {
          "description": "description",
          "logo": "https://logo.example.com/",
          "website": "https://www.example.com/",
          "companyPhone": "+310202343458",
          "companyEmail": "info@exmaple.com",
          "publiclyPublishable": "no",
          "countriesOfOperation": [
            "Netherlands",
            "Germany"
          ],
          "sectorIndustry": [
            "Energy"
          ],
          "tags": ""
        }
      },
      {
        "type": "frameworkAgreement",
        "id": "b2be77dc-20c6-4deb-8f2a-855cd34aacca",
        "agreementType": "Terms of Use",
        "agreementId": "tou",
        "title": "Terms of Use",
        "status": "Accepted",
        "signDate": "2025-02-12T00:00:00.000Z",
        "expiryDate": "2026-02-13T00:00:00.000Z",
        "verificationHash": "ae1d7d30f5db9497f21a7984a8a6f359"
      },
      {
        "type": "frameworkAgreement",
        "id": "b2be77dc-20c6-4deb-8f2a-855cd34aacca",
        "agreementType": "Accession Agreement",
        "agreementId": "aa",
        "title": "Accession Agreement",
        "status": "Accepted",
        "signDate": "2025-02-12T00:00:00.000Z",
        "expiryDate": "2026-02-13T00:00:00.000Z",
        "verificationHash": "ae1d7d30f5db9497f21a7984a8a6f359"
      },
      {
        "type": "frameworkRole",
        "id": "716e3178-36d2-4658-92cb-e2d078ff7f4e",
        "roleId": "ServiceProvider",
        "title": "Service Provider",
        "status": "Active",
        "startDate": "2025-02-12T00:00:00.000Z",
        "endDate": "2026-02-13T00:00:00.000Z",
        "frameworkId": "iSHARE",
        "loa": "substantial",
        "compliancyVerified": "yes",
        "legalAdherence": "no",
        "registrarId": "did:ishare:EU.NL.NTRNL-10000000"
      }
    ]
  }
}

PATCH /parties/did:ishare:EU.NL.NLNTR-12345678/

If only certain attributes of a claim are to be updated, then HTTP PATCH method could be used. Following is example of updating the alsoKnownAs attribute to new value. Since its an array, it must be supplied with existing values plus the update you would like to make.

{
  "alsoKnownAs": [
      "did:ebsi:LEIXG-724500AZSGBRY55MNS59",
      "did:key:z6MkhfrsD3GUMjGvRxTTSamE1WnS9w3nDJLeZzT1KZVrU5tE",
      "did:web:example.com",
      "AS.JA.NTA:1234567890123",
      "kvk:09292092
    ]
}

POST /parties/did:ishare:EU.NL.NLNTR-12345678/claims (dataspaceMembership)

Now once a participant is created as an iSHARE participant, any participant registry can add dataspace membership to that participant. Note, dataspace membership can also be part of the initial participant creation request, but here we explain how a participant registy from another dataspace can add membership to existing participant

Following types of claims can be sent in the request:

dataspaceMembership Required. This claim must be added by the participant registry of a dataspace when addmitting a participant to its dataspace
dataspaceAgreement Required if defined by dataspace. When dataspace defines its own agreement for participants, it can be added through this claim.
dataspaceRole Required if defined by dataspace. When dataspace defines its own roles for participants, it can be added through this claim.
dataspaceAuthRegistry Required if defined by dataspace. Participants can register which authorisation registry they use within this dataspace. This helps in discovery of authorisation registry to use during authorisations.

{
  "type": "dataspaceMembership",
  "id": "6fa964e4-f4c8-4dd5-93d6-71afe628b57b",
  "registrarId": "did:ishare:EU.NL.NTRNL-10000222",
  "capabilityUrl": "https://capabilities.example.com/",
  "dataspaceId": "DSP.EU.NL.DutchMobility",
  "status": "Active",
  "startDate": "2025-02-12T00:00:00.000Z",
  "endDate": "2026-02-13T00:00:00.000Z",
  "legalAdherence": "no",
  "additionalInfo": {
    "description": "description",
    "logo": "https://logo.example.com/",
    "website": "https://www.example.com/",
    "companyPhone": "+310202343458",
    "companyEmail": "info@exmaple.com",
    "publiclyPublishable": "no",
    "countriesOfOperation": [
      "Netherlands",
      "Germany"
    ],
    "sectorIndustry": [
      "Energy"
    ],
    "tags": ""
  }
},
{
  "type": "dataspaceAuthRegistry",
  "id": "9d8ce587-d320-42a4-a365-517ff935dc98",
  "dataspaceId": "DSP.EU.NL.DutchMobility",
  "authRegistryID": "EU.EORI.NL000000004",
  "authUrl": "https://some.server.com/abc",
  "status": "Active"
},
{
  "type": "dataspaceAgreement",
  "id": "e65c7982-6f8c-46a9-b32e-e9586850765e",
  "dataspaceId": "DSP.EU.NL.DutchMobility",
  "agreementType": "Terms of Use",
  "agreementId": "dmtou",
  "title": "tu",
  "status": "Accepted",
  "signDate": "2025-02-12T00:00:00.000Z",
  "expiryDate": "2026-02-13T00:00:00.000Z",
  "verificationHash": "ae1d7d30f5db9497f21a7984a8a6f359"
},
{
  "type": "dataspaceRole",
  "id": "216b5826-182b-4dec-8a28-f18da9bbab9d",
  "dataspaceId": "DSP.EU.NL.DutchMobility",
  "roleId": "ServiceBroker",
  "title": "Service Broker",
  "status": "Active",
  "startDate": "2025-02-12T00:00:00.000Z",
  "endDate": "2026-02-13T00:00:00.000Z",
  "loa": "substantial",
  "compliancyVerified": "yes",
  "legalAdherence": "no"
}

Alternatively, Participant Reigistry can add just the dataspaceMembership claim. Other claims, either may be optional or may not be defined in dataspace

{
  "type": "dataspaceMembership",
  "id": "6fa964e4-f4c8-4dd5-93d6-71afe628b57b",
  "registrarId": "did:ishare:EU.NL.NTRNL-10000222",
  "capabilityUrl": "https://capabilities.example.com/",
  "dataspaceId": "DSP.EU.NL.DutchMobility",
  "status": "Active",
  "startDate": "2025-02-12T00:00:00.000Z",
  "endDate": "2026-02-13T00:00:00.000Z",
  "legalAdherence": "no",
  "additionalInfo": {
    "description": "description",
    "logo": "https://logo.example.com/",
    "website": "https://www.example.com/",
    "companyPhone": "+310202343458",
    "companyEmail": "info@exmaple.com",
    "publiclyPublishable": "no",
    "countriesOfOperation": [
      "Netherlands",
      "Germany"
    ],
    "sectorIndustry": [
      "Energy"
    ],
    "tags": ""
  }
}

POST /parties/did:ishare:EU.NL.NLNTR-12345678/claims (dataspaceRole)

Once a participant has a membership to a dataspace, the dataspace participant registry can add new dataspace role to the participant.

{
  "type": "dataspaceRole",
  "id": "216b5826-182b-4dec-8a28-f18da9bbab9d",
  "dataspaceId": "DSP.EU.NL.DutchMobility",
  "roleId": "ServiceBroker",
  "title": "Service Broker",
  "status": "Active",
  "startDate": "2025-02-12T00:00:00.000Z",
  "endDate": "2026-02-13T00:00:00.000Z",
  "loa": "substantial",
  "compliancyVerified": "yes",
  "legalAdherence": "no"
}

PATCH /parties/did:ishare:EU.NL.NLNTR-12345678/claims/216b5826-182b-4dec-8a28-f18da9bbab9d

If only certain attributes of a claim are to be updated, then HTTP PATCH method could be used. Following is example of revoking the status of the dataspaceRole that was added previously.

{
  "status": "Revoked"
}

Additional endpoints updates

GET /dataspaces endpoint

Dataspaces endpoint will be updated to include roles and agreements as array of values as well as now includes the name of the Dataspace Governance Body and list of registrars (participant registries party_id)

The new dataspaces endpoint structure is shown below:

{
    "title": "DLDS_Logistics_DataSpace",
    "id": "EU.DS.NL.DLDS_Logistics",
    "defUrl": "https://definition.dataspace.com",
    "website": "https://www.dataspace.com",
    "govBody": "ABC Foundation",
    "govBodyId": "did:ishare:EU.NL.NLNTR-000000018",
    "registrarIds": [
        "did:ishare:EU.NL.NLNTR-000000008"
    ],
    "tags": "",
    "status": "Active",
    "countryRegistration": "Netherlands",
    "countriesOperation": [
        "Netherlands",
        "Germany"
    ],
    "sectors": [
        "Energy"
    ],
    "agreements": [
        {
            "id": "TermsofUse",
            "title": "Terms of Use",
            "required": true
        },
        {
            "id": "ComplianceABC",
            "title": "Compliance to ABC terms",
            "required": false
        }
    ],
    "roles": [
        {
            "id": "ServiceBroker",
            "title": "Service Broker",
            "x509CertificateRequired": true,
            "agreements": [
                "TermsofUse",
                "ComplianceABC"
            ],
            "loaRequired": true,
            "technicalCompliance": "yes"
        },
        {
            "id": "VocabularyProvider",
            "title": "Vocabulary Provider",
            "x509CertificateRequired": false,
            "agreements": [
                "TermsofUse"
            ],
            "loaRequired": false,
            "technicalCompliance": "yes"
        }
    ]
}

GET /frameworks endpoint

A new endpoint will be introduced in the participant registry to read the details of the framework. This endpoint will replace /versions endpoint of participant registry. Following is the structure and example:

GET /frameworks

{
    "title": "iSHARE Framework",
    "id": "iSHARE",
    "defUrl": "https://dev.ishare.eu",
    "website": "https://ishare.eu",
    "frameworkOwner": "iSHARE Foundation",
    "frameworkOwnerId": "did:ishare:EU.NL.NTRNL-73058289",
    "tags": "trustframework, datasovereignty, datarights",
    "agreements": [
        {
            "title": "iSHARE Terms of Use",
            "id": "termsofUse",
            "required": true
        },
        {
            "title": "iSHARE Adhering Party Accesssion Agreement",
            "id": "adheringAcessionAgreement",
            "required": true
        },
        {
            "title": "iSHARE Certified Party Accesssion Agreement",
            "id": "certifiedAccessionAgreement",
            "required": true
        },
        {
            "title": "iSHARE Participant Registry Agreement",
            "id": "participantRegistryAgreement",
            "required": true
        }
    ],
    "versions": [
        {
            "version": "1.0",
            "status": "deprecated"
        },
        {
            "version": "2.0",
            "status": "deprecated"
        },
        {
            "version": "2.0.1",
            "status": "active"
        },
        {
            "version": "2.1",
            "status": "active"
        },
        {
            "version": "2.2",
            "status": "active"
        }
    ],
    "roles": [
        {
            "id": "EntitledParty",
            "title": "Entitled Party",
            "x509CertificateRequired": false,
            "agreements": [
                "adheringAcessionAgreement",
                "termsofUse"
            ],
            "loaRequired": false,
            "technicalCompliance": "yes"
        },
        {
            "id": "ServiceConsumer",
            "title": "Service Consumer",
            "x509CertificateRequired": false,
            "agreements": [
                "adheringAcessionAgreement",
                "termsofUse"
            ],
            "loaRequired": false,
            "technicalCompliance": "no"
        },
        {
            "id": "ServiceProvider",
            "title": "Service Provider",
            "x509CertificateRequired": true,
            "agreements": [
                "adheringAcessionAgreement",
                "termsofUse"
            ],
            "loaRequired": false,
            "technicalCompliance": "no"
        },
        {
            "id": "AuthorisationRegistry",
            "title": "Authorisation Registry",
            "x509CertificateRequired": true,
            "agreements": [
                "certifiedAccessionAgreement",
                "termsofUse"
            ],
            "loaRequired": true,
            "technicalCompliance": "yes"
        },
        {
            "id": "IdentityProvider",
            "title": "Identity Provider",
            "x509CertificateRequired": true,
            "agreements": [
                "certifiedAccessionAgreement",
                "termsofUse"
            ],
            "loaRequired": true,
            "technicalCompliance": "yes"
        },
        {
            "id": "Identity Broker",
            "title": "IdentityBroker",
            "x509CertificateRequired": true,
            "agreements": [
                "certifiedAccessionAgreement",
                "termsofUse"
            ],
            "loaRequired": true,
            "technicalCompliance": "yes"
        },
        {
            "id": "ParticipantRegistry",
            "title": "Participant Registry",
            "x509CertificateRequired": true,
            "agreements": [
                "participantRegistryAgreement",
                "termsofUse"
            ],
            "loaRequired": true,
            "technicalCompliance": "yes"
        }
    ]
}

Considerations

The exchange of claims between Participant Registries is expected to work through the distributed ledger. For Participant Registries that are not connected to the ledger, it will not be possible to expose claims that are registered through other Participant Registries. Not being connected may also lead to duplicate records for a party in multiple Participant Registries.

For Participant Registries that are connected to the ledger this model will improve the possibility of maintaining data space specific claims. The 'main' registrar publishes the party identification and general party information, while other Participant Registries can publish claims such as data space membership, without the need to first 'transfer' a party (as is currently the case).

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	No
Service Provider	Yes	No
Entitled party	No	No
Authorization Registry	Yes	No
Identity Provider	Yes	No
Identity Broker	No	No
Participant Registry	Yes	Yes

Impact iSHARE Foundation (Scheme Owner)

The iSHARE Trust Framework
- Functional requirements per role: update text of Participant Registry so that it explains that claims can be registered for parties that are registered by other Participant Registries
The developer documentation (as an extension of the iSHARE Trust Framework)
- Remove the /versions GET endpoint
- Add the /frameworks GET endpoint
- Update the /dataspaces GET endpoint
- Remove /parties/{id} PUT endpoint
- Update /parties OPTIONS, GET and POST (optional) endpoint
- Update /parties/{id} OPTIONS and GET endpoint
- Create /parties/{id} PATCH (optional) endpoint
- Create /parties/{id}/claims OPTIONS, GET POST endpoints
- Create /parties/{id}/claims/{id} OPTIONS, GET and PATCH (optional) endpoint (note: claims cannot be removed, only revoked by updating)
The OpenAPI definitions on Swaggerhub
- See endpoint updates under developer documentation
Example implementation in Postman Collections
- Implement all PR endpoints
Code that is published on Github:
- iSHARE Satellite reference implementation
  - Update all endpoints
- eSEAL certificate procurement guide
- Reference implementation for Authorization Registry
  - Update
- Reference implementation for Service Provider
  - Update
- Onboarding portal
  - Implement new POST operation
The implementation of the iSHARE satellite for iSHARE as the Scheme Owner
- Deploy update of satellite
Internal documentation
- Yes
Authorization Registry test implementation
- Deploy
The Conformance Test Tool, tests listed on https://ctt.isharetest.net/admin/test-cases
- Yes, create tests for Participant Registry

Implementation

Release schedule

This RFC will be released as part of iSHARE 3.0.

Communication

No specific requirements.

Edited Oct 13, 2025 by athishare