# Welcome to the iSHARE Developer Portal {% hint style="info" %} **Version information** This documentation is in line with the iSHARE Trust Framework 3.0. Older versions of the framework can be accessed through the top menu. Version 1.11 is available [here](https://dev-old.ishare.eu/v1.11). {% endhint %} {% hint style="info" %} **Part of this documentation is a formal Framework specification** Part of this documentation must be considered part of the formal iSHARE Trust Framework Specification. Where applicable, this is clearly marked. {% endhint %} The iSHARE Trust Framework is a collaborative effort to improve the exchange of data between organisations in and across data spaces. The iSHARE Trust Framework is available [here](https://framework.ishare.eu). **Technical Approach** Unlike traditional software infrastructure architectures, iSHARE specifies a “soft infrastructure” architecture focusing on: * Identification, authentication, and authorisation for machine-to-machine (M2M) and human-to-machine (H2M) communication, important aspects of any data sharing transaction. * This architecture reuses and extends existing standards: * REST APIs (OAuth 2.0 & OpenIDConnect) * Verifiable Credentials (W3C VC Data model 2.0, DCP, OID4VC/VP) * Public Key Infrastructure (PKI). * Signed JSON Web Tokens (JWTs). Data sharing transactions must align with the [iSHARE Trust Framework’s roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles), each with specific responsibilities and interactions. This portal provides everything needed to technically implement iSHARE in your organisation, including: * How to get started for each role. * All iSHARE technical specifications. * Definitions for all endpoints required per role. {% hint style="info" %} **Additional content** If you are looking for additional content before getting started with your implementation, the [knowledge base](https://trustbok.ishare.eu) contains the [Technical standards used in iSHARE](https://trustbok.ishare.eu/technical-guide/technical-standards). Try the [Postman collections](/introduction/getting-started/postman-collections) to understand how the iSHARE Trust Framework works technically or make use of the reference implementations and open-source components on [GitHub](https://github.com/iSHAREScheme/). {% endhint %} # Getting started Before getting started, it is highly recommended to familiarise yourself with the essentials of the [iSHARE Trust Framework.](https://framework.ishare.eu) You need to apply for an iSHARE Test Certificate to use our test environment. How this is done is described in the [Test Certificate section](/introduction/getting-started/test-certificates). ### Consuming iSHARE Services #### Creating JSON Web Tokens A good first step is to familiarise yourself with JWT, JWS, and how to create/sign these tokens. Find various libraries and additional information for JSON Web Tokens on [jwt.io](https://jwt.io/). Various requests or responses that follow the iSHARE specifications contain signed JSON Web Tokens. Start by creating a self-signed identity claim, a *client\_assertion*, following the specifications found on the [iSHARE JWT section](/reference/ishare-jwt): 1. Construct the correct JWT header. 2. Construct the required JWT payload. 3. Sign token according to JWS specifications. {% hint style="success" %} **Tip** Take into account that an iSHARE-compliant JWT is going to be used almost everywhere. Make sure that the code you write can be easily extended according to specific JWT payload requirements. {% endhint %} #### Get an OAuth 2.0 Access Token The first workflow you should implement is an OAuth access token request. The wider use case of it is described in the [M2M Authentication section](/reference/authentication). 1. Choose a test party from the [iSHARE Test Participants](/introduction/getting-started/test-participants) and create a *client\_assertion* with the correct audience. 2. Head over to the [Access Token Endpoint section](/all-roles-common-endpoints/access-token-m2m) to see the contract of /token endpoint HTTP request. 3. Implement a token request according to the contract. 4. If done correctly, the test party should respond with an access token. {% hint style="info" %} **Note** A video demonstrating how access tokens are requested in iSHARE can be found in the [Videos section](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/demo-videos). In order to try it out with existing parties, please visit the [Postman Collections section](/introduction/getting-started/postman-collections). {% endhint %} #### Request Services With Access Tokens 1. Choose a test party from the [iSHARE Test Participants](/introduction/getting-started/test-participants) that exposes a service, with access control based on the access token. E.g. [/capabilities](/all-roles-common-endpoints/capabilities) is not restricted to additional authorisation requirements. 2. Get an access token which you’ve implemented based on the previous section. 3. Provide the access token as specified in the documentation as an authorisation header. 4. If done correctly, the test party should respond with the service that is requested. ### Exposing iSHARE services Before exposing any of the iSHARE services, firstly, you should have a proper implementation of the [iSHARE services consumption](#consuming-ishare-services). It is needed to retrieve an access token from the Participant Registry or other iSHARE parties. #### Certificate Validation Familiarise yourself with PKI, certificates and how the process of certificate validation works. iSHARE has a certificate cheat sheet. {% file src="/files/ggxc9G80xkK1kUWGYQpD" %} iSHARE OpenSSL cheat sheet {% endfile %} 1. Implement a function that retrieves the trusted list of Certificate Authorities from the Participant Registry [/trusted\_list endpoint](/participant-registry-role/trusted-list). 2. Implement a service that can validate certificates within the scope of iSHARE (see [Certificate Validation](#certificate-validation). The implemented service should check the validity of the certificate itself (such as expiry date, signature, CRL) and whether the certificate issuer is on the trusted list retrieved from the /trust\_list endpoint. {% hint style="info" %} **Note** iSHARE has example projects and code snippets on GitHub; it also contains certificate validation. Check[ it out](https://github.com/iSHAREScheme). {% endhint %} #### Expose Access Token Endpoint In order to be a party of iSHARE, your system must expose an API service that allows parties to request OAuth access tokens from your server. iSHARE does not prescribe your exact implementation or access token format, but your system should be able to handle requests sent as described in the `/token` request from the iSHARE specifications. 1. For incoming token requests, make sure that they comply with the specified iSHARE [token requests](/all-roles-common-endpoints/access-token-m2m). 2. Validate the certificate used for this request. It is in a JWT header of `client_assertion`. 3. Send the client’s party identifier (found `iss` within the request’s `client_assertion`) to the Participant Registry [/parties endpoint](/participant-registry-role/parties) for status check. Response for party status should be equal to *Active*. 4. If the party is *Active*, respond to their request with an access token; else, with a Bad Request. {% hint style="info" %} **Note** More about [iSHARE ID can be found here](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification). The sequence diagram of this flow can be found in the [Generic Authentication Flow section](/reference/authentication). {% endhint %} #### Expose Capabilities Endpoint To allow other parties to know what your party is capable of, the capabilities endpoint must be implemented. Participants of iSHARE will use this endpoint to see what iSHARE-enabled services your organisation provides. Implementation is pretty straightforward, and the API endpoint specification can be found in the [Capabilities Endpoint section](/all-roles-common-endpoints/capabilities). ### Additional Authorisation Services that require additional *evidence* for authorised access can make use of the [iSHARE authorisation protocol](/reference/authorization). This section should be interesting mostly for Authorisation Registries, Service Providers and Entitled Parties. Firstly, you will have to familiarise yourself with the iSHARE [delegation mask](/authorisation-registry-role/delegation-endpoint#request-model) and [delegation evidence](/authorisation-registry-role/delegation-endpoint#response-model) data models. #### Understanding Delegation Mask Refer to the [/delegation endpoint API specification](/authorisation-registry-role/delegation-endpoint) of the Authorisation Registry or Entitled Party. The request body contains a [delegation mask](/authorisation-registry-role/delegation-endpoint#request-model), which is in other words, could be called the actual question that is asked. The *question* contains: * Two parties between which a certain right is passed. * Resource fields that are used to specify the resource or service for which delegation evidence is requested. * An action field to indicate the kind of action regarding the resource is expected. {% hint style="info" %} **Note** You can find a video with an explanation of how the delegation mask is used within the Authorisation Registry in the [Videos section](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/demo-videos). {% endhint %} #### Creating Delegation Mask In order to create a [delegation mask](/authorisation-registry-role/delegation-endpoint#request-model) (a.k.a. the *question*), you need to translate an incoming Service Request. Through the Service Request, you should be able to: * Define which party is asking for access to a resource or service. * Indicate the second party that is needed for the mask. Your system’s knowledge of ownership of this resource or service should be able to fill in this information. * Define the resource or service itself (as long as it is clear through the Service Request). * Indicate what kind of action is expected. Once the *delegation mask* (a.k.a. the *question*) is created, a request towards /delegation endpoint of the Authorisation Registry or the Entitled party should be sent. #### Interpreting Delegation Evidence Delegation evidence will be an iSHARE-compliant[ JWT](/reference/ishare-jwt) which contains the JWT payload described in the [delegation evidence section](/authorisation-registry-role/delegation-endpoint#response-model). Based on JWT information, an authorisation decision should be made and enforced for the client. ### What’s Next? After implementing what is described above, you will have to implement endpoints which are required specifically for your organisation. Endpoints could be found in the right menu, under your organisation’s specific role. Once that is done, you will have to pass the [Conformance Test Tool](/introduction/conformance-test-tool). ### Verifiable Credentials (VCs) This *Getting started* page focuses on the classic iSHARE JWT-based flows. If your dataspace also implements **Verifiable Credentials (VCs)**, follow the VC specifications and the role-specific endpoint guidance: * [Verifiable Credential support per role](https://dev.ishare.eu/roles/verifiable-credential-support-per-role) * [Credential schemas](https://dev.ishare.eu/reference/credential-schemas) * [M2M Verifiable Credential Endpoints](https://dev.ishare.eu/all-roles-common-endpoints/m2m-verifiable-credential-endpoints) * [H2M Verifiable Credential Endpoints](https://dev.ishare.eu/all-roles-common-endpoints/H2M-Verifiable-Credential-Endpoints) # Test certificates To get an iSHARE Test certificate, you need to provide: * Your organisation's common name * Your organisation's country * Your organisation's party identifier {% hint style="warning" %} Until framework version 2.1 or higher is implemented, you may need to provide the organisation identifier as an EORI number. {% endhint %} Click [here](https://ca7.isharetest.net:8442/ejbca/ra/index.xhtml) to request your test certificate. Instructions on requesting certificates: * For testing purposes, you can choose any party identifier * For Key-pair generation, choose the option "Postpone" {% hint style="info" %} **Note on the usage of test certificates** Please note that test certificates should ONLY be used for testing purposes and to communicate test data. They are not reliable enough to be used for authentication outside of the test network, nor were they designed and distributed for that purpose. The iSHARE organisation provides the test certificates without warranty of any kind, and shall in no event or case be liable for any damage or liability in connection with the use of the test certificates. {% endhint %} ## Certificates are issued by iSHARE Test CA iSHARE Test certificates are issued by the iSHARE Test Certificate Authority. Please download the certificates, as they are needed to trust the iSHARE Test certificates when interacting with the test environment. In case your knowledge of certificates could use a quick refreshhttps\://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/8M1G8Jl0iPw8PoUkeIir/\~/changes/68/introduction/getting-started/test-participants, refer to the section below on digital certificates. It gives a brief overview of common certificate types, how certificates are used within iSHARE and various OpenSSL commands for certificate conversion. iSHARE's test CA root certificates are available [here](https://ca7.isharetest.net:8442/ejbca/retrieve/ca_certs.jsp). ## About digital certificates More background information on digital certificates is available [here](https://trustbok.ishare.eu/apply-ishare/certificates-cheat-sheet). # Test participants ## Test Service Consumer Test implementation of a service-consuming iSHARE participant. Service Consumer does not expose any service; they only consume services. The former name of this party was **ABC Trucking**. * **Party identifier**: did:ishare:EU.NL.NTRNL-10000001 {% file src="/files/glc9IAqAuOvIoAuBlgaQ" %} ## Test Participant Registry Test implementation of the Participant Registry. The Participant Registry maintains the trusted list of all iSHARE participants. The former name of this party was **iSHARE Satellite**. * **Party identifier**: did:ishare:EU.NL.NTRNL-10000000 * **API Endpoint base URL**: [https://sat-mw.uat.isharetest.net](https://sat-mw.uat.isharetest.net/) * **OpenAPI Specification**: [Participant Registry OpenAPI](https://openapi.ishare.eu/) {% file src="/files/n5PqdL1gFhvEEKXdhMY0" %} {% hint style="info" %} **Note** `/certificate_validation`, `/me`, `/testing/generate-jws`, `/testing/generate-authorize-request` endpoints in Swagger UI are not a part of the official iSHARE specification. They are provided for additional test functionality only. Therefore, they are unavailable in the production environment. {% endhint %} ## Test Service Provider A Test implementation of a Service Provider. Besides the required /token and /capabilities endpoints, Test Service Provider exposes various services under iSHARE. The former name of this party was **Warehouse 13**. * **Party identifier**: did:ishare:EU.NL.NTRNL-10000003 * **API Endpoint base URL**: [https://w13.isharetest.net](https://w13.isharetest.net/) * **OpenAPI Specification**: [W13 Swagger UI](https://w13.isharetest.net/swagger) {% file src="/files/MGLyE37N3QNqYpzdeZfw" %} {% hint style="info" %} **Note** `/me`, and `/boom_access` endpoints in Swagger UI are neither a part of the official iSHARE specification nor W13 business logic-specific endpoints. They are provided for additional test functionality only. {% endhint %} ## Test Service Provider B Test implementation of an iSHARE Service Provider. Besides the required /token and /capabilities endpoints, Test Service Provider B exposes different services under iSHARE. The former name of this party was **Awesome Widgets**. * **Party identifier**: did:ishare:EU.NL.NTRNL-10000002 * **API Endpoint base URL**: [https://awesome.isharetest.net](https://awesome.isharetest.net/) * **OpenAPI Specification**: [AW Swagger UI](https://awesome.isharetest.net/swagger) {% file src="/files/ODMRFXyJArTi4IAzvUCw" %} {% hint style="info" %} **Note** `/me`, and `/boom_access` endpoints in Swagger UI are neither a part of the official iSHARE specification nor AW business logic-specific endpoints. They are provided for additional test functionality only. {% endhint %} ## Test Entitled Party Test implementation of an Entitled Party. Besides being a resource owner across many systems, Test Entitled Party also provides the possibility to manage authorisations in its systems. Just as an Authorisation Registry, this Entitled Party provides a /delegation endpoint. The former name of this party was **Banana & Co**. * **Party identifier**: did:ishare:EU.NL.NTRNL-10000005 * **API Endpoint base URL**: [https://banana.isharetest.net](https://banana.isharetest.net/) * **OpenAPI Specification**: [B\&C Swagger UI](https://banana.isharetest.net/swagger) * **UI for policies management**: {% file src="/files/Bl1mL3OQNsVS9EaRjpKW" %} {% hint style="info" %} **Note** `/me` Endpoints in Swagger UI are neither a part of the official iSHARE specification nor B\&C business logic-specific endpoints. They are provided for additional test functionality only. {% endhint %} {% hint style="success" %} **Tip** If you need to test against this Entitled Party’s delegation endpoint, please [contact the iSHARE Foundation](https://ishare.eu/contact/), and we will issue an account for you in order to access the UI. {% endhint %} ## Test Authorisation Registry Test implementation of an Authorisation Registry. Users can get an account for the Authorisation Registry, so they can manage some dummy policies for testing authorisation flows. {% hint style="warning" %} **Warning** This is merely a tool for testing and as such is not fit for production/live situations. The Registry gives an idea of what an Authorisation Registry could look like, but the entire user interface is not mandatory. {% endhint %} * **Party identifier**: did:ishare:EU.NL.NTRNL-10000004 * **API Endpoint base URL**: [https://ar.isharetest.net](https://ar.isharetest.net/) * **OpenAPI Specification**: [AR Swagger UI](https://ar.isharetest.net/swagger) * **UI for policies management**: {% file src="/files/FivEckh3LEYhiw8Z64on" %} {% hint style="info" %} **Note** `/me` and `/policy` endpoints in Swagger UI are not a part of the official iSHARE specification. They are provided for additional test functionality only. {% endhint %} {% hint style="success" %} **Tip** If you need to test against this Authorisation Registry’s delegation endpoint, please [contact the iSHARE Foundation](https://ishare.eu/contact/), and we will issue an account for you to access the UI. {% endhint %} ## Test Identity Provider Currently not available as a test implementation. * **Party identifier**: did:ishare:EU.NL.NTRNL-10000006 {% file src="/files/NJnvHnid06jpUSoKu7QU" %} # OpenAPI Descriptions The endpoints that are defined in this developer documentation as part of the iSHARE Framework are also available in OpenAPI descriptions and are published on the iSHARE OpenAPI specifications. In each endpoint, links are provided to relevant parts of the OpenAPI description. The complete OpenAPI descriptions are available here: * Human-readable: * The site will automatically present you with the latest available version. Use the version pull-down (top right) to select any previous version. * Machine readable (YAML): /ishare\_openapi\_spec.yaml * Remember to replace \ with the required version number (for example: 2.2) # Postman collections {% hint style="warning" %} These Postman collections are compatible with iSHARE 2.0. An updated version will be available and published here soon. {% endhint %} This section contains various Postman collections, which can be used to manually test iSHARE APIs. In these collections, you, as a user, are impersonating Test participant ‘ABC Trucking’. In order to impersonate ABC Trucking, these Postman collections contain the private key of ABC Trucking. For non-dummy parties, private keys should never be shared with the Scheme Owner or other iSHARE Parties Each collection contains all API endpoints of a specific Test participant, and as ABC Trucking, you are able to consume these API endpoints. ### Downloads For the collections to work, please download iSHARE `environment` and `globals`. Then download the following Postman collections: {% file src="/files/ZGRhVrR5P3ZpTitXcq7U" %} End-2-End flow: ABC Trucking gets container data from Warehouse 13 (Service Consumer provides Delegation Evidence) (Service Provider requests Delegation Evidence) Postman collection {% endfile %} {% file src="/files/O0m8Air1ut4sN1eb8bwg" %} End-2-End flow: ABC Trucking gets container data from Warehouse 13 (Service Provider requests Delegation Evidence) Postman collection {% endfile %} {% file src="/files/CvCLqW9RafsUzu13quaW" %} ABC Trucking and Awesome Widgets Postman collection {% endfile %} {% file src="/files/hxiR39NbLqNydXcdEPik" %} ABC Trucking and the Authorization Registry Postman collection {% endfile %} {% file src="/files/wkneDFTjTpruj7j2Lk5m" %} ABC Trucking and Warehouse 13 Postman collection {% endfile %} {% file src="/files/QxrJmNP9TMzzFPKWhtNr" %} ABC Trucking and the Satellite (from iSHARE Trust Framework version 2.x onwards)and its related [`environment`](https://dev.ishare.eu/_downloads/ca3b072f85efad28432ec31bb8689eb9/13feb2024_iSHARE_satellite_PIR_Test_env.postman_collection.json) {% endfile %} {% file src="/files/vrAd1q2IIcFtZPxJjaIA" %} Globals {% endfile %} {% file src="/files/cXWA5DaW6gzMcry7yRhY" %} Environment {% endfile %} ### Instructions To request an access token: * Open the /token request * The client\_assertion is generated in the background * Run the request without making additional changes, and the response should contain (among others) an access token value To request a service: * Open a service request * The access token is automatically copied. * Run the request, the response should contain (an encoded) response * If the response is encoded, decode the token via [jwt.io](https://www.jwt.io/) and inspect the results {% hint style="info" %} There is a Walkthrough of the Postman Collection in the [Trust Body of Knowledge](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/postman-collections). {% endhint %} # Verifiable Credentials This section introduces how Verifiable Credentials (VCs) are used in the iSHARE documentation set and where to find the normative requirements and implementation details. VCs are used to issue, present, and verify signed claims (e.g., membership, roles, mandates) in a portable way, so different parties can validate the same evidence consistently. In order to implement VC flows, start with the normative specifications, schemas, and then follow the endpoint requirements for your role. **Next steps:** * [**VC Specifications**](https://dev.ishare.eu/reference/verifiable-credentials-specifications) (W3C VC / DCP / OpenID4VCI/VP) * [**Credential schemas**](/reference/credential-schemas) * [**H2M Verifiable Credential endpoints**](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints) including [**OpenID4VCI endpoints**](/identity-provider/h2m-verifiable-credential-endpoints/openid4vci-endpoints) and [**OpenID4VP endpoints**](/entitled-party/h2m-verifiable-credential-endpoints/openid4vp-endpoints), and/or [**M2M Verifiable Credential endpoints**](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints) including DCP endpoints (as applicable per role) # Release info ## Version 2.0.1 Version 2.0.1 of the iSHARE Developer Portal contains: * Minor fixes (typos, etc.) * A new publication engine, resulting in a new look & feel of the developer portal, including changed API descriptions, directly included from the [iSHARE OpenAPI specifications](https://openapi.ishare.eu/?version=2.2) * Getting started pages for each role * Note on each page that is to be considered a formal part of the framework * Minor restructuring of the content * A new introduction page * Addition of a page describing the [single-party endpoint](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/ishare-participant-registry-role/single-party.md) ## Version 2.0 With the release of v2.0 of the iSHARE scheme, several changes have been brought to the participants of iSHARE. Mostly, the changes are about (technically) federating the participant onboarding process and the introduction of the Data Spaces concept. Kindly refer to the [Scheme v2.0](https://framework.ishare.eu/is/?l=en) for more information on the non-technical changes done to the scheme. On this page, we describe the technical changes that participants will face due to v2.0 and how they can plan their migration. But first, let's list what has changed: * Introduction of Satellite role (replacing the Scheme Owner for the participant administration part) * Introduction of Data Spaces ### iSHARE Satellite Role Participant registration can now be done by any organisation playing the role of the iSHARE satellite. Additionally, now more information about a participant is registered and is made available via the APIs. Though utmost care has been taken to keep changes backwards compatible, not all changes may have been backwards compatible. In terms of APIs from the Scheme Owner to the Satellite following is the status of their changes: * */connect/token* – no change * */capabilities* – no change * */parties* – updated with new additional information. **The certifications** attribute is renamed to **roles**. For more details, [refer to the API spec](/participant-registry-role/parties) * */party* – is removed as per the deprecation warning. The same functionality is available in /parties endpoint * */trusted-list* – no change * */versions* – no change * */dataspaces* – new endpoint listing all the registered Data Spaces details. [Refer to the API spec](/participant-registry-role/dataspaces) * */ep\_creation* – new endpoint allowing satellites to create an Entitled Party programatically via API based on their validation and proof from a certified Identity Provider. Note: this API is only for creating an Entitled Party without a PKI certificate #### Migrating to a new backend To prepare for migration from the old backend to the new backend following changes in /parties endpoint must be considered. * Change of **Certifications** attribute to **Roles** attribute. * Additional attributes are now also added; however, as per the spec, the implementation should ignore the additional attributes, so it is expected to be backwards compatible. Please refer to the API specs for details of attributes that are now available via the/parties endpoint and adapt your code to consider them if needed. * Now parties' information also contains the x5c value of the PKI certificate, which can be used in matching the certificate received in client\_assertion from the requestor. The updated authentication process can be found [M2M Authentication](/reference/authentication). #### Process for migration Once you have familiarised yourself with the changes and prepared for changes on your end, you may want to register your organisation and other organisations in the test environment, if not done so already: 1. Provide a test certificate along with (test) EORI for registering in the test satellite. In case you do not have a test certificate, you can request one from [our test CA](https://ca7.isharetest.net:8442/ejbca/ra). 2. Make the changes in your code and test them in the test network with other parties or using dummy parties. 3. Publish your changes and request conformance testing. [Details](/introduction/conformance-test-tool). 4. When passed, make sure that you submit the CTT results and PKI certificate for registering your organisation in the production environment by [sending a request](https://ishare.eu/home/contact/). {% hint style="info" %} To provide continuity, iSHARE Foundation will still register participants on the production satellite run by the foundation. If participants wish to register themselves via other satellites, they are free to do so. {% endhint %} # Help & support Code snippets can be found on our [GitHub account](https://github.com/iSHAREScheme). If you’d like to add your own libraries and help the iSHARE Community, [please let us know](https://ishare.eu/home/contact/). If you have any questions about iSHARE, be sure to visit the [Trust Body of Knowledge](https://trustbok.ishare.eu/) or submit a ticket at our[ Support Portal](https://support.ishare.eu/support/tickets/new). # Specific technical standards Specific implementations of OAuth 2.0 and OpenID Connect 1.0 are used to facilitate an ecosystem in which parties can interact with previously unknown parties. Pre-registration, therefore, is not a prerequisite, and this requires alterations to the official standards. Also, for the authentication of parties within an iSHARE (data spaces/network) context, it uses PKI and digital certificates relating to all participating parties. ### Technical standards used in iSHARE and configuration aspects The iSHARE Trust Framework also prescribes various general interface specifications described in the corresponding topic pages. More information on the technical standards can be found in the [Knowledge Base.](https://trustbok.ishare.eu/apply-ishare/technical-standards)
Technical standardCharacterDescription
PKIArchitectural principleFor interoperability on a European scale, all trusted roots under the eIDAS regulation will be trusted within data spaces/iSHARE network.
OAuth 2.0Open standard for authenticationThe OAuth 2.0 subpage describes the generic Authentication flow.
OpenID Connect 1.0Open standard for authentication of humansFunctions as an additional layer on top of the OAuth 2.0 protocol.
HTTP(S)Communication protocolAn overview of relevant iSHARE HTTP response codes can be found here.
TLSCryptographic protocolWithin data spaces/iSHARE network, TLS 1.2 MUST be used for securing all HTTP communications.
JSON Web Token (JWT)Open standard for definition of access tokensA JSON Web Token (JWT) is used in data spaces/ iSHARE network when non-repudiation between parties is required.
XACML 3.0Access control policy languageWithin data spaces/ iSHARE network, a JSON port of XACML 3.0 is used to enable parties to communicate delegation evidence.
CachingTemporary data storageIn iSHARE, caching is used to optimise API interactions by reducing latency and load on services while ensuring data consistency and security.
DIDIdentifierA Decentralised Identifier (DID) is assigned to legal entities during onboarding in compliance with the iSHARE framework using the did:ishare method.
UTCTime FormatAll dates and times in iSHARE must be communicated in UTC and formatted as Unix timestamps.
X.509Cryptographic protocolIn iSHARE, X.509 certificates are used for secure identity verification, authentication, and encryption
Verifiable Credentials (VC)Open standard for verifiable digital credentialsVerifiable Credentials, as defined by the W3C Verifiable Credentials Data Model 2.0, enable participants to issue, present, and verify digitally signed credentials. They provide cryptographic assurance of identity and authorisation, support selective disclosure for privacy, and ensure interoperability with frameworks such as eIDAS 2.0 and EBSI.
# JSON Web Token (JWT) A JSON Web Token (JWT) is used when non-repudiation between parties is required. A statement, of which the data is encoded in JSON, is digitally signed to protect the authenticity and integrity of the statement. iSHARE uses signed JWTs in the following ways: 1. In a request for an OAuth Access Token or an OpenID Connect ID token, the client sends a signed JWT. The client is authenticated based on the verification of the JWT's signature. 2. Delegation evidence is presented as a signed JWT. The signature of the Authorisation Registry or Entitled Party provides proof to other parties. 3. In a response from a server, iSHARE metadata is presented as a signed JWT. The signature is used to bind the iSHARE metadata (such as license information) in the JWT to the content of the response. 4. A service from an iSHARE Service Provider MAY require a request to be signed. On [this page](/reference/ishare-jwt), the generic requirements for a signed iSHARE JWT are specified. # OAuth 2.0 iSHARE uses the OAuth 2.0 protocol for authenticating parties and providing access tokens when requesting access to a service within iSHARE (for machine-to-machine (M2M) communication). Specifically, it uses the OAuth 2.0 Client Credentials flow. On this page, a brief description of OAuth is provided. For the most recent version of the OAuth 2.0 specification, click on [this link](https://oauth.net/2/). iSHARE facilitates an ecosystem within which parties can interact with previously unknown parties; pre-registration is therefore not a prerequisite and thus requires alterations to the official standard. ### iSHARE authentication flow iSHARE requirements for iSHARE M2M OAuth 2.0-based Authentication are defined [here](/reference/authentication#machine-to-machine-m2m-authentication). ### OAuth 2.0 general description OAuth is an open standard for authorisation, which is used by e.g. Google, Facebook, Microsoft, Twitter, etc. to let their users exchange information about their accounts with other applications or websites. OAuth is designed to work with HTTP. Through OAuth, users can authorise third-party applications or websites to access their account information on other "master" systems without the need to exchange their credentials to log in to the platform. OAuth provides a "secure delegated access" to resources (email accounts, picture accounts, etc.) on behalf of the resource owner. It specifies a method for resource owners to authorise third-party access to their resources without exchanging their credentials (username, password). Authorisation servers (of the platform) issue access tokens to third-party clients (applications or websites) with the approval of the resource owner (= end user). The third-party client needs the access token to get access to the resources that are stored on the resource server (of the master system). # OpenID Connect 1.0 Besides Machine2Machine interaction, it can occur that it is relevant if a specific person requests data or a service. In order to provide a Service Provider with identity information on a human subject, iSHARE uses the OpenID Connect 1.0 protocol. The iSHARE use of OpenID Connect 1.0 is based on the requirements of the [official standard](http://openid.net/specs/openid-connect-core-1_0.html). iSHARE facilitates an ecosystem within which parties can interact with previously unknown parties; pre-registration is therefore not a prerequisite and thus requires alterations to the official standard. ### Description OpenID Connect (OIDC) is the authentication layer that is built on top of the OAuth 2.0 protocol, which is an authorisation framework. The OIDC authentication layer allows clients to verify the ID and obtain basic profile information of their end-users The authentication is performed by the authorisation server (managing the access rights and conditions) in an interoperable and REST-like manner. ### OpenID Connect's building blocks OIDC specifies a RESTful HTTP API using JSON as a data format. REST (Representational state transfer) or RESTful web services provide a method to achieve interoperability between computer systems and the internet. APIs (Application Programming Interfaces) enable Machine-to-Machine (M2M) communication, where one machine calls upon the software functionality of another machine. They facilitate connectivity between applications. It is a software architectural approach that revolves around the view on digital interfaces that APIs provide self-service, one-to-many, reusable interfaces. With OIDC, a broad range of clients (web-based, mobile, JavaScript) can request and receive data about authentication sessions and end-user profiles. The specification is extensible (meaning it considers future growth) and supports optional features for encryption, ID data, discovery of OpenID providers and session management ### OpenID Connect 1.0 OpenID Connect 1.0 is an adapted version of OpenID, combined with OAuth 2.0. OpenID Connect performs many of the same tasks as OpenID 2.0, but in an API-friendly way and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas the integration of OAuth 1.0a with OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself. ### iSHARE H2M authentication flow Based on the described standards and specifications in this scheme, the generic iSHARE Human2Machine Authentication flow is described [here](/reference/authentication#human-to-machine-h2m-authentication). The OpenID Connect 1.0 flow contains 2 important iSHARE-specific JWTs, which are described in more detail in [this section](https://dev.ishareworks.org/#operation--iSHARE_human_identity_details3-get) of the developer portal. {% hint style="warning" %} **Authorisation in OpenID Connect flow** The generic OpenID Connect 1.0 flow does not take into account Authorisations of a human. However, in iSHARE, it is essential that authorisations of a user are combined with their identity details before a service can be offered. This authorisation flow is heavily dependent on the pseudonym used to refer to humans without exposing their identity. This section of the scheme is under construction, and parties wishing to implement authorisations of a user are advised to [contact the iSHARE Foundation](https://ishare.eu/contact/). {% endhint %} # PKI For authentication purposes, iSHARE requires adhering and Certified Parties to acquire an X.509 certificate, which is distributed by a trusted root under certain PKIs (Public Key Infrastructure). For interoperability on a European scale, all trusted roots under the eIDAS regulation will be trusted within iSHARE. ### Brief description A PKI is a system for the distribution and management of digital keys and certificates, which enables secure authentication of parties interacting with each other. Generally, three different methods exist for creating trust within PKIs. These are through 'Certificate Authorities', 'Web of Trust' and 'Simple PKI'. Within iSHARE, the 'Certificate Authority' approach is used, and as such, the other methods will not be discussed. A PKI can be considered a chain of certificates. At the beginning of the chain is the root 'Certificate Authority' (CA), a public trusted party which is allowed to digitally sign its own certificates (SSC, self-signed certificate). This 'Root CA' distributes certificates and encryption keys to organisations. The certificate is signed by the 'root CA' as proof that the owner of the certificate is trusted. These organisations can start distributing certificates as well, if allowed by their root. They become CAs, and as such, sign the certificates that they distribute. Repeating these steps, a chain of certificates is created, with each certificate signed by the CA that distributed the certificate. Parties need to trust a certificate for authentication purposes. Instead of trusting individual certificates of organisations, root certificates can be trusted. By trusting a root, all certificates that have the root within their PKI chains are automatically trusted. Most large root CAs are automatically trusted within web browsers, enabling computers to safely interact with most web servers. ### Trusted roots and eIDAS iSHARE supports digital certificates that are recognised under eIDAS as Advanced or Qualified Certificates. The eIDAS regulation aims to provide secure and seamless electronic interactions between businesses, citizens and public authorities throughout the entire European Union. A main part of this regulation is that each EU country is required to establish and maintain 'trusted lists', among which trusted root information is found. Each EU country is required to implement these trusted lists in their own country. Therefore, iSHARE aims to make use of these trusted lists as trust roots within iSHARE to ensure secure and seamless interaction throughout the entire EU. # TLS HTTP communication within iSHARE is encrypted using TLS versions up to their end of life (EOL). Currently, this means TLS 1.2 or 1.3. On this page, a brief description of TLS is provided. For the most recent version of the specification, click on [this link](https://tools.ietf.org/html/rfc5246). ### Description Transport Layer Security (TLS) is a cryptographic protocol that describes communication security for computer networks. The first version of TLS 1.0 is built upon and is an upgrade of SSL 3.0 (Secure Sockets Layer). ### Differences and similarities between TLS and SSL Both TLS and SSL provide means for data encryption and authentication between applications, machines and servers when data is sent through an insecure network. The differences between TLS and its forerunner, Secure Sockets Layer (SSL), are the addressed vulnerabilities. TLS, for instance, works with * a wider variety of hash functions. * more secure and stronger cypher suites, such as the Advanced Encryption Standard (AES) cypher suites, which are integrated into TLS version 1.1. * browser security warnings. TLS has more alert descriptions than SSL. # XACML 3.0 Within iSHARE, it is essential to provide fine-grained authorisation. Besides rules on the authorisation, it is important to have varying options to describe the resources and their attributes to which the rules apply. XACML 3.0 is a specification for describing such authorisation rules, but it is XML-based. For iSHARE, a JSON port was created for expressing the XACML specifications regarding authorisation. This 'delegation evidence structure' is discussed in more detail in the chapter on [delegation evidence structure](/authorisation-registry-role/delegation-endpoint#response-model). On this page, a brief description of XACML is provided. For the most recent version of the specification, click on [this link](http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html). ### Description XACML (eXtensible Access Control Markup Language) is an XML-based specification that is designed to control access to applications. One of the main advantages of this specification is that applications and systems with their own and different authorisation structure can be integrated into one authorisation scheme. authorisation and the rules surrounding it can be managed centrally, regardless of the authorisation mechanism of the applications themselves. This phenomenon is called externalisation. XACML is derived from SAML and provides the underlying specification for ABAC (Attribute-Based Access Control). XACML is also suitable to be used in combination with RBAC (Role-Based Access Control). Moreover, with the help of XACML, authorisation can be arranged and managed in detail. This is called fine-grained authorisation. XACML supports the use of security labels, rules with arbitrary attributes, rules with a certain duration and dynamic rules. In XACML, two main functions can be distinguished. One function defines the criteria with which authorisations are assigned, such as 'only an experienced user from department X is allowed to modify documents’. The other function compares the criteria with the rules or policies to determine whether a person is allowed to perform the operation on the object or not. The architecture of XACML is fairly complex. This is partly due to the fact that it is difficult to fit the various components of XACML in the application landscape. These components should be positioned in such a way that the owner of the data can somehow control the authorisation to his or her data, but at the same time, the components should be positioned in such a way that the performance is not negatively influenced. This is extra important when independent parties need to cooperate with each other and want to jointly organise access to their applications. Finally, applications need to be compatible with XACML. # Caching Caching is a way to boost performance efficiency. Often, data is temporarily stored on a different medium to enable faster access to the data. For every API that is compliant with iSHARE, caching MUST be made explicit to the API consumer. If a response is not cacheable, it MUST contain the following headers: Copy ``` Cache-Control: no-store Pragma: no-cache ``` If a response is cacheable, it MUST contain the following headers: Copy ``` Cache-Control: max-age=31536000 ``` {% hint style="info" %} **Note** max-age MAY vary {% endhint %} # DID A DID (Decentralised Identifier) is issued to legal entities during onboarding in compliance with the iSHARE framework, utilising the DID method. DID Method is used to issue a unique iSHARE identifier to legal entities when onboarding, following the iSHARE framework compliant method `did:ishare`. Specification of the iSHARE DID method is available here: . This identifier follows a standardised format conforming to global decentralised identity protocols and points to a REST-compliant API for retrieval. The identifier consists of the organisation’s unique ID as defined by national or international standards (e.g., PKI certificate or eIDAS), ensuring secure identity verification. Core elements about DID can be found [here](https://www.w3.org/TR/did-core/). # Date/time formatting iSHARE adopts internationally recognised standards for expressing dates and times: * **UTC (Coordinated Universal Time)** – Time standard unaffected by time zones or daylight saving time. * **Unix Timestamp** – The number of seconds elapsed since the Unix epoch (1970-01-01T00:00:00Z, UTC). * *Example:* `1536089675` represents **2018-09-04T19:34:35Z**. * **RFC3339 /** **ISO 8601 Date-Time Format** – A human-readable and machine-parseable representation of date and time in UTC, using the Z suffix (as defined in [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) and [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339.html)). * *Example:* `2025-09-22T14:05:30.123Z`. **Requirement**\ All date-time values **MUST** be expressed in UTC and **MUST** follow the ISO 8601 extended date-time format with milliseconds, and the `Z` UTC indicator, e.g. `YYYY-MM-DDTHH:MM:SS.sssZ`. Unless explicitly specified, ISO8601 date-time in UTC is the default format. An exception is, for example, the [iSHARE JWT](/reference/ishare-jwt), which specifies the use of a Unix Timestamp (in line with the JWT standard). # X.509 In cryptography, X.509 is a standard defining the format of public key certificates. X.. 509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, an organisation, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. The most recent version of this specification can be found at [tools.ietf.org (RFC 5280)](https://tools.ietf.org/html/rfc5280). X. 509 is used in iSHARE as a standard defining the format of public key certificates. # HTTP response codes After sending an HTTP request to a server, the server responds with (among others) a Status Code, which indicates the outcome of the request made to the server. Within the iSHARE Scheme, the HTTP standard concerning response codes is followed as established by the IETF. Please refer to the [IETF website](https://www.ietf.org/assignments/http-status-codes/http-status-codes.xml) for further specifications. Within iSHARE, the HTTP response codes 401, 403, 406, 409 and 412 are most relevant.
HTTP VerbCRUDEntire Collection (e.g. /customers)Specific Item (e.g. /customers/{id})
POSTCreate201 (Created), 'Location' header with link to /customers/{id} containing new ID.404 (Not Found), 409 (Conflict) if resource already exists..
GETRead200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists.200 (OK), single customer. 404 (Not Found), if ID not found or invalid.
PUTUpdate/Replace404 (Not Found), unless you want to update/replace every resource in the entire collection.200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
PATCHUpdate/Modify404 (Not Found), unless you want to modify the collection itself.200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
DELETEDelete404 (Not Found), unless you want to delete the whole collection—not often desirable.200 (OK). 404 (Not Found), if ID not found or invalid.
# Verifiable Credentials (VC) The iSHARE Trust Framework supports Verifiable Credentials adhering to W3C Verifiable Credentials Data Model 2.0 as a technical standard for representing verifiable identity, adherence, and authorisation information. This functionality complements the existing OAuth 2.0 and OpenID Connect 1.0 standards within iSHARE, offering an additional, decentralised mechanism for establishing trust across data spaces. VCs enable flexible use across both machine-to-machine (M2M) and human-to-machine (H2M) contexts. ### Associated Protocols The iSHARE specifications refers to following standards to enable issuance and verification of the VCs: * For human-to-machine interaction: * [OpenID for Verifiable Credential Issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) (OID4VCI): defines how credentials are securely issued using OAuth 2.0-compatible flows. * [OpenID for Verifiable Presentations ](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)(OID4VP): defines how holders present credentials and how verifiers validate them in a standardised request/response exchange. * For machine-to-machine interaction: * [Decentralized Claims Protocol](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/) (DCP): defines how credentials are issued and presented in a data space machine-to-machine context. These protocols ensure that credential flows integrate seamlessly with iSHARE authorisation flows while remaining interoperable with external wallets and identity ecosystems such as eIDAS 2.0. ### Backwards Compatibility and Hybrid Use To maintain backward compatibility, iSHARE supports a hybrid trust model where either Verifiable Credentials or existing JWT-based tokens can be used. This allows gradual adoption of VC-based trust interactions without disrupting existing authorisation and identity processes. # UI Guidelines Follow these guidelines for the iSHARE sign-in button
Refer to the [iSHARE Brand Guidelines](#brand-guidelines) for more information on using the brand elements ### iSHARE logo The URL below should be used for the visual asset of the button. This allows us to approximate anonymised usage statistics of the logo. Also, you can use iSHARE SVG files that are available for download: * [Only logo](https://dev-old.ishare.eu/_downloads/d7459f4fdc82a5d4f44b192019aee650/ishare%20only%20logo.svg) * [Logo with iSHARE at the bottom](https://dev-old.ishare.eu/_downloads/4b830eba02ab07523c594cc87f5d8237/ishare%20logo%20bottom.svg) * [Logo with iSHARE on the right](https://dev-old.ishare.eu/_downloads/7dd14c3b3611478d7ed1b2dd6959b867/ishare%20logo%20right.svg) ### Equal prominence The iSHARE Sign-In button must be displayed at least as prominently as other third-party sign-in options. For example, buttons should be approximately the same size and have similar visual weight. ### Matching your own app’s style Using the standard iSHARE Sign-In button is strongly recommended as it enables iSHARE users to more quickly identify the iSHARE option. If you need to adapt the button to match your app design or translate the text “Sign in with” or “Sign in”, follow these guidelines. #### Size You can scale the button as needed for different devices and screen sizes, but you must preserve the aspect ratio so that the iSHARE logo is not stretched. #### Text To encourage users to click the button, we recommend the call-to-action text “Sign in with iSHARE”. It should be clear to the user that they are signing in to your app for your app with their iSHARE credentials. #### “iSHARE” Text You can use the word “iSHARE” by itself in the button if it is accompanied by adjacent text that makes it clear what the action is. For example:
#### Colour The colour for an unpressed button is #FFFFFF (white). The colour of the button text is #61385F (dark purple). The button must always include the standard colour iSHARE logo. {% hint style="info" %} **Note** Dark mode is not yet ready. {% endhint %} #### Font The button font-family is Lato, and font-weight is 700. Do not use other fonts on the button, except as noted for situations with Matching your own app’s style. #### Padding The padding to the left, right, top and bottom of the text should be 12px. The logo should be 25px in size, text “iSHARE” should be 18px. There should be a 12px space between the logo and the button text. If you need the sign-in button to be smaller or bigger, keep the same proportions. #### iSHARE logo in the “Sign in with iSHARE” button Regardless of the text, you can’t change the size or colour of the iSHARE logo. It must be the standard colour version and appear on a white background.
### Incorrect button design * Do not use the iSHARE icon or logo by itself without the button boundary and without text to indicate the user action.
* Do not use an iSHARE icon by itself to represent iSHARE Sign-In.
* Do not put the iSHARE icon on a coloured background.
* Do not create your own icon for the button.
* Do not recolour the icon of iSHARE
### Brand Guidelines {% file src="/files/cIZOgxBkXzJkEmpfEEh5" %} Brand Guidelines {% endfile %} # Conformance test tool {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The Conformance Test Tool (CTT) enables users to perform automated tests on their API services. To be allowed to join the production environment of the iSHARE Network, parties will need to pass all test cases that apply to their role in the iSHARE Network. The CTT will show you, per test case, whether you passed or failed the case. To be able to join the iSHARE network in the production environment, you are required to pass a full test run for your specific role in the network. If you have passed the test run for your specific role, please notify us () with the identifier of your test run. ### Portal Users can log in to the CTT at the [admin portal](https://ctt.isharetest.net/admin) and run a set of test cases on their API services. In order to log in, please [request an account](https://ishare.eu/home/contact/). Key functionalities that users of the Conformance Test Tool can perform: * Run the full test run for a specific role in the iSHARE Framework (i.e. Service Provider or Authorisation Registry) on your API services; * Run a test run on your specific API Service (i.e. /token or /delegation); * Run a specific test case on your API Service. After logging in to the Conformance Test Tool, users will be able to configure the endpoints of their API services and will be able to run the test cases on the API services themselves. After a test run completes, users will receive the results of the test run in the CTT. The results will display if you have passed the tests, or if not, which test cases failed, and why. The user interface is made in such a way that it will be easy to understand for anyone what test cases have passed and failed, and why. However, some test cases consist of multiple steps, so in order to understand which exact step has failed, detailed logs are needed. CTT provides raw JSON step-by-step dumps for completed test runs, but those logs might be too technical for business people or non-technical IT specialists to read. If your service fails at least one test case, it is not yet conforming to the iSHARE standards as specified in the scheme and on the developer portal. ### Test Case Specifications The API services that need to conform to iSHARE standards differ per party role in the iSHARE Network. Different roles in the iSHARE Network require different sets of test cases, as is detailed below. Below is only a list of required endpoints; the full list of test cases per API service can be found on the [CTT test cases page](https://ctt.isharetest.net/admin/test-cases). {% hint style="info" %} **Note** The Conformance Test Tool can only check if you validate test certificates correctly. It is your responsibility to validate PKI certificates correctly. To learn more, please read the [Certificate Validation](/reference/authentication#certificate-validation) section. {% endhint %} **Service Consumers** * The Service Consumer does not necessarily host API services. The only requirement is to be able to get a valid access token from the Participant Registry. **Service Providers** * The /token endpoint MUST conform to the iSHARE standards; * The /capabilities endpoint MUST conform to the iSHARE standards. **Authorisation Registries** * The /token endpoint MUST conform to the iSHARE standards; * The /capabilities endpoint MUST conform to the iSHARE standards; * The /delegation endpoint MUST conform to the iSHARE standards. For proper testing of this endpoint, users SHOULD provide two valid delegation requests: one that returns a “Permit” when requested, and one that returns a “Deny” when requested. {% hint style="success" %} If you want to test your delegation endpoint, it is necessary to add Test Service Consumer 1’s ID (did:ishare:EU.NL.NTRNL-10000001) in some test-policy. This delegation will be tested during conformance testing. {% endhint %} **Identity Providers** * The /capabilities endpoint MUST conform to the iSHARE standards; * The /authorise endpoint MUST conform to the iSHARE standards. For proper testing of this endpoint, users SHOULD provide an error endpoint to which users will be redirected on invalid authorize requests. * The /token endpoints (both M2M and H2M) MUST be conforming to the iSHARE standards; * The /userinfo endpoint MUST conform to the iSHARE standards. For proper testing of this endpoint, users SHOULD provide two valid delegation requests: one that returns a “Permit” when requested, and one that returns a “Deny” when requested. For proper testing of IdP endpoints, users SHOULD provide a login endpoint towards which human authentication requests will be sent. In addition, users should also provide username and password HTTP request body parameter names that their API expects, with existing human user credentials that are going to simulate the login. {% hint style="info" %} `/token` Endpoint requirements for Identity Providers are different from those for the other iSHARE participants. {% endhint %} ### Delegations testing An important aspect of testing an Authorisation Registry is testing the /delegations endpoint. To be able to do this testing, it is necessary that the Conformance Test Tool can retrieve a ‘*dummy*’ delegation. Users can enter two delegation masks in the Conformance Test Tool: * **A Permit Mask**: This is a delegation mask that should resolve to “Permit” when used in a delegation request * **A Deny Mask**: This is a delegation mask that should resolve to “Deny” when used in a delegation request The Conformance Test Tool does multiple ‘valid requests’ to ensure that the implementation is correct. For example, one test case does a delegation request as if the request is done by the ‘accessSubject’ of the delegation mask. Another test case does a delegation request as if the request is done by a Service Provider from the ‘environment’ of the delegation mask. This requires the use of the ‘previous\_steps’ field (see iSHARE Authorisation). For these delegation requests to work, it is important to know the following: * The ‘accessSubject’ in the delegation mask needs to be ‘`did:ishare:EU.NL.NTRNL-10000001`’ * The ‘environment’ in the delegation mask needs to contain the Service Provider.`did:ishare:EU.NL.NTRNL-10000003`’ * A ‘client\_assertion’ from ‘`did:ishare:EU.NL.NTRNL-10000001`’ to ‘`did:ishare:EU.NL.NTRNL10000003`’ is included in ‘previous\_steps’ in the delegation request when the request is done by ‘`did:ishare:EU.NL.NTRNL-10000003`’ Below you can see an example of the body of such a request. ```json { "delegationRequest": { "policyIssuer": "did:ishare:EU.NL.NTRNL-10000005", "target": { "accessSubject": "did:ishare:EU.NL.NTRNL-10000001" }, "policySets": [ { "policies": [ { "target": { "resource": { "type": "CONTAINER.DATA", "identifiers": [ "ID.12345" ], "attributes": [ "CONTAINER.ETA" ] }, "actions": [ "iSHARE.READ" ], "environment": { "serviceProviders": [ "did:ishare:EU.NL.NTRNL-10000003" ] } }, "rules": [ { "effect": "Permit" } ] } ] } ] }, "previous_steps": [ "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlFZ1RDQ0FtbWdBd0lCQWdJSU45VmlDRGkzQndzd0RRWUpLb1pJaHZjTkFRRUxCUUF3U0RFWk1CY0dBMVVFQXd3UWFWTklRVkpGVkdWemRFTkJYMVJNVXpFTk1Bc0dBMVVFQ3d3RVZHVnpkREVQTUEwR0ExVUVDZ3dHYVZOSVFWSkZNUXN3Q1FZRFZRUUdFd0pPVERBZUZ3MHhPVEF5TVRVeE1UUTJNVFZhRncweU1UQXlNVFF4TVRRMk1UVmFNRUl4RlRBVEJnTlZCQU1NREVGQ1F5QlVjblZqYTJsdVp6RWNNQm9HQTFVRUJSTVRSVlV1UlU5U1NTNU9UREF3TURBd01EQXdNVEVMTUFrR0ExVUVCaE1DVGt3d2dnRWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUUMwTzRoVWhEK1ZvT0tWSVpTTk1OVGZ6YzBPMmtZaitaenBRRUFCWkd0UHR5MGtLUEplcDArbzV4c3RvdTFLK1V4dkhmeEVwSHhIR1RkdHFadWMyOExoVTRDZUNnb2VETURUK0NIUzNOb3NpRVNRTXdoL1paZVRjOS9lS0NvNTY5R0NuKzJYdFRpR1NwQlN3TVNXcU5IZ3BBWllLZEhyVC9rRU1JeVRLb2F1dWlLUThjVXA3b3c3bVp6LzlLK3FWM3M5TDAzMFc4SWF3TEpCSksvMmFwQXQ1amgxajQvbUY3ZjBxOHpoemhyQzh2MDFQTGxaZHVUempqQnJlN216K3lpL3ZsWXovZWFwMGVZVGpoeElhdHlWOUZGd2xtaTRGQzFDTmNNdExoOG5zaUpvZTVjQm0xM0xLYlFGdTNHWUg3Nm9lTFp2V3FiUGJwMTFteGxIYS9LZEFnTUJBQUdqZFRCek1Bd0dBMVVkRXdFQi93UUNNQUF3SHdZRFZSMGpCQmd3Rm9BVUZqem5JT25XbE84ZjVhTHh1UHkrNnQ4c040RXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBd0V3SFFZRFZSME9CQllFRkFQSCs4VXJZaVZMWGFLUFJHZmxrQStjdXNRN01BNEdBMVVkRHdFQi93UUVBd0lGb0RBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQWdFQVlsNXRXSDBZdFlTOUp5cXlsWkpXb21BNTVTaEtsbGFCUmN2cm82Q0h4bGxKV0hvMHFDOVpUTWN2Q3l3TXYxNFZKeVFkNmVGWnFjVnRPbHVHclJaQmtsSDlBYW5rb3ZwMkpMYXFjRDc5dDFDeXVYWm5JelRGbC9Ca01zRTZ3bEFKWFkvc2Fybm94ZWllalA0RS9FZi8wZXVJRnZCYUlDQ0YrS2QyV0pZYmJuMFd5MGRINDg0UUpiSHlNdFZmcjQyb0lwVU5WdUxTdTg0eUtZQWVtOUpCdVlUcDNZMEsyaGlFQVcvYk9LRHZ2SGV0VmY1ZnU2NnlmZWtEWDUzajNOS2lGSkNYUzJyS0lab0R1TUZ1eHBTeVZrUzJrYldrMSs1Sm95N3FPU05BTlJGUGxwSGNnekxRWnA4SHJndmhzbWhJdDFWVFZZa3l4Y2Q4cVhBbGh3cVZnT3E1TmdMeGtxdWw5aE5NR2lNN3NxK0g3M1EvRmk4aWY3Z1A4SVZBU3pRR3d1SGcyWjg3aWI2QTJ2b24wZlJKWnEzZkl1YkhveEk2M0FUd2ZjUks4NnkxNzJ4YkZFM1ZVMGR1TjF0STVaMFRDZzBHQUpZdEpwYm52ZXhJdDVsazVGSWs0VGh2UjBMOG1OTHkxRFVhMTFOK0VNeGtxYmZxbFR1ckI4WmczQ1kvUWFTS21YWTVDTVV3V2VFQlhSSGh5ZmtaUTVqUFBVSHJGYW95T1JYOHAxRXJZRGt0QjFLOW80am11RVZwQjMzY3ZnWUJFaUF5VjV6NDQyNkZ1VkNNYkhhRkRWN2lLVzllQmxYb3hlWm80WFg4K2pYeVNMNUdXOFh3TlJUSzVjNHZXMDJRM1ZKeVlWZTV1bWVzdHNLUStMUjhpQXpvVVNyZUsxOCtKa0FqQUpVPSJdfQ.eyJpc3MiOiJFVS5FT1JJLk5MMDAwMDAwMDAxIiwic3ViIjoiRVUuRU9SSS5OTDAwMDAwMDAwMSIsImp0aSI6ImI2YmViNzdmNDcxZTQ3ZDhhYjhmNmMwOTFmYzE4ZGZmIiwiaWF0IjoxNTU5MDUwNjY2LCJuYmYiOjE1NTkwNTA2NjYsImV4cCI6MTU1OTA1MDY5NiwiYXVkIjoiRVUuRU9SSS5OTDAwMDAwMDAwMyJ9.ctJyGBr9ytCWOdm0l6zrBWyiCzuI0h2fm0Hp0UFfisS99jfXvfUVUKauhxwrOYkrAif36xu3jhc0qJMhdmGZ5RXhw8DaHnurP1TH3j1fy8hKPKvwBCbz3PtlQWywWbiVodrtlmVkqK5HU-AMou1JzZIrC5AS5fxprGysfRuL3TcFKkG-VH3MipC7uyjLVutRIlOev_l_gZ9ALyQkBf0wp__uTj--COdukttCmvzCtFtde9JE_Jde6t5N4Wps8jYasWiJEiEFxEFfWvzJKihSpyl-PAHNf304HNMEgQlgw9CG9L-YywKT53vzNITjwYVD_Ihi2ONGmTjMF4bi_Z96yw" ] } ``` ### What is next? After verifying compatibility: In general, you follow the steps listed below. Kindly refer to the admission process at , which is leading * Apply for an appropriate signing certificate with an authorised Certificate Authority which is in the trusted list. Please note that the application may take some time. For general non-binding guidance, please refer to and feel free to contribute your learnings to the same. * Install the certificate on your server * Register certificate with Participant Registry * Sign Accession Agreement * For Certified Roles: provide a signed Assessment Framework for Certified Parties # Roles {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} One of the iSHARE Trust Framework's core features is its description of functional roles. These roles represent the different ways organisations can interact with each other. To ensure federation of all aspects, and no single points of ‘failure’ or ‘power’ in the structure, all roles are defined and can be executed by multiple parties. ### Role definition The principle of a role is that its execution can be done by the same legal entity, but the interface specification assures that an always level playing field/federation is possible. The Trust Framework introduces two core role types: "Adhering Parties" and "Certified Parties” **"Adhering parties"** directly engage with data and include: * [Entitled party](/entitled-party/getting-started): Organisations with rights to access specific services or data. * [Service Provider:](/service-provider-role/getting-started) Organisations offering services for consumption. * [Service Consumer](/service-consumer-role/getting-started): Organisations using services provided by service providers. **"Certified Parties"** are certified to facilitate trusted exchanges between Adhering Parties. They encompass these specific roles: * [Participant Registry (former name: iSHARE Satellite)](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/ishare-participant-registry-role/getting-started.md): Organisations responsible for onboarding participants and trust assurance. * [Authorisation Registry](/authorisation-registry-role/getting-started): Organisations providing Authorisation registry services. * [Identity Provider](/identity-provider/getting-started): Organisations offering identification services for humans. * Identity Broker: Organisations serving as intermediaries between Service Providers and Identity Providers. ### Role identifiers In certain situations, a role identifier is used to identify the [role(s) of a participant](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles). For this purpose, the Trust Framework specifies the following identifiers: | Role identifier | Role | | ------------------------------------------------------- | --------------------------------------------------- | | ServiceConsumer | Service Consumer | | ServiceProvider | Service Provider | | EntitledParty | Entitled Party | | AuthorisationRegistry | Authorisation Registry | | IdentityProvider | Identity Provider | | IdentityBroker | Identity Broker | | ParticipantRegistry (former identifier iShareSatellite) | Participant Registry (former name iSHARE Satellite) | # Verifiable Credential support per role {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} Each role defined in the iSHARE Trust Framework has specific responsibilities related to issuing, holding, or verifying Verifiable Credentials (VCs). The terminology on this page references the [W3C VC Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/). This page describes which roles are expected to provide, consume, or verify particular credential types. It ensures consistent implementation of verifiable identity and authorisation across all iSHARE participants. ### Participant Registry The Participant Registry is responsible for issuing and maintaining Participant Credentials. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Issuance:** Creates Verifiable Credentials confirming about organisations such as that the organisation is an iSHARE-adhering participant, member of a certain dataspace, has signed agreements or is using an X509 certificate. * **Credential Type:** *Participant Credential and Participant Claim Credentials, Bitstring Status List Credential* * **Presentation Use:** Other roles (Service Consumers, Service Providers, Authorisation Registries, etc.) must present these credentials when interacting with a participant. ### Authorisation Registry The Authorisation Registry issues Data Rights Credentials on behalf of an Entitled Party, that express delegation or authorisation rights. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Issuance:** Issues Verifiable Credentials on behalf of Entitled Parties, allowing Service Consumers to prove their right to access specific services or datasets. * **Credential Type:** *Data Rights Credential, Bitstring Status List Credential* * **Presentation Use:** Service Consumers present this credential to Service Providers when requesting access to data. The Authorisation Registry must also verify Participant Credentials during registration or token issuance. ### Identity Provider The Identity Provider issues Identity Credentials to human participants to act on behalf of an organisation. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Issuance:** Generates Verifiable Credentials that confirm a natural person can act on behalf of their organisation and may integrate with eIDAS 2.0 or European Digital Identity Wallets. * **Credential Type:** *Identity Credential, Bitstring Status List Credential* * **Presentation Use:** Used primarily in Human-to-Machine (H2M) interactions for authenticating users in service portals or operational dashboards. ### Entitled Party The Entitled Party manages delegation and may trigger the issuance of Data Rights Credentials through the Authorisation Registry. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Issuance:** Requests or authorises the Authorisation Registry to issue Data Rights Credentials to specific Service Consumers. * **Credential Type:** *Data Rights Credential* (via Authorisation Registry)*, Bitstring Status List Credential* * **Presentation Use:** Presents Participant Credentials to other roles during data sharing transaction to authenticate identity. ### Service Provider The Service Provider verifies the credentials presented by others and may present its own credentials for trust establishment. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Verification:** Must be able to validate Participant Credentials, Data Rights Credentials, and Identity Credentials presented by human or machine Service Consumers and must be able to validate revocation against the Bitstring Status List. * **Credential Types:** *Participant Credential*, *Data Rights Credential*, *Identity Credential, Bitstring Status List Credential* * **Presentation:** May present its own Participant Credential when onboarding with registries or providing evidence of adherence. ### Service Consumer The Service Consumer acts as a presenter of credentials when accessing data or services. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Credential Types:** *Participant Credential*, *Data Rights Credential, Identity Credential(H2M), Bitstring Status List Credential* * **Presentation:** Presents its Participant Credential and any relevant Data Rights Credential and Identity Credential(H2M) when interacting with a Service Provider. * **Verification:** Must be able to validate Participant Credentials presented by other participants during a data sharing transaction ### Identity Broker The Broker facilitates the interaction between participants and Identity Providers and doesn't directly issue or present any specific credential. * **Holding:** Must manage its credentials through a Credential Store (wallet). * **Verification:** Must validate Participant Credentials from participants connecting to the Identity Provider through it. * **Credential Types:** *Participant Credential, Bitstring Status List Credential* ### Impact Table
RoleParticipant CredentialData Rights CredentialIdentity Credential (only H2M)Bitstring Status List Credential
Participant RegistryVerify/Present/Issue——Issue/Verify/Present*
Authorisation RegistryVerify/PresentIssue (on behalf of EP)—Issue/Verify/Present*
Identity ProviderVerify/Present—IssueVerify/Present*
Entitled PartyVerify/PresentIssue (through AR)—Verify/Present*
Service ProviderVerify/PresentVerifyVerifyVerify/Present*
Service ConsumerVerify/PresentPresentPresentVerify/Present*
Identity BrokerVerify/Present——Issue/Verify/Present*
\* Depending on implementation: the Bitstring Status List Credential may be published by the issuer on a public URL, or shared via issue/presentation via a holder. ### Implementation Notes * All issued credentials must conform to schemas published at [schemas.ishare.eu](https://schemas.ishare.eu). * Verification processes must confirm credential signature validity, issuer trust status, and expiration timestamps. * Roles acting as issuers or verifiers must support the DCP, OID4VCI and OID4VP protocols for issuance and presentation. # Access token (M2M) {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ## Obtains access token > Used to obtain an OAuth access token from a Participant Registry, Authorization Registry or Service Provider. The access token must be added under "Authorization" header attribute for secured endpoints. Refer to relevant endpoints on proper usage. ```json {"openapi":"3.0.0","info":{"title":"iSHARE API specifications","version":"3.0"},"tags":[{"name":"Participant Registry (Required)","description":"Required endpoints for the iSHARE Participant Registry API."},{"name":"Service Provider (Required)","description":"Required endpoints for the iSHARE Service Provider API."},{"name":"Authorisation Registry (Required)","description":"Required endpoints for the iSHARE Authorisation Registry API."}],"servers":[{"description":"iSHARE UAT network base domain","url":"https://isharetest.net"},{"description":"iSHARE TEST network base domain","url":"https://test.ishareworks.nl"}],"paths":{"/[v3.0]/connect/token":{"post":{"requestBody":{"content":{"application/x-www-form-urlencoded":{"schema":{"required":["grant_type","scope","client_id","client_assertion_type","client_assertion"],"type":"object","properties":{"grant_type":{"description":"OAuth 2.0 grant type. MUST contain “client_credentials”","type":"string"},"scope":{"description":"OAuth 2.0 scope. MUST contain iSHARE scope value. Other values allow the Service Consumer to get tokens that do not include all rights the Service Consumer has. According to RFC 6749, scopes are case-sensitive.","type":"string"},"client_id":{"description":"Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain a valid party identifier of the Service Consumer","type":"string"},"client_assertion_type":{"description":"Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain “urn:ietf:params:oauth:client-assertion-type:jwt-bearer”","type":"string"},"client_assertion":{"description":"Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain JWT token conform iSHARE specifications, signed by the client.","type":"string"}}}}},"required":true},"tags":["Participant Registry (Required)","Authorisation Registry (Required)","Service Provider (Required)"],"responses":{"200":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/connectTokenResponse"}}},"description":"OK"},"400":{"description":"bad request or request is malformed"}},"deprecated":false,"operationId":"request-oauth-token","summary":"Obtains access token","description":"Used to obtain an OAuth access token from a Participant Registry, Authorization Registry or Service Provider. The access token must be added under \"Authorization\" header attribute for secured endpoints. Refer to relevant endpoints on proper usage."}}},"components":{"schemas":{"connectTokenResponse":{"title":"ConnectTokenResponse","type":"object","properties":{"access_token":{"type":"string","format":"application/jwt"},"token_type":{"type":"string"},"expires_in":{"type":"number"}}}}}} ``` The format of `access_token` is not defined by this specification. They are left to the server and should be opaque to the Service Consumer. {% hint style="info" %} According to [RFC 6749](https://tools.ietf.org/html/rfc6749), scopes are case-sensitive. {% endhint %} # Capabilities {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The `/capabilities` An endpoint is required for every participant that provides services: * Participant Registry * Authorisation Registry * Service Provider * Identity Provider Other roles may provide capabilities endpoint to point the services that are offered by service providers on their behalf. The endpoint returns the iSHARE capabilities of the iSHARE party. The server response is an iSHARE signed JSON Web Token. Depending on whether or not an Access Token is provided to the capabilities endpoint, the endpoint must return public or public and restricted endpoints. in detail: * If an access token IS NOT provided * Return public endpoints, including the Access Token endpoint * If an access token IS provided * Return public endpoints, including the Access Token endpoint * Return restricted endpoints Any endpoints that do not support the iSHARE's Identification, Authentication, and Authorisation (IAA) methods and are not intended for use by iSHARE roles should not be included in the capabilities endpoint response. This is because when a participant sees an endpoint in the capabilities response, they will assume it is iSHARE-compliant and supports iSHARE’s IAA mechanisms. However, if a party has other endpoints that rely on different authorisation methods and are not aligned with iSHARE, those should be excluded from the response to prevent misunderstandings. ### Response Model The model of the `capabilitiesToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=2.2#/jwt_payload_capabilities_token). For convenience, the model of the parties\_info object, contained within the token, is described below: **Decoded capabilitiesToken parameters:** It contains [iSHARE-compliant JWT claims](/reference/ishare-jwt); however, if an access token is not provided, then `aud` The claim should be omitted while signing JWT. In addition to that, it also contains the following parameters: * `capabilities_info`\ **Object**. Root level. (Required)\ Contains information about capabilities. * `publicServices`\ **An array of objects**. Contained in `capabilities_info`. (Required)\ When no Authorisation header is presented when invoking the /capabilities endpoint, only public\_services are returned. Public services themselves may (and usually will) require authentication to invoke them. * `identifier`\ **String**. Contained in `publicServices`. (Required)\ Unique identifier of the service. For iSHARE-defined services, it must contain the predefined identifier (defined as operationId in the iSHARE generic OpenAPI specification). For other services, it might, for instance, refer to operationId in OpenAPI specifications, or other forms of identifiers in other specification formats. * `title`\ **String**. Contained in `publicServices`. (Required)\ Human-readable name of the service. * `description`\ **String**. Contained in `publicServices`.\ Description of the service. * `endpointDescription`\ **String**. Contained in `publicServices`.\ URL that describes the service endpoint. Could be, for instance, a URL to an OpenAPI description, a WSDL document, a SPARQL Service Description, etc. * `endpointURL`\ **String**. Contained in `publicServices`. (Required)\ URL of the endpoint, including the correct host. Depending on the setup, this information could also already be included in the description that is provided via the `endpointDescription`. * `tokenEndpoint`\ **String**. Contained in `publicServices`.\ URL where the access token for the feature can be retrieved. This is optional because if the feature is an access token, it is not needed to mention it twice. * `status`\ **String**. Contained in `publicServices`. (Required)\ Provides information on the status of the service. Must be either "deprecated" or "active". * `serviceType`\ **String**. Contained in `publicServices`. (Required)\ Can be either "framework-defined", "dataspace-defined" or "self-defined". A framework-defined service is required from a framework perspective (including, for instance, the /capabilities endpoint), a dataspace-defined service is required from a dataspace perspective, and a self-defined service is defined by the provider of the service (actual data services are part of this category). * `version`\ **Object**. Contained in `publicServices`. (Required)\ Versioning information of the provided service. * `compliesWithFrameworkVersions`\ **An array of strings**. Contained in `version`.\ An array of framework versions that the service complies with, at a framework level. If not included, the service is assumed to be compliant with the latest version. The versions can be retrieved using the [/versions endpoint](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/ishare-satellite-role/versions.md). Required for framework-defined services. * `compliesWithDataspaceVersions`\ **An array of strings**. Contained in `version`.\ An array of dataspace versions that the service complies with, at a dataspace level. * `capabilityVersion`\ **An array of strings**. Contained in `version`. (Required)\ Version of the provided service. The version numbering of services is not related to the version numbering of the framework or of a dataspace. * `methods`\ **An array of strings**. Contained in `publicServices`.\ An array of operations supported by the endpoint. It could be HTTP methods when the endpoint is HTTP-based, for example: GET, POST, etc. * `authRegistry`\ **Object**. Contained in `publicServices`.\ Optional object which contains details about the Authorisation Register that must be used for this service. * `partyId`\ **String**. Contained in `authRegistry`. (Required)\ Party Identifier of the Authorisation Registry provider that must be used for this service. * `url`\ **String**. Contained in `authRegistry`. (Required)\ The URL pointer specific to the party where authorisations can be queried/checked from. * restrictedServices\ **An array of objects**. Contained in `capabilities_info`.\ When an Authorisation header is presented when invoking the /capabilities endpoint, in addition to the public services, restricted services may be returned, based on the information provided on the participant by the Authorisation header. This could, for example, be implemented to expose services only to participants of a dataspaces. restrictedServices themselves may (and usually will) require authentication to invoke them. *The attributes of restrictedServices are 100% equal to the attributes of publicServices and therefore omitted here.* ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /capabilities ``` ### Example response The response contains an encoded JWT, which looks like this: ```json { "capabilitiesToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHakRDQ0JIU2dBd0lCQWdJVVhsZHlZL0o3MFVGTFNmY2ljeUFnbkNBYkxhVXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNek1URmFGdzB5TnpFeE1EWXhORE16TVRCYU1Hb3hDekFKQmdOVkJBWVRBazVNTVNBd0hnWURWUVFLREJkVVpYTjBJRk5sY25acFkyVWdVSEp2ZG1sa1pYSWdRVEVnTUI0R0ExVUVBd3dYVkdWemRDQlRaWEoyYVdObElGQnliM1pwWkdWeUlFRXhGekFWQmdOVkJHRU1EazVVVWs1TUxURXdNREF3TURBek1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBOW9uQ1F4UDcyRXkyMlIzZ0dNRjgvcy81ODErVGNrZEJ5RHFmZ29ZTEJRbFQwSkt4QXpXandETkZNeUN2TDE4c0w1WE9vVm9qU1dJSkRFZmtBanUwdFdjcGthZkV5Q1U5OVNWVG9Gdzhkd08zSEUyYlFNZ3JUUmNUQ2NjeFVoMnBOMzlMb0FmT3FLUngrcHRkTDJzUWo5T0RZaXNkUWFqb01GTmlONjdGVmFBTVpWT3hDUXdydy82eGdjUnVzaEZlT0UzZHNKOVVVKyt2TU9OdThWNzdXS2lKaXVEQlFQdlJ5ejBibjVvblRXQXBlM0lhSDdMWG9YcnhKL2xBcGxCL0R3OGtCTHV2eUpta2hwZWxrRjJUb3ZxaERYNTVqNEtTWU8rU09md0tXbmVrdEZnQWVURjJrM0NrcloyY2Y5UU9EY1FpVnowL0NxWGNrTEpoTlAxVkJ3SURBUUFCbzRJQ05UQ0NBakV3RGdZRFZSMFBBUUgvQkFRREFnWkFNQXdHQTFVZEV3RUIvd1FDTUFBd0h3WURWUjBqQkJnd0ZvQVVzeHBQUWtEcDJIaWRhLy84SkxBUXNUUTg4SWt3VndZSUt3WUJCUVVIQVFFRVN6QkpNRWNHQ0NzR0FRVUZCekFCaGp0b2RIUndjem92TDJOaE55NXBjMmhoY21WMFpYTjBMbTVsZERvNE5EUXlMMlZxWW1OaEwzQjFZbXhwWTNkbFlpOXpkR0YwZFhNdmIyTnpjREFRQmdOVkhTQUVDVEFITUFVR0ExVWRJREFmQmdOVkhTVUVHREFXQmdnckJnRUZCUWNEQkFZS0t3WUJCQUdDTndvREREQmJCZ2dyQmdFRkJRY0JBd1JQTUUwd0V3WUdCQUNPUmdFR01Ba0dCd1FBamtZQkJnSXdOZ1lJS3dZQkJRVUhBUU1NS2xSb2FYTWdhWE1nZEdWemRDQmxjMlZoYkNCalpYSjBhV1pwWTJGMFpTQm1iM0lnZEdWemRHbHVaekFlQmdWbmdRd0RBUVFWTUJNVEEwNVVVaE1DVGt3TUNERXdNREF3TURBek1JSEhCZ05WSFI4RWdiOHdnYnd3Z2JtZ2diYWdnYk9HZ2JCb2RIUndjem92TDJOaE55NXBjMmhoY21WMFpYTjBMbTVsZERvNE5EUXlMMlZxWW1OaEwzQjFZbXhwWTNkbFlpOTNaV0prYVhOMEwyTmxjblJrYVhOMFAyTnRaRDFqY213bWFYTnpkV1Z5UFVOT0pUTkVaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwSlRKRGIzSm5ZVzVwZW1GMGFXOXVTV1JsYm5ScFptbGxjaVV6UkU1VVVrNU1MV2xUU0VGU1JWUkZVMVFsTWtOUEpUTkVhVk5JUVZKRlZHVnpkQ1V5UTBNbE0wUllXREFkQmdOVkhRNEVGZ1FVZkkvNkZzVzFZT0RRTWtnbEhXZWZITWFXRjhFd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dJQkFHMnc0ZGdjTkRhL0ltVTZQK09yUEFaYWp5M0c3aCs2ejRpUFJCV1hnc0RjbDVVTHBOVXpTSUljZ2dHb05rYUNJU294KzFyV0ZwM3BOUWx4c1lkYjhFcjFYRFBvOG9WRjU4M241VU95UFVpTENnUU5GV0ZxaUg3NnpkeEk5c2Fua0l5TVMrZytuSHZxRlR1Y1pqbkVnbU5MWjZhNDVxQ2ZYRXRtRnkxUVJRMU4wcWZ3d2VEVEpWYjNCb054RU84UjdlQWg0cTBOaFNxWGJrb3JQUUxlamsyWG5NYm5NOHRqc1V1cmpwQ3M4VU1nMFR6UlROdXlHLzd0VmFMcmRFbnBxUDIwK2drNXE1d2FFRndwRDZlT3ZxbFVnSDByRkxrMlZQOEhidG4xM0dhQlpCa3FBUzJrbmJxZFZ2VEZpclR6RldNMGRRTmk5NzdBbDRsVmJYTGNBSEVaNWpTazRWYnFyYkFGQm9wS0tNUFNWL0NzeStwMksvc25mVjNRcXhhRnhUdjloTUFuVG1rUTFudTNuU1BwQXE5OUI1cURuQXdxaHlqaHFNdEpIbEd5cWQyeUl1aHFrMmVjeVl3cThSRGpLTkFqZE1MRzVLWERLckdraW9WcnFLdDNBa2F2dk5HV0J0NlFiVnNoNFJZWWI4SVc4L2RCWU9jOVhWV2xNS1RKdHc0dUVvQW1xVTNMV3E4OXJSOW5jcmwwMWlUbDJjaWlKamZRN21sNTIyUXZHUmwxbGtUZnJ6K2Y2VnJQOEVPKzkrTWVtck96eFFJbjNqUms2TlFydlNGanlKWDNZTUV6YVlIL2NBMld2Mm16V0ZjOWJUa25lYjdXa3ZWeFcxOFhxaGpjc25qdDk2N2Rlamk5eDExTExZOE5Cd1I3S3J6Si9kSmRNTHFucHlLWSIsIk1JSUYyakNDQThLZ0F3SUJBZ0lVUEczK1RBbnhWT0JjZTlOYVB0OXBUQWdtNVI0d0RRWUpLb1pJaHZjTkFRRUxCUUF3UWpFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlUZFdKRFFVY3pNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQWVGdzB5TXpBNE1qVXdPVEF4TXpKYUZ3MDBPREE0TWpVd09UQXdNRFZhTUYweEhqQWNCZ05WQkFNTUZXVkpSRUZUWlZORlFVeFBTVVJmU1hOelEwRkhOREVaTUJjR0ExVUVZUk1RVGxSU1Rrd3RhVk5JUVZKRlZFVlRWREVUTUJFR0ExVUVDaE1LYVZOSVFWSkZWR1Z6ZERFTE1Ba0dBMVVFQmhNQ1dGZ3dnZ0lpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElDRHdBd2dnSUtBb0lDQVFEYW5VZ00xL1BReVhOVFgrVU9MR3JaalM4SGFUV1IvUDR4RDhTTUNSeE9YSEt6SExRcUVRT3VIRC93K3J4OS9iRXd6SDR3VmZKMG02L3I1NktPZzB3TFVsVndPeWlrT1hHb0lURDJ1K1VpOXQyNHRZSWt4OHpqTEc3VkhWY3c0ZFhPdDkyc3ZLWTFMeWJ2bHByb1d6VEhsUndvSU8xWVE0aE8rcnlic3cvS0VERVhVYmtvd2psSEFQY3duc09XNjQzNjdFTitlelQxc1M4ZHpGSXhtRzhxQzJMck0yc1hKV3FxNXZKZUUvODZUZloyTk1PK0NVeGtqajd1UGdiVzJWL01PVWhZeUF0R0FqemQvS3dPckxNUk1ZYVhPSWo2MW04UjcxbmgvTFY5bjhkbmowd1RRT05USGh1TTdtZFpReGhxT2RrTDJja1NyQldpM2F0RVZUMU9oQlJYNEZtbWhJaG1TV3VDdGd5S2lEQ0lvdHlHQXNYMm82ODE3ZmVlNFJkdHdmdzlRNG9OM05BaHRvZDYwaU9BV0FwVnQrQlQ1dHZkZ0dPWVdQY2JNUjVwR3picDM4ZEdVeXV3WVpWNExBbklHU201eWF1Y05FMkUyeHJRQ2JFZVptNFJQc3g1SmxlV3ppcGsrNDJkN3ZxdldEODhJUWNRK2JaTTJYNHJKQlpOczE2NkNseCttNkhtS3hLQUxlYlV0anN6c2d5SDhjcTEwZCtrNEFvOG9DYU9ZanYySWFFYk1kK2ZWL1VmOGtQa3pUdEtsdHRkcWlpeG9JcXljWE1FZ0JhU2drdWI3WG9RNksyNnRSUEowdzVRa3V1aDNNS3RHRVdmVzdFRUdtcG5DcWpPdjYvckFNSmlNV3loMUlnTGdOQlVQUDd6YVZQcERBdEM4OE9TSlFJREFRQUJvNEdzTUlHcE1CSUdBMVVkRXdFQi93UUlNQVlCQWY4Q0FRRXdId1lEVlIwakJCZ3dGb0FVNHViWDBwNkRWak45REt0T1dXTVlBcytIeGRRd0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBcEJnTlZIU1VFSWpBZ0JnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3SFFZRFZSME9CQllFRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1BNEdBMVVkRHdFQi93UUVBd0lCQmpBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQWdFQVp2NUd1a3gwUEV2VlJFSXQ4TVRhUGZDSDRhd3lpaVl5aTE3aDZSNUxMazFyZXJ3UXNTU1NIZlZxZnRkd1JGMG9jTHAyUFhKaGUwNzVxVjQwNkMwNENqYW1OazNlejlaaU5IQ05qUHRmaWQ2b094cXoxWGs4WFBqTllFbGJBRm1QN2VLbC80NDF2WmhHdWsvUmhYR054UWJ0bzBRMTZnOElSY0dEdldnTmh0cnRCMUcyeFNtdEIxUzJ1VXBTYWlaVk5PcmtkelRoaUVKc2VVUkJvWHhVWElxcEx5UFRSbDZNTWdWYUxHUllSYzN2WWlqNEI3TTJoQk43L2NqbkdMc01WdGdiT3Y2Q1YyMWcyU1hvd2JnT3F6QnlINTFVVFI2T2JIaUdqMGtTQ0FMRzE0SVFQa3pRUGlTcGp1Kys5TTJqQWpQTTNvNDIxWk9VRE1QMjQ2Q3NxUFhyVEFiUFhKVlVSL2dpNHU1M2ttekMyMTBqdlZxOWhId2VseFFPVFBGaGxNNkUxQ2g0SmI0UFFSTEtEUEZsKzVOVzRGeTJKQURqeXVweVZIbmNkTEV1UHkwUGdDTDJZbzE0N0hTcFBqNHU3amMxUm1IVTdOTzEyRVYyWkNNZkZsUndkR3Y2aWY4cU83cy82bHBaSmpwUHRMRU9iQTV0RDRhaGMrYVBOQWk5V0NrMHBlUm0xS0U1VkdEV0tGTlNOQWlMSk56UDdtMlE2eThmT3kzOGNOZ0ZCaEdPRi9LZ0VJc1QxMFYrNUs1byt5bFZWdFBWZVJSRU5FdktPOUVMa3plMElIZ3NUQi82Y3dPaWo0cHhNOUp2YXVqMDZHZ2xoSWhpSUE2cTBpRFVxQjFNVVIwSHppWTlCc25XWTlrUjhod1YzT1crbnNtenRRd0dWRXcya2pVPSIsIk1JSUZqakNDQTNhZ0F3SUJBZ0lVRmo5LzNqR09SaHRJcFo5OE9MUnRSSHMwQVlzd0RRWUpLb1pJaHZjTkFRRUxCUUF3UVRFZE1Cc0dBMVVFQXd3VVpVbEVRVk5sVTBWQlRFOUpSRjlTYjI5MFJ6SXhFekFSQmdOVkJBb1RDbWxUU0VGU1JWUmxjM1F4Q3pBSkJnTlZCQVlUQWxoWU1CNFhEVEl6TURneU5UQTVNREEwTkZvWERUUTRNRGd5TlRBNU1EQXdOVm93UWpFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlUZFdKRFFVY3pNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQ0NBaUl3RFFZSktvWklodmNOQVFFQkJRQURnZ0lQQURDQ0Fnb0NnZ0lCQUw3bnpreW9GWFdnMWdoZEc2Zm51enV2QWRNV3NtL0krbVgzRGJ6M0kvS3lxTGRXdDdYRzNPV1ZTbmhvc0FEMlcyU1hubEdYcXh5ZTBoUHRFZ2tRSWRlbDdGbkZvc1dXcnNFT3JhdGdYbG5NNE5XcFlES01XRVZZcm83aHpIZ0NaMTI2WlBRVUxsczUyTmN2cFJNOFMzZFprK1hLMWtmM1ZlUzBKMmhVU0ZFQVpITHlYQ1hraFRuVUk3cW8xdXIxVG1EV1lzTlF3eERHT3U3Q1F5WllkS0l3S3FJOWVHc1JMZ002UFFsZzN2WkNyb3BPb2RNN2xvVHVpckNsM1VLdzRIckdrMmNPaUFmNElkLy9lYVZDYWZ3a2pLc0pUUXVBYWh1Uno0cU1zSFlBM2tEUXorMCtoZ25SNzRyK2lMcis4bHIwNDRnbG5hV0lXdnJFR2NpUlIrUGVjdGZyTE9RUUlXN2hhMTNkeldvemtUMGFnblQxTGsvQ0dyZ05YVnFob3NHQzBydUFRUEk2RGNQTnkySU5NOUpndENtQnNTak1NMTg1RklCWDRDeTE3bTczaDlyS2pYWk14YjZUeFg3Q0laeWVzZ0FTMGJCUmI2eElwS3NacmxyakVhenNqQzJWSFJSV09NSldZcWNYTEQ1Wk56R01aVXI2VHQyeUNVQXRhbWVjREFUS042L0dic3hlMHRBQk4wcGswcng1aWMrNFRYZEJyb045T0FaY2hINHRKQ3NPQ0tvbkN6QXBQeFZUaEROTXhzb295RnE5RG1nWGh5RVVPT29lUytGcjRGZ0gralNBTm0vbDE3OEpoOWVwZlhROWdFLzZhcVB4WWpOU0JnUzYwUzFFVnFDcHh3MnJUMW1VWWVHZndpYlZtNTNpeEdwdFI4a3RlNzBuQWdNQkFBR2pmVEI3TUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SHdZRFZSMGpCQmd3Rm9BVTJMdWJOUzFiUCsvaGE4dk1ETStpTHJwcGVvd3dHQVlEVlIwZ0JCRXdEekFGQmdOVkhTQXdCZ1lFVlIwZ0FEQWRCZ05WSFE0RUZnUVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3RGdZRFZSMFBBUUgvQkFRREFnRUdNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUI4anFZVXc3VHYrVzRaSDA2UHJhRjZ6ZmRDeFQwM0RoUkNodzRaL1FtMFhWUzJnUnlSd2NNcHRRRkVSaFBOT0EyMjF1OUxxb3paMWFLM0IzNXdrY0dEL2RGSmdKQ0pCOTZTTXR0UWwySHAvRWlRejlQRkYwMmRCU3J1WGhJYXJhUGJNK05JR2RteU4yWnl3R0dYSTFhVTdKRDNYRzI5U2gyQUFkT2t2OGRJNmdFZ3p0L0RIU0lJYmFrYmFMZEVJYzdXQjk1R1VIY0huTmo1OFR6VFN5VmZCbXRiM3ZCSzlKRzBJbzZOQVBXUVl4MlZQOCtmSXlsamEyZDEyOGhnaDBkc0RyWEZBTSs5QVg4aGFlNXZ2eFZpOFRXcy96MmluZytrK2ltbXRTTmZ6ektNaU83cjV3SkFreWp3dFVCbEJTdEtJQTZaZXIyMnBtU1RaWmV1Y0hkRVRoYWJjV1FpZFZabU1QM0lmNml4NVVleVg4VjZPQXcwZ3NJM0lVYjkxUTc2ZDRzTFdiem9HTk9OQVlGQzFJeXoweFdqNDdaZDZQN1oyR2ZoMVZpSWJNeFZpRkRsTm1iRVpmbHBFUzg3Sy95aEJVUS90bkNOR1FvU2R0c3V5dVdnM05mV2J5Sm9OWnpsVTk2Sld4Y3FTYVhrenNlOWo4d2FoYXlLTk02U1dLU1kxWjA1aDhKU2NPQ21GQjVGOFYzYmQ1blAvdUtqYTdIOE80R09BQVBNM090RytlcTM3eFcveE4wb0FzamJ2dDRvam5VYkpzMmtpQXhFZHdYeDBLN21jUGVTN3pXbVZ0OGg0UmRjRG0vUEdURGE5bThPcWhRdWNrODBRbnV4SVVXVnI3R1dhZGgxTHkvdGwwK2J2bWtjbk8yeWJSSitnYnFSRUhEVGUwc3hzdz09IiwiTUlJRmN6Q0NBMXVnQXdJQkFnSVVDdmZTdlFlcmpGRG1NMkx2bWpvVERPSW5MQXd3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQXdObG9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUlJQ0lqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FnOEFNSUlDQ2dLQ0FnRUF4Vk1LSTlSTWhuT1NBMkxvcmdFQzNZRE5kMml0bjcyTE9kZlJSVXU0NWZHNzBJZXYrRTRrUnJ6SjFrMjNXWEg1c0hUYmNzbHBFVGVBWm5qMC94S0JZZEVMdXdlNkhYOGtJd2QxczZXR2xaYzBsN2tpMWZtajRIcVNzdEdKL0JLR2oxYTcyMzZXd1BKRVdFSHFmeDlRTUVldUpLbFVTVkZGeUU0ak1zZllwODdpZklwdXdFOG9MT3c0eWtERE9QNTJUZDA2dkhDSVlycURCcnZ4RmRBdUVuRnhOeGxQWFJFNGdMc3lnZzYySE94T3VHbWhXZnN5NlRjY0lwNVhJT2RqMkN6ZW9YSjgybTUvaW1CUEp2a2VmbnJqRVFYemlTRTJtaTJJQkR0R1AvQXdGV0k3V3BzRXlEWFdJbU1TUjBUM0N1RG1rZVExNHBObWNxTXAvYnFYM2kxYWV0YWRGVFdzdWhsMG5IMmlScUtaREp4WmxTY3U5OXRvcTVHcmRjRlVjeEdSUXlsK3NGaFVoM1hjQldKVjdZMnduRkwydFk3dGh0UThaUG16VE84a1BLQ2JFbDVVNmdDU0lrcFJQTlpCUEc0ZFQwcXUrOEJkNzFQdTduQXkxaUI0VTZ5czM0Y0ZsT2xKcEdNMEZHcjM1TGVmYlBSOGJnejZNOVhOalJiZ01EUWNYRE1uZmlESjdFODFvVkJwQ1hOOXlkSGkxYmxoYWt1RUJhb2E5TS9rYXppcEdQbUF1eHJXQk1tcDJxMHd6UXA5R1MyZThrZUpJRHdKdXl6RUxhUlpDNHlqVnNWWlFNSy8vRCs0SjNib1U1ZHJDbW1tNkMxcndOUmZTWnVGR05jSVlEWmVIdGVHb0NGNEVBNWpjZ2RGYUlZckRlajZWQWFiNDJ2TjVMVUNBd0VBQWFOak1HRXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QWZCZ05WSFNNRUdEQVdnQlRZdTVzMUxWcy83K0ZyeTh3TXo2SXV1bWw2akRBZEJnTlZIUTRFRmdRVTJMdWJOUzFiUCsvaGE4dk1ETStpTHJwcGVvd3dEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQmJjSHlWMmI1bUd3SFd4Q1NiRHdyNVY3UGdTWklKYTFzY3JDbklIRDNaL3l4RzdYcDVjSWxCajRNeTRsUkhqWnRKVnZVZlRqRnBzRURFdi9QQXE3NE9Jb2xOL2tQZE1mVGN6RkJHcHZzWnIweDJ5VVBFSnpRc1RTTHgwZ3daK3d2b0tIV0UwQzdHcWdrQUJOckZXOEZMcVJ6TnFYc21NNW9JNGMzVjVzeXh3QllGRFVZNU1QV2RxSkVEZlJ2ampKUENYbUtPUDFsTytpK0UwN3ZzRnBEekhTMkZLQjVjNnNUSVprdnQrSC9DRzRoVnU2WnZjRlhYenYySksvRW9WWjZ3VWRDbHQ0cExnVFFaL1cwcVFDSjNHakZlL1BaNzRtY2tXMXgvems5ejBWUWpVcFRxejNBalBMSWpqNjBuTUxUTHA1MG9GY01ManVYc3MwdnY0dFVqQ1RwczJRZzluMEd3TGxEUjQyTnl3MlRLY01NQjZ5Y0VvTmlVRXUwbGdhMUpNMFNWU3NGUDdHU1UvVzlWcWF0Szd4cC9YVzkvR0R2Z3AzWi9wUE0wRTNpMXRxcC9uT1U0M1lvZjhXaTRKSjZ6T2dYQnpxUXhPNk1JTFpKNHFFZmVuQXRJN285NVR5NXlrOXZSYm9Vc3R5d3NmQzZDVnN1MDhOTC90dHc0T1NYT3Zia1ErN3pNeENZVDlZeVFENWwvbHRDM2JnZGovbEJaem5zQnVHWU5PQjE2d0ROY0dwdXVhZWtzZlFmQkRQSFQrdlI2Z1BWRlpweVZ3eS90ekg2TlRwVUdEam9IVnNDeFVqWTg3ME9NNEQySmNqOU9JcXFkbGtDb1dPNmk0VmVjN3NUenhpWDM5b05TcjFHN0NvYmMzc1lkaG54Zy92bGcxQmVDSjg3cDBBPT0iXX0.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUkxOTC0xMDAwMDAwMyIsInN1YiI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTE5MLTEwMDAwMDAzIiwiYXVkIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJMTkwtMTAwMDAwMDEiLCJqdGkiOiI3MDcxZWNjNTE1NDQ0MTI3OTkwMzYyMmFmMWJlZGJjMCIsImlhdCI6MTU5MTk2NTI3NywiZXhwIjoxNTkxOTY1MzA3LCJjYXBhYmlsaXRpZXNfaW5mbyI6eyJwdWJsaWNTZXJ2aWNlcyI6W3siaWRlbnRpZmllciI6Ii9jYXBhYmlsaXRpZXMiLCJ0aXRsZSI6IkNhcGFiaWxpdGllcyIsImRlc2NyaXB0aW9uIjoiaVNIQVJFIENhcGFiaWxpdGllcyBFbmRwb2ludCIsImRlc2NyaXB0aW9uVVJMIjoiaHR0cHM6Ly9vcGVuYXBpLmlzaGFyZS5ldS9pbmRleC5odG1sP3ZlcnNpb249Mi4yIy9TZXJ2aWNlJTIwUHJvdmlkZXIvJTJGY2FwYWJpbGl0aWVzIiwiZW5kcG9pbnRVUkwiOiJodHRwczovL3Rlc3Qtc2VydmljZS1wcm92aWRlci5pc2hhcmUuZXUvY2FwYWJpbGl0aWVzIiwidG9rZW5FbmRwb2ludCI6Imh0dHBzOi8vdGVzdC1zZXJ2aWNlLXByb3ZpZGVyLmlzaGFyZS5ldS90b2tlbiIsInN0YXR1cyI6ImFjdGl2ZSIsInNlcnZpY2VUeXBlIjoiZnJhbWV3b3JrLWRlZmluZWQiLCJ2ZXJzaW9uIjp7ImNvbXBsaWVzV2l0aEZyYW1ld29ya1ZlcnNpb25zIjpbIjIuMSJdLCJjb21wbGllc1dpdGhEYXRhc3BhY2VWZXJzaW9ucyI6WyIxLjAiXSwiY2FwYWJpbGl0eVZlcnNpb24iOiIxLjUifSwibWV0aG9kcyI6WyJHRVQiLCJQT1NUIl0sImF1dGhSZWdpc3RyeSI6eyJwYXJ0eUlkIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwNCIsInVybCI6Imh0dHBzOi8vYXIuaXNoYXJldGVzdC5uZXQifX1dfX0.jXoJAjczjRrsxZQUR6SS0xYbNpec9VYXwk5msnELa8e2TdDkH6KsHvCIzDB1KkQ-_F85T4EoPlwfWxIjFUQj1jIC8E6JcVUlb9eXKOEjOilpF0imudBtoWmosgCDmZcSy0dW-b-PniVZVibYBp9BynYVS-Ecx-mY6VhvSo_3HmxAagEppTc-TzJIc0uo3ZGW2psr3DsW_Xm8N31MgSf4EA_V6IlCvEoD81SLJZCL6PmMc6Jp4vEO7Ry9WFa_oJjJLcGRmJCso47f_UhHknM5R53CdxSw9ibF8zEWOf9KWBoK7xy9rZJFhf9298HrJuw5AiTX5jBJ8LGP2K1MsgZF5w" } ``` After decoding, the example content of the JWT looks like this: ```json { "iss": "did:ishare:EU.NL.NTRLNL-10000003", "sub": "did:ishare:EU.NL.NTRLNL-10000003", "aud": "did:ishare:EU.NL.NTRLNL-10000001", "jti": "7071ecc5154441279903622af1bedbc0", "iat": 1591965277, "exp": 1591965307, "capabilities_info": { "publicServices": [ { "identifier": "/capabilities", "title": "Capabilities", "description": "iSHARE Capabilities Endpoint", "endpointDescription": "https://openapi.ishare.eu/index.html?version=2.2#/Service%20Provider/%2Fcapabilities", "endpointURL": "https://test-service-provider.ishare.eu/capabilities", "tokenEndpoint": "https://test-service-provider.ishare.eu/token", "status": "active", "serviceType": "framework-defined", "version": { "compliesWithFrameworkVersions": [ "2.1" ], "compliesWithDataspaceVersions": [ "1.0" ], "capabilityVersion": "1.5" }, "methods": [ "GET", "POST" ], "authRegistry": { "partyId": "did:ishare:EU.NL.NTRNL-10000004", "url": "https://ar.isharetest.net" } } ] } } ``` # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} All the endpoints included in the iSHARE Developer Portal are in line with [DCP 1.0](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/). The endpoints are provided for convenience and the examples used in the pages about the endpoints reflect how iSHARE participants may apply verifiable credentials in their dataspace. For each role the endpoints that are required for DCP are listed under a 'DCP Endpoints' section. The following table provides an overview of required endpoints per role.
EndpointAuthorization Registry (holder, issuer, verifier)Entitled Party (holder, verifier)Identity Provider (holder, issuer, verifier)Participant Registry (holder, issuer, verifier)Service Consumer (holder, verifier)Service Provider (holder, verifier)
/pages/X6ApmFm31tHd4Fj3j5RRtruetruetruetruetruetrue
/pages/B4l3ApUhsE5AGQ894DXqtruefalsetruetruefalsefalse
/pages/c5VwjofXs7DxcggloQPJtruefalsetruetruefalsefalse
/pages/1FcdeyWDKgQMED3hikTItruefalsetruetruefalsefalse
/pages/nm9Otstb2iLHR5AfsywXtruetruetruetruetruetrue
/pages/Cd8j8JM4W2sskH8QO4KEtruetruetruetruetruetrue
# Credential storage (DCP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the `/credentials` endpoint with a `CredentialMessage` requests the storage of a credential. All roles (participants) must support this endpoint, since all roles must be able to store credentials. The endpoint would typically be provided by a Wallet provider. {% hint style="info" %} The `POST` request to the `/credentials` is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with the **Decentralised Claims Protocol (DCP)**. {% endhint %} ## Request issuance or storage of a Verifiable Credential > If invoked with a credential-request message, requests the issuance of a Verifiable Credential according to the Eclipse Decentralized Claims Protocol v1.0 specification. This is applicable to issuers only.\ > If invoked with a credential-message, requests the storage of a credential, applicable to all roles (participants), since all roles must be able to store credentials.\ > More information in the \[DCP specification of the credential request API]\() and the \[DCP specification of the storage API]\(). ```json {"openapi":"3.1.0","info":{"title":"iSHARE Decentralized Claims Protocol (DCP) API specifications","version":"3.0"},"tags":[{"name":"Issuer","description":"Endpoints relevant for the VC Issuer role (e.g., issuing credentials, issuer metadata)."},{"name":"Holder","description":"Endpoints relevant for the VC Holder role (e.g., storing credentials, receiving offers)."}],"security":[{"BearerAuth":[]}],"components":{"securitySchemes":{"BearerAuth":{"type":"http","scheme":"bearer","bearerFormat":"JWT","description":"iSHARE JWT Bearer token authentication"}}},"paths":{"/credentials":{"post":{"tags":["Issuer","Holder"],"summary":"Request issuance or storage of a Verifiable Credential","description":"If invoked with a credential-request message, requests the issuance of a Verifiable Credential according to the Eclipse Decentralized Claims Protocol v1.0 specification. This is applicable to issuers only.\nIf invoked with a credential-message, requests the storage of a credential, applicable to all roles (participants), since all roles must be able to store credentials.\nMore information in the [DCP specification of the credential request API](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#credential-request-api) and the [DCP specification of the storage API](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#storage-api).","operationId":"issue-credential","requestBody":{"required":true,"content":{"application/json":{"schema":{"oneOf":[{"$ref":"#/x-ext/1d11beb"},{"$ref":"#/x-ext/30ea372"}]}}}},"responses":{"201":{"description":"Credential (request) created successfully","headers":{"Location":{"description":"URL to the credential request status endpoint (only after credential issuance request)","schema":{"type":"string","format":"uri"}}}},"400":{"description":"Bad Request - Invalid request"},"401":{"description":"Unauthorized - Invalid or missing authentication"},"403":{"description":"Forbidden - Insufficient permissions to issue credential"},"500":{"description":"Internal Server Error"}}}}}} ``` ### Request model The model for the CredentialMessage is defined in: . * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the CredentialRequestMessage type. Must contain `"CredentialMessage"` * `credentials`\ **Array of objects**. Root level.\ An array of Credential Container objects. * `credentialType`\ **String**. Contained in Credential Container object. (Required)\ A single string specifying type of credential. Could contain a reference to a credential type defined in the iSHARE Framework (as Credential Schema). * `payload`\ **String**. Contained in Credential Container object. (Required)\ A [Json Literal](https://www.w3.org/TR/json-ld11/#json-literals) containing a Verifiable Credential defined by VC DataModel version of the selected profile. * `format`\ **String**. Contained in Credential Container object. (Required)\ A JSON string that describes the format of the credential to be issued. Typically contains `"jwt"`. * `issuerPid`\ **String**. Root level. (Required)\ A string corresponding to the issuance id on the Issuer side. * `holderPid`\ **String**. Root level.\ A string corresponding to the request id on the Holder side. * `status`\ **String**. Root level. (Required)\ A string stating whether the request was successful (`ISSUED`) or rejected (`REJECTED`). ### Example request ```json POST /credentials HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "CredentialMessage", "credentials": [ { "credentialType": "FrameworkCompliance", "payload": "", "format": "jwt" }, { "credentialType": "DataspaceMembership", "payload": "", "format": "jwt" } ], "issuerPid": "issuerPid", "holderPid": "holderPid", "status": "ISSUED" } ``` ### Response model After success, a 201 response will be provided. # Credential issuance (DCP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the `/credentials` endpoint with a `CredentialRequestMessage` requests the issuance of a credential. {% hint style="info" %} The `POST` request to the `/credentials` is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with the **Decentralised Claims Protocol (DCP)**. {% endhint %} ## Request issuance or storage of a Verifiable Credential > If invoked with a credential-request message, requests the issuance of a Verifiable Credential according to the Eclipse Decentralized Claims Protocol v1.0 specification. This is applicable to issuers only.\ > If invoked with a credential-message, requests the storage of a credential, applicable to all roles (participants), since all roles must be able to store credentials.\ > More information in the \[DCP specification of the credential request API]\() and the \[DCP specification of the storage API]\(). ```json {"openapi":"3.1.0","info":{"title":"iSHARE Decentralized Claims Protocol (DCP) API specifications","version":"3.0"},"tags":[{"name":"Issuer","description":"Endpoints relevant for the VC Issuer role (e.g., issuing credentials, issuer metadata)."},{"name":"Holder","description":"Endpoints relevant for the VC Holder role (e.g., storing credentials, receiving offers)."}],"security":[{"BearerAuth":[]}],"components":{"securitySchemes":{"BearerAuth":{"type":"http","scheme":"bearer","bearerFormat":"JWT","description":"iSHARE JWT Bearer token authentication"}}},"paths":{"/credentials":{"post":{"tags":["Issuer","Holder"],"summary":"Request issuance or storage of a Verifiable Credential","description":"If invoked with a credential-request message, requests the issuance of a Verifiable Credential according to the Eclipse Decentralized Claims Protocol v1.0 specification. This is applicable to issuers only.\nIf invoked with a credential-message, requests the storage of a credential, applicable to all roles (participants), since all roles must be able to store credentials.\nMore information in the [DCP specification of the credential request API](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#credential-request-api) and the [DCP specification of the storage API](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#storage-api).","operationId":"issue-credential","requestBody":{"required":true,"content":{"application/json":{"schema":{"oneOf":[{"$ref":"#/x-ext/1d11beb"},{"$ref":"#/x-ext/30ea372"}]}}}},"responses":{"201":{"description":"Credential (request) created successfully","headers":{"Location":{"description":"URL to the credential request status endpoint (only after credential issuance request)","schema":{"type":"string","format":"uri"}}}},"400":{"description":"Bad Request - Invalid request"},"401":{"description":"Unauthorized - Invalid or missing authentication"},"403":{"description":"Forbidden - Insufficient permissions to issue credential"},"500":{"description":"Internal Server Error"}}}}}} ``` ### Request model The model for the CredentialRequestMessage is defined in: . * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the CredentialRequestMessage type. Must contain `"CredentialRequestMessage"` * `holderPid`\ **String**. Root level. (Required)\ A string corresponding to the request id on the Holder side. * `credentials`\ **Array of objects**. Root level. (Required)\ An array of objects with an id property, each referencing a CredentialObject. * `id`\ **String**. Contained in credential object. (Required)\ ID referencing an id value of an object in the credentialsSupported returned from the Issuer Metadata endpoint. ### Example request ```json POST /credentials HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "CredentialRequestMessage", "holderPid": "holderPid", "credentials": [ { "id": "d5c77b0e-7f4e-4fd5-8c5f-28b5fc3f96d1" }, { "id": "c0f81e68-6d35-4f9d-bc04-51e511b2e46c" } ] } ``` ### Response model After success, a 201 response will be provided. The response contains a header "Location" that contains a URL pointing to the status of the request. This URL or the ID in the URL must be stored by the issuance requestor to request the [status of credential issuance](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-status-dcp) in a later stage. # Credential status (DCP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `GET` request to the `/requests/{requestId}` endpoint requests the status of a credential issuance process. {% hint style="info" %} The `GET` request to the `/requests/{requestId}` is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with the **Decentralised Claims Protocol (DCP)**. {% endhint %} ## Get credential request status > Retrieves the status of a credential request. This endpoint is used to check the processing status of a previously submitted credential request. The request ID is provided in the Location header of the 201 response from the /credentials endpoint. More information in the \[DCP specification]\(). ```json {"openapi":"3.1.0","info":{"title":"iSHARE Decentralized Claims Protocol (DCP) API specifications","version":"3.0"},"tags":[{"name":"Issuer","description":"Endpoints relevant for the VC Issuer role (e.g., issuing credentials, issuer metadata)."}],"security":[{"BearerAuth":[]}],"components":{"securitySchemes":{"BearerAuth":{"type":"http","scheme":"bearer","bearerFormat":"JWT","description":"iSHARE JWT Bearer token authentication"}}},"paths":{"/requests/{requestId}":{"get":{"tags":["Issuer"],"summary":"Get credential request status","description":"Retrieves the status of a credential request. This endpoint is used to check the processing status of a previously submitted credential request. The request ID is provided in the Location header of the 201 response from the /credentials endpoint. More information in the [DCP specification](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#credential-request-status-api).","operationId":"get-credential-request-status","parameters":[{"name":"requestId","in":"path","required":true,"description":"Unique identifier of the credential request","schema":{"type":"string","format":"uri"}}],"responses":{"200":{"description":"Credential request status retrieved successfully","content":{"application/json":{"schema":{"$ref":"#/x-ext/e780916"}}}},"401":{"description":"Unauthorized - Invalid or missing authentication"},"404":{"description":"Credential request not found"},"500":{"description":"Internal Server Error"}}}}}} ``` ### Request model The request contains a {requestId} parameter in the URL. This {requestId} corresponds to the ID identified by the location header returned after a [Credential Issuance message](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-issuance-dcp). ### Example request ```json GET /credentials/3cc1e9be-99d0-43fc-bb48-1f60837163bd HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN ``` ### Response model The model for the CredentialStatus is defined in: . * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the CredentialStatus type. Must contain `"CredentialStatus"` * `issuerPid`\ **String**. Root level. (Required)\ A string corresponding to the issuance id on the Issuer side. * `holderPid`\ **String**. Root level. (Required)\ A string corresponding to the request id on the Holder side. * `status`\ **String**. Root level. (Required)\ A string with a value of `RECEIVED`, `REJECTED`, or `ISSUED`. ### Example response ```json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "CredentialStatus", "issuerPid": "issuerPid", "holderPid": "holderPid", "status": "RECEIVED" } ``` # Metadata (DCP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `GET` request to the `/metadata` endpoint requests an overview of supported credential types by the issuer. The credential types that are defined by the iSHARE Framework are defined on the [iSHARE Schemas Site](https://schemas.ishare.eu/v3/). An iSHARE Participant Registry must, at a minimum, issue a [Participant Credential](https://schemas.ishare.eu/v3/party/schema.json). An iSHARE Authorisation Registry must, at a minimum, issue a [Data Rights Credential](https://schemas.ishare.eu/v3/party/schema.json). {% hint style="info" %} The `GET` request to the `/metadata` is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with the **Decentralised Claims Protocol (DCP)**. {% endhint %} ## Gets credential types supported by the issuer > Retrieves a list of supported credential types that the issuer can provide. More information in the \[DCP specification]\( > The credential types that are defined by the iSHARE Framework are defined on the \[iSHARE Schemas Site]\( > An iSHARE Participant Registry must at minimum issue a \[Participant Credential]\(). An iSHARE Authorization Registry must at minimum issue a \[Data Rights Credential]\(). ```json {"openapi":"3.1.0","info":{"title":"iSHARE Decentralized Claims Protocol (DCP) API specifications","version":"3.0"},"tags":[{"name":"Issuer","description":"Endpoints relevant for the VC Issuer role (e.g., issuing credentials, issuer metadata)."}],"security":[{"BearerAuth":[]}],"components":{"securitySchemes":{"BearerAuth":{"type":"http","scheme":"bearer","bearerFormat":"JWT","description":"iSHARE JWT Bearer token authentication"}}},"paths":{"/metadata":{"get":{"tags":["Issuer"],"summary":"Gets credential types supported by the issuer","description":"Retrieves a list of supported credential types that the issuer can provide. More information in the [DCP specification](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#issuermetadata).\nThe credential types that are defined by the iSHARE Framework are defined on the [iSHARE Schemas Site](https://schemas.ishare.eu/v3/).\nAn iSHARE Participant Registry must at minimum issue a [Participant Credential](https://schemas.ishare.eu/v3/party/schema.json). An iSHARE Authorization Registry must at minimum issue a [Data Rights Credential](https://schemas.ishare.eu/v3/data-rights/schema.json).","operationId":"get-metadata","responses":{"200":{"description":"Metadata retrieved successfully","content":{"application/json":{"schema":{"$ref":"#/x-ext/59ce031"}}}},"401":{"description":"Unauthorized - Invalid or missing authentication"},"404":{"description":"Metadata not found"},"500":{"description":"Internal Server Error"}}}}}} ``` ### Request model There are no request parameters defined. ### Example request ```json GET /metadata Authorization: Bearer YOUR_SECRET_TOKEN ``` ### Response model The model for the IssuerMetadata is defined in: . * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the CredentialStatus type. Must contain `"IssuerMetadata"` * `issuer` **String**. Root level. (Required)\ The credential issuer DID. * `credentialsSupported`\ **Array of Objects**. Root level.\ An array of [credential objects](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#credentialobject) that the issuer supports. * `id`\ **String**. Contained in credential object. (Required)\ A string defining a unique, stable identifier for this CredentialObject. * `type`\ **String**. Contained in credential object. (Required)\ A string specifying the object type. Must contain `CredentialObject`. * `credentialType`\ **String**. Contained in credential object.\ A single string specifying type of credential being offered. * `credentialSchema`\ **String**. Contained in credential object.\ A URL pointing to the credential schema of the object in a VC's `credentialSubject` property. * `bindingMethods`\ **Array of strings**. Contained in credential object.\ An array of strings defining the key material that an issued credential is bound to. * `profile`\ **String**. Contained in credential object.\ Contains the alias of the [profiles](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#profiles-of-the-decentralized-claims-protocol), e.g. `"vc20-bssl/jwt"`. * `issuancePolicy`\ **Object**. Contained in credential object.\ A [presentation definition](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-definition) signifying the required [Verifiable Presentation](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#dfn-verifiable-presentation) for issuance. Further details are omitted from this specifications, refer to for more information. ### Example response ```json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "IssuerMetadata", "issuer": "did:ishare:EU.NL.NTRLNL-10000000", "credentialsSupported": [ { "id": "d5c77b0e-7f4e-4fd5-8c5f-28b5fc3f96d1", "type": "CredentialObject", "credentialType": "FrameworkRole", "credentialSchema": "https://schemas.ishare.eu/v3/party/claims/framework-role/schema.json", "bindingMethods": [ "did:web" ], "profile": "vc10-sl2021/jwt", "issuancePolicy": { "id": "a468fc48-5c1a-43c7-903e-ab1851882afb", "input_descriptors": [ { "id": "framework-compliance", "name": "Requires proof of compliance to framework", "purpose" :: "constraints": { "fields": [ { "path": [ "$.vc.type" ], "filter": { "type": "string", "pattern": "^FrameworkCompliance$" } } ] } } ] } } ] } ``` # Offers (DCP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the `/offers` endpoint prompts a holder to request a new Verifiable Credential. {% hint style="info" %} The `POST` request to the `/offers` is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with the **Decentralised Claims Protocol (DCP)**. {% endhint %} ## Issuer initiates reissuance of credential at holder > A Credential Issuer can proactively prompt a Holder to request a new Verifiable Credential. More information in the \[DCP specification]\(). ```json {"openapi":"3.1.0","info":{"title":"iSHARE Decentralized Claims Protocol (DCP) API specifications","version":"3.0"},"tags":[{"name":"Holder","description":"Endpoints relevant for the VC Holder role (e.g., storing credentials, receiving offers)."}],"paths":{"/offers":{"post":{"tags":["Holder"],"summary":"Issuer initiates reissuance of credential at holder","description":"A Credential Issuer can proactively prompt a Holder to request a new Verifiable Credential. More information in the [DCP specification](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#credential-offer-api).","operationId":"post-offer","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/x-ext/f1da757"}}}},"responses":{"200":{"description":"Credential offer received successfully"},"400":{"description":"Bad Request - Invalid credential offer request"},"500":{"description":"Internal Server Error"}}}}}} ``` ### Request model The model for the CredentialOfferMessage is defined in: . * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the CredentialOfferMessage type. Must contain `"CredentialOfferMessage"` * `issuer` **String**. Root level. (Required)\ The credential issuer DID. * `credentials`\ **Array of Objects**. Root level. (Required)\ An array of [credential objects](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#credentialobject) that the issuer supports. * `id`\ **String**. Contained in the credential object. (Required)\ A string defining a unique, stable identifier for this CredentialObject. * `type`\ **String**. Contained in credential object. (Required)\ A string specifying the object type. Must contain `CredentialObject`. * `credentialType`\ **String**. Contained in credential object.\ A single string specifying type of credential being offered. * `bindingMethods`\ **Array of strings**. Contained in credential object.\ An array of strings defining the key material that an issued credential is bound to. * `profile`\ **String**. Contained in credential object.\ Contains the alias of the [profiles](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#profiles-of-the-decentralized-claims-protocol), e.g. `"vc20-bssl/jwt"`. * `issuancePolicy`\ **Object**. Contained in credential object.\ A [presentation definition](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-definition) signifying the required [Verifiable Presentation](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#dfn-verifiable-presentation) for issuance. Further details are omitted from this specifications, refer to for more information. ### Example request ```json POST /offers Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "CredentialOfferMessage", "issuer": "did:ishare:EU.NL.NTRLNL-10000000", "credentials": [ { "id": "d5c77b0e-7f4e-4fd5-8c5f-28b5fc3f96d1", "type": "CredentialObject", "credentialType": "FrameworkRole", "bindingMethods": [ "did:web" ], "profile": "vc10-sl2021/jwt", "issuancePolicy": { "id": "a468fc48-5c1a-43c7-903e-ab1851882afb", "input_descriptors": [ { "id": "framework-compliance", "name": "Requires proof of compliance to framework", "purpose" :: "constraints": { "fields": [ { "path": [ "$.vc.type" ], "filter": { "type": "string", "pattern": "^FrameworkCompliance$" } } ] } } ] } } ] } ``` ### Response model On succesfull receipt of the CredentialOfferMessage, the holder must return a 200 code. # Resolution (DCP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the `/presentations/query` endpoint queries the holder for credentials, after which the holder sends a set of Verifiable Presentations as a response. {% hint style="info" %} The `POST` request to the `/presentations/query` is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with the **Decentralised Claims Protocol (DCP)**. {% endhint %} ## Verifier requests Verifiable Presentation from holder > The Resolution API defines the Credential Service endpoint for querying credentials and returning a set of Verifiable Presentations. More information in the \[DCP specification]\(. ```json {"openapi":"3.1.0","info":{"title":"iSHARE Decentralized Claims Protocol (DCP) API specifications","version":"3.0"},"tags":[{"name":"Holder","description":"Endpoints relevant for the VC Holder role (e.g., storing credentials, receiving offers)."}],"security":[{"BearerAuth":[]}],"components":{"securitySchemes":{"BearerAuth":{"type":"http","scheme":"bearer","bearerFormat":"JWT","description":"iSHARE JWT Bearer token authentication"}}},"paths":{"/presentations/query":{"post":{"tags":["Holder"],"summary":"Verifier requests Verifiable Presentation from holder","description":"The Resolution API defines the Credential Service endpoint for querying credentials and returning a set of Verifiable Presentations. More information in the [DCP specification](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#resolution-api.","operationId":"post-vp-request","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/x-ext/5c2969b"}}}},"responses":{"200":{"description":"VP request received successfully","content":{"application/json":{"schema":{"$ref":"#/x-ext/5dff8d7"}}}},"400":{"description":"Bad Request - possibly because both PresentationQueryMessage and presentationDefinition are provided (only one is allowed)"},"500":{"description":"Internal Server Error"}}}}}} ``` ### Request model The model for the PresentationQueryMessage is defined in: . Verifiable presentations containing credentials may be requested using [scopes](https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0/#scopes) or using a [presentation definition](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-definition). * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the PresentationQueryMessage type. Must contain `"PresentationQueryMessage"` * `scope`\ **Array of Strings**. Root level.\ A non-empty array of scopes. * `presentationDefinition`\ **Object**. Root level.\ An object containing the definition of the requested presentation. Further details on . A `PresentationQueryMessage` *MUST* contain either a `presentationDefinition` or a `scope` parameter. If both parameters are present it is an error and the client *MUST* return an `HTTP 400 BAD REQUEST` response. ### Example request #### Example using scopes ```json POST /presentations/query Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "PresentationQueryMessage", "scope": [ "org.eclipse.dspace.dcp.vc.type:X509CertificateCredential", "org.eclipse.dspace.dcp.vc.type:FrameworkComplianceCredential", "org.eclipse.dspace.dcp.vc.type:FrameworkAgreementCredential", "org.eclipse.dspace.dcp.vc.type:FrameworkRoleCredential" ] } ``` #### Example using presentation definition ```json POST /presentations/query Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "PresentationQueryMessage", "presentationDefinition": { "id": "ishareFrameworkCompliance", "name": "iSHARE Framework Compliance", "purpose": "Request proof of compliance with the iSHARE Framework", "input_descriptors": [ { "id": "ishareFrameworkComplianceFrameworkIdAndStatus", "format": { "ldp_vc": { "proof_type": [ "Ed25519Signature2018" ] } }, "constraints": { "fields": [ { "path": [ "$.type" ], "filter": { "type": "string", "pattern": "FrameworkCompliance" } }, { "path": [ "$.frameworkId" ], "filter": { "type": "string", "pattern": "iSHARE" } }, { "path": [ "$.status" ], "filter": { "type": "string", "pattern": "active" } } ] } } ] } } ``` ### Response model On succesfull receipt of the PresentationRequestMessage, the holder must return a 200 code and a PresentationResponseMessage. A `PresentationResponseMessage` should only include valid (non-expired, non-revoked, non-suspended) credentials. The model for the PresentationQueryMessage is defined in: . * `@context`\ **Array of Strings**. Root level. (Required)\ Specifies a valid Json-Ld context. Must contain `"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"` * `type`\ **String**. Root level. (Required)\ A string specifying the PresentationResponseMessage type. Must contain `"PresentationResponseMessage"` * `presentation`\ **Array of Strings**. Root level.\ An array of Verifiable Presentations. The Verifiable Presentations may be strings, JSON objects, or a combination of both depending on the format. * `presentationSubmission`\ **Object**. Root level.\ A valid Presentation Submission. Further details on . Implementations that support the `presentationDefinition` parameter *MUST* include the `presentationSubmission` parameter. ### Example response #### Example including presentations ```json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "PresentationResponseMessage", "presentation": [ "presentation1", "presentation2" ] } ``` #### Example including presentation and presentationSubmission ```json { "@context": [ "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld" ], "type": "PresentationResponseMessage", "presentation": [ "jwtPresentation" ], "presentationSubmission": { "id": "ishareFrameworkCompliancePresentation", "definition_id": "ishareFrameworkCompliance", "descriptor_map": [ { "id": "ishareFrameworkComplianceFrameworkIdAndStatus", "format": "jwt_vp", "path": "$.presentation[0]" } ] } } ``` # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VC**: * **OpenID4VCI**: Credential Issuance endpoints * **OpenID4VP**: Credential Presentation endpoints # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} All the endpoints included in the iSHARE Developer Portal are in line with [OpenID for Verifiable Presentations (OpenID4VP) v1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html). The endpoints are provided for convenience, and the examples used in the pages about the endpoints reflect how iSHARE participants may apply verifiable presentations in their dataspace. For each role, the endpoints that are required for OpenID4VP are listed under an 'OpenID4VP Endpoints' section. The following table provides an overview of required endpoints per role.
EndpointAuthorization Registry (verifier)Entitled Party (holder)Identity Provider (verifier, holder)Participant Registry (verifier, holder)Service Consumer (holder)Service Provider (verifier)
/pages/iHFhoEc5mOYb1jn1BZaEtruefalsetruetruefalsetrue
/pages/IW41uM4MamlGFsXBlRrMtruefalsetruetruefalsetrue
/pages/zVnylljLOiWJGCbhYO2Mtruetruetruetruetruetrue
# Verifier Metadata (OpenID4VP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `GET` request to the `/.well-known/openid-verifier` endpoint provides discovery information about the verifier, including supported presentation request formats, presentation endpoint URL, authorization endpoint URL, and other metadata required for OpenID4VP verifiable presentation flows. {% hint style="info" %} The `GET` request to the `/.well-known/openid-verifier` is an **OPTIONAL** endpoint and is part of iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Presentations (OpenID4VP)**. {% endhint %} ### Endpoint ``` GET /.well-known/openid-verifier ``` The base URL for this endpoint may be published in the [capabilities endpoint](/all-roles-common-endpoints/capabilities) under `publicServices` with identifier `"OpenID4VPVerifierBaseUrl"` for verifier roles. ### Request model There are no request parameters defined. ### Example request ``` GET /.well-known/openid-verifier Host: verifier.ishare.eu ``` ### Response model The response is a JSON object containing the Verifier Metadata as specified in [OpenID4VP Section 6](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-verifier-metadata). * `verifier`\ **String**. (Required)\ The URL of the Verifier. This MUST be the base URL used to construct verifier endpoints. * `authorization_endpoint`\ **String**. (Required)\ The URL of the Authorization Endpoint where presentation requests are initiated. * `presentation_endpoint`\ **String**. (Required)\ The URL of the Presentation Endpoint where verifiable presentations are submitted. * `presentation_definition_supported`\ **Array of Objects**.\ Array of supported presentation definition formats. * `vp_formats_supported`\ **Object**.\ Object containing supported verifiable presentation formats (e.g., `vc+sd-jwt`, `mso_mdoc`). ### Example response ```json { "verifier": "https://verifier.ishare.eu", "authorization_endpoint": "https://verifier.ishare.eu/authorize", "presentation_endpoint": "https://verifier.ishare.eu/presentation", "presentation_definition_supported": [ { "format": "vp_token", "presentation_definition_uri_supported": true } ], "vp_formats_supported": { "vc+sd-jwt": { "cryptographic_binding_methods_supported": [ "did:web" ], "cryptographic_suites_supported": [ "ES256" ] } } } ``` # Authorization Endpoint (OpenID4VP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `GET` or `POST` request to the authorisation endpoint initiates a verifiable presentation request. This endpoint is part of the OpenID for Verifiable Presentations (OpenID4VP) protocol and follows OAuth 2.0 authorisation flow patterns. {% hint style="info" %} The authorisation endpoint for OpenID4VP is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Presentations (OpenID4VP)**. {% endhint %} ### Endpoint ``` GET /authorize POST /authorize ``` The URL for this endpoint is provided in the Verifier Metadata (see [Verifier Metadata](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp)). This endpoint may be the same as the standard iSHARE authorisation endpoint, but supports additional parameters for verifiable presentation requests. ### Request model #### Parameters The request parameters follow the OAuth 2.0 authorisation request format with OpenID4VP-specific additions: * `response_type`\ **String**. (Required)\ OAuth 2.0 response type. For OpenID4VP, MUST include `vp_token` (e.g., `vp_token` or `code vp_token`). * `client_id`\ **String**. (Required)\ The client identifier. Within iSHARE, this MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) when applicable. * `redirect_uri`\ **String**. (Required)\ The redirect URI where the response will be sent. * `scope`\ **String**.\ OAuth 2.0 scope parameter. May include credential types or presentation scopes. * `presentation_definition`\ **Object**.\ A [Presentation Definition](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-definition) object specifying the required credentials and constraints. * `presentation_definition_uri`\ **String**.\ A URI pointing to a Presentation Definition document. * `nonce`\ **String**.\ A nonce to prevent replay attacks. * `state`\ **String**.\ OAuth 2.0 state parameter for maintaining state between request and callback. ### Example request ``` GET /authorize?response_type=vp_token&client_id=did:ishare:EU.NL.NTRLNL-10000001&redirect_uri=https://wallet.example.com/cb&scope=openid&presentation_definition_uri=https://verifier.ishare.eu/presentation-definitions/participant-credential&nonce=abc123&state=xyz789 Host: verifier.ishare.eu ``` ### Response model The response follows OAuth 2.0 authorization response format: * `vp_token`\ **String**.\ A verifiable presentation token (when `response_type` includes `vp_token`). * `code`\ **String**.\ An authorization code (when `response_type` includes `code`). * `state`\ **String**.\ The state parameter value from the request. * `presentation_submission`\ **Object**.\ A [Presentation Submission](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-submission) object when using presentation definitions. ### Example response The response is typically a redirect to the `redirect_uri` with parameters: ``` https://wallet.example.com/cb?vp_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...&state=xyz789 ``` ### iSHARE-Specific Requirements Within iSHARE, the following requirements apply: * Clients (holder applications) MUST NOT be pre-registered. A look-up in the Participant Registry is sufficient. * The `client_id` MUST contain a valid Party Identifier when applicable. * The verifier MUST validate the requesting party's authorization to request verifiable presentations. * The authorization endpoint may be the same as the standard iSHARE authorization endpoint used for OpenID Connect flows, but MUST support the additional OpenID4VP parameters. # Presentation Endpoint (OpenID4VP) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the presentation endpoint is where verifiable presentations are submitted by holders. This endpoint is part of the OpenID for Verifiable Presentations (OpenID4VP) protocol. {% hint style="info" %} The `POST` request to the presentation endpoint is an **OPTIONAL** endpoint and is part of the iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Presentations (OpenID4VP)**. {% endhint %} ### Endpoint ``` POST /presentation ``` The URL for this endpoint is provided in the Verifier Metadata (see [Verifier Metadata](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp)). ### Request model #### Headers * `Content-Type`\ **String**.\ MUST be equal to `application/x-www-form-urlencoded` or `application/json`. #### Parameters The request body MUST contain the following parameters (when using `application/x-www-form-urlencoded`): * `vp_token`\ **String**.\ A verifiable presentation token containing the verifiable presentation. * `presentation_submission`\ **String (JSON)**.\ A [Presentation Submission](https://identity.foundation/presentation-exchange/spec/v2.1.1/#presentation-submission) object when using presentation definitions. * `state`\ **String**.\ The state parameter value from the authorization request. When using `application/json`, the request body is a JSON object containing the same parameters. ### Example request ``` POST /presentation Host: verifier.ishare.eu Content-Type: application/x-www-form-urlencoded vp_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...&presentation_submission={"id":"submission123","definition_id":"participant-credential","descriptor_map":[...]}&state=xyz789 ``` ### Response model #### Success Response The response is a JSON object or redirect containing: * `vp_token`\ **String**.\ The verifiable presentation token (if not already provided in request). * `presentation_submission`\ **Object**.\ The presentation submission object (if using presentation definitions). * `state`\ **String**.\ The state parameter value from the request. #### Error Response Error responses follow standard HTTP status codes and OAuth 2.0 error format: * `error`\ **String**. (Required)\ Error code (e.g., `invalid_request`, `invalid_vp_token`, `presentation_rejected`). * `error_description`\ **String**.\ Human-readable description of the error. * `error_uri`\ **String**.\ URI pointing to a document describing the error. ### Example response ```json { "vp_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "presentation_submission": { "id": "submission123", "definition_id": "participant-credential", "descriptor_map": [ { "id": "participant-credential-descriptor", "format": "vc+sd-jwt", "path": "$.vp.verifiableCredential[0]" } ] }, "state": "xyz789" } ``` ### iSHARE-Specific Requirements Within iSHARE, the following requirements apply: * The verifier MUST validate the verifiable presentation: * Verify the presentation signature * Verify all included credential signatures * Check credential expiration and status * Verify issuer trust status * The verifier MUST verify that the credentials in the presentation match the requested presentation definition or scope. * The verifier MUST verify that the holder is authorized to present the credentials. * All verifiable presentations MUST conform to the [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/). * Credentials in presentations MUST use schemas published at [schemas.ishare.eu](https://schemas.ishare.eu). # OpenID4VCI Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} All the endpoints included in the iSHARE Developer Portal are in line with [OpenID for Verifiable Credential Issuance (OpenID4VCI) v1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). The endpoints are provided for convenience and the examples used in the pages about the endpoints reflect how iSHARE participants may apply verifiable credentials in their dataspace. For each role the endpoints that are required for OpenID4VCI are listed under an 'OpenID4VCI Endpoints' section. The following table provides an overview of required endpoints per role.
EndpointAuthorization Registry (issuer)Identity Provider (issuer)Participant Registry (issuer)
/pages/ZyKqgoY4eHh9gcJcCa0atruetruetrue
/pages/97MiqjpuPQTLVKEEk6yctruetruetrue
/pages/1batLUAK0eg3LCFhLzW6truetruetrue
# Credential Issuer Metadata (OpenID4VCI) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `GET` request to the `/.well-known/openid-credential-issuer` endpoint provides discovery information about the credential issuer, including supported credential types, credential endpoint URL, token endpoint URL, and other metadata required for OpenID4VCI credential issuance. {% hint style="info" %} The `GET` request to the `/.well-known/openid-credential-issuer` is an **OPTIONAL** endpoint and is part of iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Credential Issuance (OpenID4VCI)**. {% endhint %} ### Endpoint ``` GET /.well-known/openid-credential-issuer ``` The base URL for this endpoint is published in the [capabilities endpoint](/all-roles-common-endpoints/capabilities) under `publicServices` with identifier `"OpenID4VCICredentialIssuerBaseUrl"`. ### Request model There are no request parameters defined. ### Example request ``` GET /.well-known/openid-credential-issuer Host: credential-issuer.ishare.eu ``` ### Response model The response is a JSON object containing the Credential Issuer Metadata as specified in [OpenID4VCI Section 11.2](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-). * `credential_issuer`\ **String**. (Required)\ The URL of the Credential Issuer. This MUST be the base URL used to construct credential issuer endpoints. * `authorization_server`\ **String**.\ The URL of the Authorization Server. If not provided, the `credential_issuer` value is used as the Authorization Server URL. * `credential_endpoint`\ **String**. (Required)\ The URL of the Credential Endpoint where credential requests are made. * `token_endpoint`\ **String**.\ The URL of the OAuth 2.0 Token Endpoint. If not provided, the `credential_issuer` value is used to construct the token endpoint. * `credential_issuer_endpoint`\ **String**.\ The URL of the Credential Issuer Metadata endpoint. If not provided, the `credential_issuer` value is used to construct the metadata endpoint. * `credentials_supported`\ **Array of Objects**. (Required)\ Array of credential configurations supported by this issuer. Each object contains: * `format`\ **String**. (Required)\ The credential format (e.g., `vc+sd-jwt`, `mso_mdoc`). * `credential_definition`\ **Object**.\ The credential definition containing: * `type`\ **Array of Strings**. (Required)\ Array of credential types (e.g., `["VerifiableCredential", "ParticipantCredential"]`). * `credentialSubject`\ **Object**.\ The credential subject structure. The credential types that are defined by the iSHARE Framework are defined on the [iSHARE Schemas Site](https://schemas.ishare.eu/v3/). * An iSHARE Participant Registry must at minimum support [Participant Credential](https://schemas.ishare.eu/v3/party/schema.json) and related claim credentials. * An iSHARE Authorization Registry must at minimum support [Data Rights Credential](https://schemas.ishare.eu/v3/datarights/schema.json). * An iSHARE Identity Provider must at minimum support [Identity Credential](https://schemas.ishare.eu/v3/party/claims/idp-assertion/schema.json). ### Example response ```json { "credential_issuer": "https://credential-issuer.ishare.eu", "authorization_server": "https://credential-issuer.ishare.eu", "credential_endpoint": "https://credential-issuer.ishare.eu/credential", "token_endpoint": "https://credential-issuer.ishare.eu/token", "credential_issuer_endpoint": "https://credential-issuer.ishare.eu/.well-known/openid-credential-issuer", "credentials_supported": [ { "format": "vc+sd-jwt", "credential_definition": { "type": [ "VerifiableCredential", "ParticipantCredential" ], "credentialSubject": {} } } ] } ``` # Token Endpoint (OpenID4VCI) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the token endpoint issues access tokens for credential issuance. This endpoint is an OAuth 2.0 endpoint that supports grant types for OpenID4VCI credential issuance flows. {% hint style="info" %} The `POST` request to the token endpoint for OpenID4VCI is an **OPTIONAL** endpoint and is part of iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Credential Issuance (OpenID4VCI)**. {% endhint %} ### Endpoint ``` POST /token ``` The URL for this endpoint is provided in the Credential Issuer Metadata (see [Credential Issuer Metadata](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-issuer-metadata-openid4vci)). This endpoint may be the same as the standard iSHARE token endpoint but supports additional grant types for credential issuance flows. ### Request model The request body MUST be sent as `application/x-www-form-urlencoded` and contain the following parameters: * `grant_type`\ **String**. (Required)\ OAuth 2.0 grant type. For OpenID4VCI, supported values include: * `authorization_code`: Used when the holder has obtained an authorization code * `pre-authorized_code`: Used when a pre-authorized code has been provided * `code`\ **String**.\ The authorization code received from the authorization endpoint. Required when `grant_type` is `authorization_code`. * `pre-authorized_code`\ **String**.\ The pre-authorized code provided by the issuer. Required when `grant_type` is `pre-authorized_code`. * `client_id`\ **String**.\ The client identifier. Within iSHARE, this MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) when applicable. * `client_assertion_type`\ **String**.\ Client assertion type. Within iSHARE, MUST be equal to `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` when using client assertion authentication. * `client_assertion`\ **String (JWT)**.\ Client assertion JWT. Within iSHARE, MUST contain a [JWT token conforming to iSHARE specifications](/reference/ishare-jwt) when using client assertion authentication. * `redirect_uri`\ **String**.\ The redirect URI used in the authorization request. Required when `grant_type` is `authorization_code`. ### Example request ``` POST /token Host: credential-issuer.ishare.eu Content-Type: application/x-www-form-urlencoded grant_type=authorization_code& code=SplxlOBeZQQYbYS6WxSbIA& redirect_uri=https://wallet.example.com/cb& client_id=did:ishare:EU.NL.NTRLNL-10000001& client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... ``` ### Response model The response is a JSON object containing: * `access_token`\ **String**. (Required)\ The access token issued by the authorization server. * `token_type`\ **String**. (Required)\ The token type. MUST be `Bearer`. * `expires_in`\ **Integer**.\ The lifetime in seconds of the access token. * `c_nonce`\ **String**.\ A nonce to be used in the credential request for proof of possession. * `c_nonce_expires_in`\ **Integer**.\ The lifetime in seconds of the `c_nonce`. * `scope`\ **String**.\ The scope of the access token. ### Example response ```json { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "token_type": "Bearer", "expires_in": 3600, "c_nonce": "8Xz5r4k3m2", "c_nonce_expires_in": 300 } ``` ### iSHARE-Specific Requirements Within iSHARE, the following requirements apply: * Clients (holder applications) MUST NOT be pre-registered. A look-up in the Participant Registry is sufficient. * The `client_id` MUST contain a valid Party Identifier when applicable. * Client authentication using `client_assertion` (JWT) MUST be supported and MUST conform to [iSHARE JWT specifications](/reference/ishare-jwt). * The certificate used to sign the `client_assertion` MUST be validated according to iSHARE certificate validation requirements (see [Authentication](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/reference/authentication.md)). # Credential Endpoint (OpenID4VCI) {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The `POST` request to the `/credential` endpoint is where credential requests are made and verifiable credentials are issued. This endpoint is part of the OpenID for Verifiable Credential Issuance (OpenID4VCI) protocol. {% hint style="info" %} The `POST` request to the `/credential` is an **OPTIONAL** endpoint and is part of iSHARE Framework's Verifiable Credentials support in line with **OpenID for Verifiable Credential Issuance (OpenID4VCI)**. {% endhint %} ### Endpoint ``` POST /credential ``` The URL for this endpoint is provided in the Credential Issuer Metadata (see [Credential Issuer Metadata](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-issuer-metadata-openid4vci)). ### Request model #### Headers * `Authorization`\ **String**. (Required)\ OAuth 2.0 authorization based on bearer token. MUST contain "Bearer " + access token value. The access token is obtained from the [Token Endpoint](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/token-endpoint-openid4vci). * `Content-Type`\ **String**.\ MUST be equal to `application/json`. #### Parameters The request body MUST be a JSON object containing: * `format`\ **String**.\ The credential format requested (e.g., `vc+sd-jwt`, `mso_mdoc`). If not specified, the issuer's default format is used. * `credential_definition`\ **Object**.\ The credential definition specifying the type of credential requested: * `type`\ **Array of Strings**. (Required)\ Array of credential types (e.g., `["VerifiableCredential", "ParticipantCredential"]`). * `proof`\ **Object**.\ Proof of possession of the key material. Contains: * `proof_type`\ **String**. (Required)\ The proof type (e.g., `jwt`). * `jwt`\ **String**.\ The JWT proof when `proof_type` is `jwt`. This JWT MUST be signed with the holder's key and MUST include the `c_nonce` received from the token endpoint. * `transaction_id`\ **String**.\ Transaction identifier for tracking the credential issuance request. ### Example request ```json POST /credential Host: credential-issuer.ishare.eu Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... Content-Type: application/json { "format": "vc+sd-jwt", "credential_definition": { "type": [ "VerifiableCredential", "ParticipantCredential" ] }, "proof": { "proof_type": "jwt", "jwt": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." } } ``` ### Response model The response is a JSON object containing: * `format`\ **String**. (Required)\ The credential format of the issued credential. * `credential`\ **String**. (Required)\ The issued verifiable credential. The format depends on the `format` value: * For `vc+sd-jwt`: A signed JWT containing the credential * For `mso_mdoc`: A mobile document format credential * `c_nonce`\ **String**.\ A new nonce for subsequent credential requests. * `c_nonce_expires_in`\ **Integer**.\ The lifetime in seconds of the `c_nonce`. ### Example response ```json { "format": "vc+sd-jwt", "credential": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsInZjIjp7InR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJQYXJ0aWNpcGFudENyZWRlbnRpYWwiXX19.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUkxOTC0xMDAwMDAwMCIsInN1YiI6ImRpZDppc2hhcmU6RVUuTk4uTlRSTkwtMTAwMDAwMDEiLCJ2YyI6eyJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiUGFydGljaXBhbnRDcmVkZW50aWFsIl0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7InBhcnR5SWQiOlsiZGlkOmlzaGFyZTpFVS5OTi5OVFJOTC0xMDAwMDAwMSJdLCJwYXJ0eU5hbWUiOiJUZXN0IFBhcnRpY2lwYW50In19LCJpYXQiOjE2OTk5OTk5OTksImV4cCI6MTcyMTU1NTU1NX0.signature", "c_nonce": "9Yz6s5t4n3", "c_nonce_expires_in": 300 } ``` ### iSHARE-Specific Requirements Within iSHARE, the following requirements apply: * All issued credentials MUST conform to the [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/). * Credentials MUST use schemas published at [schemas.ishare.eu](https://schemas.ishare.eu). * Credentials MUST include a `credentialStatus` property when required by the schema (see [Bitstring Status List](/reference/verifiable-credentials-as-part-of-the-ishare-framework#bitstring-status-list-v10)). * The issuer MUST validate the access token and proof of possession before issuing credentials. * The issuer MUST verify that the requesting party is authorized to receive the requested credential type. # Getting started The Authorisation Registry role is fulfilled by a legal entity that provides solutions for Adhering Parties for the storage of delegation and authorisation information. An Authorisation Registry: * Can hold information on delegations to Service Consumers; i.e. information indicating what parts of the rights of an Entitled Party are delegated to a Service Consumer. * Can check, based on this information, whether a machine representing a legal entity is authorised to take delivery of a service; * Can confirm whether this is the case for the Service Provider; * Can issue a DataRights (Verifiable) Credential on behalf of the Entitled Party to Service Consumer to store in a Credential Store (wallet) and present them to Service Providers during access workflows; * Can expose them via the [DCP Endpoints](/authorisation-registry-role/m2m-verifiable-credential-endpoints) for machine Service Consumers and via the [OIDC4VC/VP Endpoints](/authorisation-registry-role/h2m-verifiable-credential-endpoints/openid4vci-endpoints) for human Service Consumers. {% hint style="info" %} For the structure of the DataRights Credential, see the [JSON Schema.](https://schemas.ishare.eu/v3/datarights/schema.json) * Can bilaterally provide info about Authorisation Registry to Service Provider and/or Service Consumer. {% endhint %} As a result, Adhering Parties can outsource tasks concerning the management of authorisation and delegation information to an Authorisation Registry instead of implementing their own tooling. To double-check if required endpoints are implemented, please use the following list as a cheat sheet: Authorisation Registry * [ ] [Access Token](/all-roles-common-endpoints/access-token-m2m) * [ ] [Capabilities](/all-roles-common-endpoints/capabilities) * [ ] [Delegation](/authorisation-registry-role/delegation-endpoint) # Delegation {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ### Request model #### Headers * `Authorization`\ **String**.\ OAuth 2.0 authorisation based on a bearer token. MUST contain “Bearer “ + access token value. How to retrieve the access token can be found in the [Access Token Endpoint section](/all-roles-common-endpoints/access-token-m2m). * `Content-Type`\ **String**.\ Defines the request body content type. MUST be equal to *application/json*. #### Parameters The body of the request MUST contain a JSON with the following structure. * `delegationRequest`\ **Object**. Root level. (Required)\ The request for delegation evidence. * `policyIssuer`\ **String**. Contained in `delegationRequest`. (Required)\ Identifier of the delegator (the delegating entity, usually the Entitled Party). * `target`\ **Object**. Contained in `delegationRequest`. (Required)\ MUST for the root level contain an `accessSubject`. No other elements are allowed. * `accessSubject`\ **String**. Contained in `target`. (Required)\ Identifier of the delegate, also known as the entity that receives the delegated rights (usually the Service Consumer). * `policySets`\ **Array of Objects**. Contained in `delegationRequest`. (Required)\ A container for one or more objects containing policy elements with an indication for further delegation. Note that policySet elements within one delegationRequest MUST not restrict each other, but rather offer a mechanism to express additional rights. They will be evaluated by the Authorisation Registry in a *permit-override* manner, allowing a *Permit* if only one of the policySet elements evaluates to *Permit*. * `policies` **Array of Objects**. Contained in `policySets`. (Required) Used to express the actual rights for which evidence is being requested. Note that policies within one policySet object MUST not restrict each other, but rather offer a mechanism to express additional rights. They will be evaluated in a *permit-override* manner, allowing a *Permit* if only one of the policy elements evaluates to *Permit*. * `target`\ **Object**. Contained in `policies`. (Required)\ Describes the target, in terms of resource and action, this request applies. It is also the scope that is permitted through the default rule. * `resource`\ **Object**. Contained in `target`. (Required)\ Contains `type`, `identifiers` and `attributes`. * `type`\ **String**. Contained in `resource`. (Required)\ String which describes the type of resource for which delegation evidence is requested. * `identifiers`\ **Array of Strings**. Contained in `resource`. (Required)\ An array of strings containing one or more resource identifiers for which the delegation evidence is requested. Use of wildcards (for example, "\*") is allowed. * `attributes`\ **Array of Strings**. Contained in `resource`. (Required)\ An array of attributes of the resources for which the delegation evidence is requested. Use of wildcards (for example, "\*") is allowed. * `actions`\ **Array of Strings**. Contained in `target`. (Required)\ An array of actions for which delegation evidence is requested. * `context`\ **Array of Objects**. Contained in `target`. *Optional.*\ Placeholder for any information regarding the context of the delegation request. This will help the Authorisation Registry in evaluating dynamic conditions before providing delegation evidence. * `serviceProvider`\ **Array of Strings**. Contained in `context`. *Optional.*\ Reserved name for a party identifier of the service providers at which the service will be consumed. * `rules`\ **Array of Objects**. Contained in `policies`. (Required) * `effect`\ **String**. Contained in `rules`. (Required)\ Value must be equal to *Permit* or *Deny*. In the delegationRequest a value of *Permit* is expected, requesting the Authorisation Registry evidence that access to the requested resource is permitted. * `delegationPath`\ **Array of Strings**. Root level. *Optional*.\ Container for one or more iSHARE identifier values for a situation where multiple delegation policies need to be linked together. * `previousSteps`\ **Array of Strings**. Root level. *Optional*.\ A container for one or more pieces of evidence, such that the client has a legitimate reason to request delegation of evidence. For example: * Client\_assertion * Delegation\_evidence in a delegation chain * Other evidence or information, as determined by the data space (could also be verified post-transaction), specification beyond the scope of this framework Privacy considerations: to prevent unallowed access to delegation evidence, a data space or participant can decide to require evidence or information in the previous\_steps attribute, depending on the nature of the data that is being shared. ### Response model The response contains a, containing an. The model of the `delegation_evidence_token` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=2.2#/jwt_payload_delegation_evidence_token). For convenience, the model of the delegation Evidence object, contained within the token, is described below: * `delegationEvidence`\ **Object**. Root level. (Required)\ The root of any delegation evidence. * `notBefore`\ **Integer**. Contained in `delegationEvidence`. (Required)\ Unix timestamp indicating the start of the validity period of this delegation evidence as indicated by the Entitled Party. By default, SHOULD be equal to the time of issuing of the delegation unless historic evidence is desired. * `notOnOrAfter`\ **Integer**. Contained in `delegationEvidence`. (Required)\ Unix timestamp indicating the end of the validity period of this delegation evidence. It is up to the issuer to provide the evidence to set this time. Note that a reasonable amount of time SHOULD be allowed for processing of longer delegation paths. Also note that evidence cannot be revoked, so setting very long validity periods SHOULD be avoided. * `policyIssuer`\ **String**. Contained in `delegationEvidence`. (Required)\ Identifier of the delegator, also known as the delegating entity (usually the Entitled Party). * `target`\ **Object**. Contained in `delegationEvidence`. (Required)\ MUST for the root level contain an accessSubject. No other elements are allowed. It makes the entire delegation evidence applicable only to this accessSubject. * `accessSubject`\ **Object**. Contained in `target`. (Required)\ Party identifier of the delegate, also known as the entity that receives the delegated rights (usually the Service Consumer). It can be any one of the id’s in id or alsoKnownAs. * `policySets`\ **Array of Objects**. Contained in `delegationEvidence`. (Required)\ A container, optional for one or more objects containing policy elements with an indication for further delegation. Note that policySet elements within one delegationEvidence MUST not restrict each other, but rather offer a mechanism to express additional rights. They MUST be evaluated in a *permit-override* manner, allowing a *Permit* if only one of the policySet elements evaluates to *Permit*. * `maxDelegationDepth`\ **Integer**. Contained in `policySets`. *Optional*.\ An optional element that, if present, indicates that further delegation of the rights, conveyed in the policy elements that are part of this PolicySet, is allowed. The value indicates the delegation steps that are allowed after this step in order to evaluate the entire delegation path to *Permit*. * `target` **Object**. Contained in `policySets`. *Optional*. Contains `environment`. * `environment` **Object**. Contained in `target`. *Optional*. Contains `licenses`. * `licenses` **Array of Strings and Objects**. Contained in `environment`. An array which describes which iSHARE licenses apply to this policy set. Please refer to the [iSHARE Licenses](https://licenses.ishare.eu/) for more information about structuring this array. * `policies` **Array of Objects**. Contained in `policySets`. (Required) Used to express the actual rights for which evidence is being provided. Note that policies within one policySet object MUST not restrict each other, but rather offer a mechanism to express additional rights. They will be evaluated in a *permit-override* manner, allowing a *Permit* if only one of the policy elements evaluates to *Permit*. * `target`\ **Object**. Contained in `policies`. (Required)\ Describes the target, in terms of resource and action, this request applies to. It is also the scope that is permitted through the default rule. * `resource`\ **Object**. Contained in `target`. (Required)\ Contains `type`, `identifiers` and `attributes`. * `type`\ **String**. Contained in `resource`. (Required)\ String which describes the type of resource to which the rules apply. * `identifiers`\ **Array of Strings**. Contained in `resource`. (Required)\ An array of strings containing one or more resource identifiers to which the rules apply. * `attributes`\ **Array of Strings**. Contained in `resource`. (Required)\ An array of attributes of the resources to which the rules apply. * `actions`\ **Array of Strings**. Contained in `target`. (Required)\ An array of actions that apply to this policy. * `rules`\ **Array of Objects**. Contained in `policies`. (Required) * `effect`\ **String**. Contained in `rules`. (Required)\ Value must be equal to *Permit* or *Deny*. * `conditions`\ **Object**. Contained in `rules`. *Optional.*\ Optional conditions which must be evaluated before the rule applies. For guidance on how to interoperably define conditions, refer to the page about delegation evidence conditions. The following keywords in conditions are reserved: * `serviceProvider`: reserved keyword for a condition that contains a party identifier of a Service Provider, which is allowed to provide services to the accessSubject. ### Example request 
> Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ

POST /delegation

{
  "delegationRequest": {
    "policyIssuer": "did:ishare:EU.NL.NTRNL-10000005",
    "target": {
      "accessSubject": "did:ishare:EU.NL.NTRNL-10000001"
    },
    "policySets": [
      {
        "policies": [
          {
            "target": {
              "resource": {
                "type": "GS1.CONTAINER",
                "identifiers": [
                  "180621.CONTAINER-Z"
                ],
                "attributes": [
                  "GS1.CONTAINER.ATTRIBUTE.ETA",
                  "GS1.CONTAINER.ATTRIBUTE.WEIGHT"
                ]
              },
              "actions": [
                "ISHARE.READ",
                "ISHARE.CREATE",
                "ISHARE.UPDATE",
                "ISHARE.DELETE"
              ],
              "context": {
                "serviceProvider": "did:ishare:EU.NL.NTRNL-10000003"
              }
            },
            "rules": [
              {
                "effect": "Permit"
              }
            ]
          }
        ]
      }
    ]
  },
  "delegation_path": [
    "did:ishare:EU.NL.NTRNL-10000007"
  ],
  "previous_steps": [
    "<delegation evidence token>"
  ]
}
### Example response The response contains an encoded JWT: ```json { "delegation_evidence_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHbERDQ0JIeWdBd0lCQWdJVWJsT1hOMmpiamVSaWJUcnoxN3FzTWd1Tlk4MHdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNME16SmFGdzB5TnpFeE1EWXhORE0wTXpGYU1ISXhDekFKQmdOVkJBWVRBazVNTVNRd0lnWURWUVFLREJ0VVpYTjBJRUYxZEdodmNtbHpZWFJwYjI0Z1VtVm5hWE4wY25reEpEQWlCZ05WQkFNTUcxUmxjM1FnUVhWMGFHOXlhWE5oZEdsdmJpQlNaV2RwYzNSeWVURVhNQlVHQTFVRVlRd09UbFJTVGt3dE1UQXdNREF3TURRd2dnRWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUUM4VndPQzIvWXVCNVpXeE5YMzNUYW55WFF6dEUzWWU3TjN0bTZsVGJ1OXEzbDlMYkNJeTlGelZvNHVWTjI1YnpKVDg2MlpQWXp4MFNrVVhvUkVUMFF0MnNMRFpZZ05SdjN0SDFuSkRFM0FKUlM4RUtDVlZ4Rllvc0tiQ2gzNDhadGRwd0tMVUtzUnE1M1VJcTBIaHF1bUptdHhVY2NUYk1OMXYwY1RXaDdXMVdBaVlRY0lqWmQwY0pweFBOYVRmVk5Ha093aHcyRDJTZlA4S0dlL1NicVBxVVUwVjNNNUJlWlRKS21HZDhJUzFlRUk1ZmRrK0ZhUGhRL2ZjbC9NaHRobzhXclJNVW1tNWw2Q21tMkkrbHVxVThSbkVQVjFYUlpJUFlzcmlJc1ZyaUFyb2FjNTdYaTB2SHh3bGUwK2JPdzJWZkpMUmgwM2l3NGFEMTVHKzYxVkFnTUJBQUdqZ2dJMU1JSUNNVEFPQmdOVkhROEJBZjhFQkFNQ0JrQXdEQVlEVlIwVEFRSC9CQUl3QURBZkJnTlZIU01FR0RBV2dCU3pHazlDUU9uWWVKMXIvL3drc0JDeE5EendpVEJYQmdnckJnRUZCUWNCQVFSTE1Fa3dSd1lJS3dZQkJRVUhNQUdHTzJoMGRIQnpPaTh2WTJFM0xtbHphR0Z5WlhSbGMzUXVibVYwT2pnME5ESXZaV3BpWTJFdmNIVmliR2xqZDJWaUwzTjBZWFIxY3k5dlkzTndNQkFHQTFVZElBUUpNQWN3QlFZRFZSMGdNQjhHQTFVZEpRUVlNQllHQ0NzR0FRVUZCd01FQmdvckJnRUVBWUkzQ2dNTU1Gc0dDQ3NHQVFVRkJ3RURCRTh3VFRBVEJnWUVBSTVHQVFZd0NRWUhCQUNPUmdFR0FqQTJCZ2dyQmdFRkJRY0JBd3dxVkdocGN5QnBjeUIwWlhOMElHVnpaV0ZzSUdObGNuUnBabWxqWVhSbElHWnZjaUIwWlhOMGFXNW5NQjRHQldlQkRBTUJCQlV3RXhNRFRsUlNFd0pPVEF3SU1UQXdNREF3TURRd2djY0dBMVVkSHdTQnZ6Q0J2RENCdWFDQnRxQ0JzNGFCc0doMGRIQnpPaTh2WTJFM0xtbHphR0Z5WlhSbGMzUXVibVYwT2pnME5ESXZaV3BpWTJFdmNIVmliR2xqZDJWaUwzZGxZbVJwYzNRdlkyVnlkR1JwYzNRL1kyMWtQV055YkNacGMzTjFaWEk5UTA0bE0wUmxTVVJCVTJWVFJVRk1UMGxFWDBsemMwTkJSelFsTWtOdmNtZGhibWw2WVhScGIyNUpaR1Z1ZEdsbWFXVnlKVE5FVGxSU1Rrd3RhVk5JUVZKRlZFVlRWQ1V5UTA4bE0wUnBVMGhCVWtWVVpYTjBKVEpEUXlVelJGaFlNQjBHQTFVZERnUVdCQlJBdHJ4TFpQQ2JCbnlQYy9ualdYYk9zQy95Q1RBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQWdFQVJzTktsVFBnVWRNTGZMU1V3b2ZuKzNSZmM2amVIR2d6bCtxQ29MMlRkbmxOOWZFdHY1TlMweFZyL2x5Ykx1MDFQdUk0Mmd4bmgvZ1BLUDA2ZlV1VXI1WVpySzVNeHczUUhZdzhpdlNDcndvcE1zSUhob1FjN0g2MUtZNlV1WlFJVXRCUitHdmVBVUx4NC9Vd2pKY0MrdTM3aWd3akZ6QkVneUQ1dzJGNHViajh5N0hlNEthVGhBM2xOVmkwVXprdDhUb1NBNnBoSTA2eTMwREYyUGN3UkloT1NkT1NSMzJZVTZxVXgxSXJnRU13K3VYa3NMYmt4eU0rdjQxek9jMkh5alpXZGpJTFZLbDBQYnhXcE9DYmdndm4wdDE0anhzaVVoekRFcHd1RVNFZHJhUnBoaVVrWlMrbHdqeEhEengyRlhVKys0d053ak9yUldhdXlkSHlsaGZtMlMvMWFwTmlvUk0zcXZscXVrUWEyVzhqZWRYR2Y5d0tEcDZBc2VBK3RlNWJVb1VRUGZTYnNzYWFHMllucWRjNTFDbk1WZldmemlZWTJ3RWpKVHpwZ004SXRmRDlrV1VXbWwxYi9wODhiQ3RTZFZLbHFKRUlXazdvK1V5QTZCUFBIVUhsUkRRNlU5aGlCM3dGeHQ3K3FPNXFDd2hPN0xkSmkzNEZtUEE4WHhOdHZCMjB6dFlveS9PcXlDanVUbUxQU0p6Yk9BcVlPSzl0TmozSU5aMWUvZjdYV2Q0ME9JVnRXeFYzdEM4ZUQ4TS9zV0k3ZUt2ajhET0JWcDBjMkNBL1E2ekVRSzNTNWM5U1ZuVGZLQzQ1RFhWaU8zYTV2cGhHakNlSG5EWWN4SmpHTzZ3d0szR1hmNHVGeVZzRjducGVoN1N2NnR4UDE5QjBnWHprWWdFPSIsIk1JSUYyakNDQThLZ0F3SUJBZ0lVUEczK1RBbnhWT0JjZTlOYVB0OXBUQWdtNVI0d0RRWUpLb1pJaHZjTkFRRUxCUUF3UWpFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlUZFdKRFFVY3pNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQWVGdzB5TXpBNE1qVXdPVEF4TXpKYUZ3MDBPREE0TWpVd09UQXdNRFZhTUYweEhqQWNCZ05WQkFNTUZXVkpSRUZUWlZORlFVeFBTVVJmU1hOelEwRkhOREVaTUJjR0ExVUVZUk1RVGxSU1Rrd3RhVk5JUVZKRlZFVlRWREVUTUJFR0ExVUVDaE1LYVZOSVFWSkZWR1Z6ZERFTE1Ba0dBMVVFQmhNQ1dGZ3dnZ0lpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElDRHdBd2dnSUtBb0lDQVFEYW5VZ00xL1BReVhOVFgrVU9MR3JaalM4SGFUV1IvUDR4RDhTTUNSeE9YSEt6SExRcUVRT3VIRC93K3J4OS9iRXd6SDR3VmZKMG02L3I1NktPZzB3TFVsVndPeWlrT1hHb0lURDJ1K1VpOXQyNHRZSWt4OHpqTEc3VkhWY3c0ZFhPdDkyc3ZLWTFMeWJ2bHByb1d6VEhsUndvSU8xWVE0aE8rcnlic3cvS0VERVhVYmtvd2psSEFQY3duc09XNjQzNjdFTitlelQxc1M4ZHpGSXhtRzhxQzJMck0yc1hKV3FxNXZKZUUvODZUZloyTk1PK0NVeGtqajd1UGdiVzJWL01PVWhZeUF0R0FqemQvS3dPckxNUk1ZYVhPSWo2MW04UjcxbmgvTFY5bjhkbmowd1RRT05USGh1TTdtZFpReGhxT2RrTDJja1NyQldpM2F0RVZUMU9oQlJYNEZtbWhJaG1TV3VDdGd5S2lEQ0lvdHlHQXNYMm82ODE3ZmVlNFJkdHdmdzlRNG9OM05BaHRvZDYwaU9BV0FwVnQrQlQ1dHZkZ0dPWVdQY2JNUjVwR3picDM4ZEdVeXV3WVpWNExBbklHU201eWF1Y05FMkUyeHJRQ2JFZVptNFJQc3g1SmxlV3ppcGsrNDJkN3ZxdldEODhJUWNRK2JaTTJYNHJKQlpOczE2NkNseCttNkhtS3hLQUxlYlV0anN6c2d5SDhjcTEwZCtrNEFvOG9DYU9ZanYySWFFYk1kK2ZWL1VmOGtQa3pUdEtsdHRkcWlpeG9JcXljWE1FZ0JhU2drdWI3WG9RNksyNnRSUEowdzVRa3V1aDNNS3RHRVdmVzdFRUdtcG5DcWpPdjYvckFNSmlNV3loMUlnTGdOQlVQUDd6YVZQcERBdEM4OE9TSlFJREFRQUJvNEdzTUlHcE1CSUdBMVVkRXdFQi93UUlNQVlCQWY4Q0FRRXdId1lEVlIwakJCZ3dGb0FVNHViWDBwNkRWak45REt0T1dXTVlBcytIeGRRd0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBcEJnTlZIU1VFSWpBZ0JnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3SFFZRFZSME9CQllFRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1BNEdBMVVkRHdFQi93UUVBd0lCQmpBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQWdFQVp2NUd1a3gwUEV2VlJFSXQ4TVRhUGZDSDRhd3lpaVl5aTE3aDZSNUxMazFyZXJ3UXNTU1NIZlZxZnRkd1JGMG9jTHAyUFhKaGUwNzVxVjQwNkMwNENqYW1OazNlejlaaU5IQ05qUHRmaWQ2b094cXoxWGs4WFBqTllFbGJBRm1QN2VLbC80NDF2WmhHdWsvUmhYR054UWJ0bzBRMTZnOElSY0dEdldnTmh0cnRCMUcyeFNtdEIxUzJ1VXBTYWlaVk5PcmtkelRoaUVKc2VVUkJvWHhVWElxcEx5UFRSbDZNTWdWYUxHUllSYzN2WWlqNEI3TTJoQk43L2NqbkdMc01WdGdiT3Y2Q1YyMWcyU1hvd2JnT3F6QnlINTFVVFI2T2JIaUdqMGtTQ0FMRzE0SVFQa3pRUGlTcGp1Kys5TTJqQWpQTTNvNDIxWk9VRE1QMjQ2Q3NxUFhyVEFiUFhKVlVSL2dpNHU1M2ttekMyMTBqdlZxOWhId2VseFFPVFBGaGxNNkUxQ2g0SmI0UFFSTEtEUEZsKzVOVzRGeTJKQURqeXVweVZIbmNkTEV1UHkwUGdDTDJZbzE0N0hTcFBqNHU3amMxUm1IVTdOTzEyRVYyWkNNZkZsUndkR3Y2aWY4cU83cy82bHBaSmpwUHRMRU9iQTV0RDRhaGMrYVBOQWk5V0NrMHBlUm0xS0U1VkdEV0tGTlNOQWlMSk56UDdtMlE2eThmT3kzOGNOZ0ZCaEdPRi9LZ0VJc1QxMFYrNUs1byt5bFZWdFBWZVJSRU5FdktPOUVMa3plMElIZ3NUQi82Y3dPaWo0cHhNOUp2YXVqMDZHZ2xoSWhpSUE2cTBpRFVxQjFNVVIwSHppWTlCc25XWTlrUjhod1YzT1crbnNtenRRd0dWRXcya2pVPSIsIk1JSUZqakNDQTNhZ0F3SUJBZ0lVRmo5LzNqR09SaHRJcFo5OE9MUnRSSHMwQVlzd0RRWUpLb1pJaHZjTkFRRUxCUUF3UVRFZE1Cc0dBMVVFQXd3VVpVbEVRVk5sVTBWQlRFOUpSRjlTYjI5MFJ6SXhFekFSQmdOVkJBb1RDbWxUU0VGU1JWUmxjM1F4Q3pBSkJnTlZCQVlUQWxoWU1CNFhEVEl6TURneU5UQTVNREEwTkZvWERUUTRNRGd5TlRBNU1EQXdOVm93UWpFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlUZFdKRFFVY3pNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQ0NBaUl3RFFZSktvWklodmNOQVFFQkJRQURnZ0lQQURDQ0Fnb0NnZ0lCQUw3bnpreW9GWFdnMWdoZEc2Zm51enV2QWRNV3NtL0krbVgzRGJ6M0kvS3lxTGRXdDdYRzNPV1ZTbmhvc0FEMlcyU1hubEdYcXh5ZTBoUHRFZ2tRSWRlbDdGbkZvc1dXcnNFT3JhdGdYbG5NNE5XcFlES01XRVZZcm83aHpIZ0NaMTI2WlBRVUxsczUyTmN2cFJNOFMzZFprK1hLMWtmM1ZlUzBKMmhVU0ZFQVpITHlYQ1hraFRuVUk3cW8xdXIxVG1EV1lzTlF3eERHT3U3Q1F5WllkS0l3S3FJOWVHc1JMZ002UFFsZzN2WkNyb3BPb2RNN2xvVHVpckNsM1VLdzRIckdrMmNPaUFmNElkLy9lYVZDYWZ3a2pLc0pUUXVBYWh1Uno0cU1zSFlBM2tEUXorMCtoZ25SNzRyK2lMcis4bHIwNDRnbG5hV0lXdnJFR2NpUlIrUGVjdGZyTE9RUUlXN2hhMTNkeldvemtUMGFnblQxTGsvQ0dyZ05YVnFob3NHQzBydUFRUEk2RGNQTnkySU5NOUpndENtQnNTak1NMTg1RklCWDRDeTE3bTczaDlyS2pYWk14YjZUeFg3Q0laeWVzZ0FTMGJCUmI2eElwS3NacmxyakVhenNqQzJWSFJSV09NSldZcWNYTEQ1Wk56R01aVXI2VHQyeUNVQXRhbWVjREFUS042L0dic3hlMHRBQk4wcGswcng1aWMrNFRYZEJyb045T0FaY2hINHRKQ3NPQ0tvbkN6QXBQeFZUaEROTXhzb295RnE5RG1nWGh5RVVPT29lUytGcjRGZ0gralNBTm0vbDE3OEpoOWVwZlhROWdFLzZhcVB4WWpOU0JnUzYwUzFFVnFDcHh3MnJUMW1VWWVHZndpYlZtNTNpeEdwdFI4a3RlNzBuQWdNQkFBR2pmVEI3TUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SHdZRFZSMGpCQmd3Rm9BVTJMdWJOUzFiUCsvaGE4dk1ETStpTHJwcGVvd3dHQVlEVlIwZ0JCRXdEekFGQmdOVkhTQXdCZ1lFVlIwZ0FEQWRCZ05WSFE0RUZnUVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3RGdZRFZSMFBBUUgvQkFRREFnRUdNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUI4anFZVXc3VHYrVzRaSDA2UHJhRjZ6ZmRDeFQwM0RoUkNodzRaL1FtMFhWUzJnUnlSd2NNcHRRRkVSaFBOT0EyMjF1OUxxb3paMWFLM0IzNXdrY0dEL2RGSmdKQ0pCOTZTTXR0UWwySHAvRWlRejlQRkYwMmRCU3J1WGhJYXJhUGJNK05JR2RteU4yWnl3R0dYSTFhVTdKRDNYRzI5U2gyQUFkT2t2OGRJNmdFZ3p0L0RIU0lJYmFrYmFMZEVJYzdXQjk1R1VIY0huTmo1OFR6VFN5VmZCbXRiM3ZCSzlKRzBJbzZOQVBXUVl4MlZQOCtmSXlsamEyZDEyOGhnaDBkc0RyWEZBTSs5QVg4aGFlNXZ2eFZpOFRXcy96MmluZytrK2ltbXRTTmZ6ektNaU83cjV3SkFreWp3dFVCbEJTdEtJQTZaZXIyMnBtU1RaWmV1Y0hkRVRoYWJjV1FpZFZabU1QM0lmNml4NVVleVg4VjZPQXcwZ3NJM0lVYjkxUTc2ZDRzTFdiem9HTk9OQVlGQzFJeXoweFdqNDdaZDZQN1oyR2ZoMVZpSWJNeFZpRkRsTm1iRVpmbHBFUzg3Sy95aEJVUS90bkNOR1FvU2R0c3V5dVdnM05mV2J5Sm9OWnpsVTk2Sld4Y3FTYVhrenNlOWo4d2FoYXlLTk02U1dLU1kxWjA1aDhKU2NPQ21GQjVGOFYzYmQ1blAvdUtqYTdIOE80R09BQVBNM090RytlcTM3eFcveE4wb0FzamJ2dDRvam5VYkpzMmtpQXhFZHdYeDBLN21jUGVTN3pXbVZ0OGg0UmRjRG0vUEdURGE5bThPcWhRdWNrODBRbnV4SVVXVnI3R1dhZGgxTHkvdGwwK2J2bWtjbk8yeWJSSitnYnFSRUhEVGUwc3hzdz09IiwiTUlJRmN6Q0NBMXVnQXdJQkFnSVVDdmZTdlFlcmpGRG1NMkx2bWpvVERPSW5MQXd3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQXdObG9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUlJQ0lqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FnOEFNSUlDQ2dLQ0FnRUF4Vk1LSTlSTWhuT1NBMkxvcmdFQzNZRE5kMml0bjcyTE9kZlJSVXU0NWZHNzBJZXYrRTRrUnJ6SjFrMjNXWEg1c0hUYmNzbHBFVGVBWm5qMC94S0JZZEVMdXdlNkhYOGtJd2QxczZXR2xaYzBsN2tpMWZtajRIcVNzdEdKL0JLR2oxYTcyMzZXd1BKRVdFSHFmeDlRTUVldUpLbFVTVkZGeUU0ak1zZllwODdpZklwdXdFOG9MT3c0eWtERE9QNTJUZDA2dkhDSVlycURCcnZ4RmRBdUVuRnhOeGxQWFJFNGdMc3lnZzYySE94T3VHbWhXZnN5NlRjY0lwNVhJT2RqMkN6ZW9YSjgybTUvaW1CUEp2a2VmbnJqRVFYemlTRTJtaTJJQkR0R1AvQXdGV0k3V3BzRXlEWFdJbU1TUjBUM0N1RG1rZVExNHBObWNxTXAvYnFYM2kxYWV0YWRGVFdzdWhsMG5IMmlScUtaREp4WmxTY3U5OXRvcTVHcmRjRlVjeEdSUXlsK3NGaFVoM1hjQldKVjdZMnduRkwydFk3dGh0UThaUG16VE84a1BLQ2JFbDVVNmdDU0lrcFJQTlpCUEc0ZFQwcXUrOEJkNzFQdTduQXkxaUI0VTZ5czM0Y0ZsT2xKcEdNMEZHcjM1TGVmYlBSOGJnejZNOVhOalJiZ01EUWNYRE1uZmlESjdFODFvVkJwQ1hOOXlkSGkxYmxoYWt1RUJhb2E5TS9rYXppcEdQbUF1eHJXQk1tcDJxMHd6UXA5R1MyZThrZUpJRHdKdXl6RUxhUlpDNHlqVnNWWlFNSy8vRCs0SjNib1U1ZHJDbW1tNkMxcndOUmZTWnVGR05jSVlEWmVIdGVHb0NGNEVBNWpjZ2RGYUlZckRlajZWQWFiNDJ2TjVMVUNBd0VBQWFOak1HRXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QWZCZ05WSFNNRUdEQVdnQlRZdTVzMUxWcy83K0ZyeTh3TXo2SXV1bWw2akRBZEJnTlZIUTRFRmdRVTJMdWJOUzFiUCsvaGE4dk1ETStpTHJwcGVvd3dEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQmJjSHlWMmI1bUd3SFd4Q1NiRHdyNVY3UGdTWklKYTFzY3JDbklIRDNaL3l4RzdYcDVjSWxCajRNeTRsUkhqWnRKVnZVZlRqRnBzRURFdi9QQXE3NE9Jb2xOL2tQZE1mVGN6RkJHcHZzWnIweDJ5VVBFSnpRc1RTTHgwZ3daK3d2b0tIV0UwQzdHcWdrQUJOckZXOEZMcVJ6TnFYc21NNW9JNGMzVjVzeXh3QllGRFVZNU1QV2RxSkVEZlJ2ampKUENYbUtPUDFsTytpK0UwN3ZzRnBEekhTMkZLQjVjNnNUSVprdnQrSC9DRzRoVnU2WnZjRlhYenYySksvRW9WWjZ3VWRDbHQ0cExnVFFaL1cwcVFDSjNHakZlL1BaNzRtY2tXMXgvems5ejBWUWpVcFRxejNBalBMSWpqNjBuTUxUTHA1MG9GY01ManVYc3MwdnY0dFVqQ1RwczJRZzluMEd3TGxEUjQyTnl3MlRLY01NQjZ5Y0VvTmlVRXUwbGdhMUpNMFNWU3NGUDdHU1UvVzlWcWF0Szd4cC9YVzkvR0R2Z3AzWi9wUE0wRTNpMXRxcC9uT1U0M1lvZjhXaTRKSjZ6T2dYQnpxUXhPNk1JTFpKNHFFZmVuQXRJN285NVR5NXlrOXZSYm9Vc3R5d3NmQzZDVnN1MDhOTC90dHc0T1NYT3Zia1ErN3pNeENZVDlZeVFENWwvbHRDM2JnZGovbEJaem5zQnVHWU5PQjE2d0ROY0dwdXVhZWtzZlFmQkRQSFQrdlI2Z1BWRlpweVZ3eS90ekg2TlRwVUdEam9IVnNDeFVqWTg3ME9NNEQySmNqOU9JcXFkbGtDb1dPNmk0VmVjN3NUenhpWDM5b05TcjFHN0NvYmMzc1lkaG54Zy92bGcxQmVDSjg3cDBBPT0iXX0.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDA0Iiwic3ViIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwNCIsImp0aSI6IjdmYTFlYzM5YmFjMzRmZmZhMmNhNDgyMDFlNDhmMDNhIiwiaWF0IjoxNzExNDY2OTg1LCJleHAiOjE3MTE0NjcwMTUsImF1ZCI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDEiLCJkZWxlZ2F0aW9uRXZpZGVuY2UiOnsibm90QmVmb3JlIjoxNTQxMDU4OTM5LCJub3RPbk9yQWZ0ZXIiOjIxNDc0ODM2NDcsInBvbGljeUlzc3VlciI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDUiLCJ0YXJnZXQiOnsiYWNjZXNzU3ViamVjdCI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDEifSwicG9saWN5U2V0cyI6W3sibWF4RGVsZWdhdGlvbkRlcHRoIjowLCJ0YXJnZXQiOnsiZW52aXJvbm1lbnQiOnsibGljZW5zZXMiOlsiSVNIQVJFLjAwMDEiXX19LCJwb2xpY2llcyI6W3sidGFyZ2V0Ijp7InJlc291cmNlIjp7InR5cGUiOiJHUzEuQ09OVEFJTkVSIiwiaWRlbnRpZmllcnMiOlsiMTgwNjIxLkFCQzEyMzQiXSwiYXR0cmlidXRlcyI6WyJHUzEuQ09OVEFJTkVSLkFUVFJJQlVURS5FVEEiXX0sImVudmlyb25tZW50Ijp7InNlcnZpY2VQcm92aWRlcnMiOlsiZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMyJdfSwiYWN0aW9ucyI6WyJJU0hBUkUuUkVBRCJdfSwicnVsZXMiOlt7ImVmZmVjdCI6IlBlcm1pdCJ9XX1dfV19fQ.dNiITX_uHj3CJagOm54W-_MD2PXIsh1snviAtuoRbc7a7nRkQXZShJJDpldpyQOugsqFFhgLedUXM5z8kST0-5a9BNaaxrW5KAZNqyXtDgudRgB8T2vrohcmgLin39pgvD1gydoHHIXolJxPHCOYdxAamMD-8umvTzCFogjdwFaB9RMVWUHMbDuAZGYup-lSewuIK2pkwKJZft5ZRWxfignBBt2mauB4wot5Z92VLPReNA8EH0R9C_GkykP6pRCu2Km7La3c116WNP0szN02l8P87rqVNwDsjLpzhpH1cs17shDvbis8DbKb3KsHnq_LALAG9nx4GOFrupxuAadhGw" } ``` After decoding, the example content of the JWT looks like this: ```json { "iss": "did:ishare:EU.NL.NTRNL-10000004", "sub": "did:ishare:EU.NL.NTRNL-10000004", "jti": "7fa1ec39bac34fffa2ca48201e48f03a", "iat": 1711466985, "exp": 1711467015, "aud": "did:ishare:EU.NL.NTRNL-10000001", "delegationEvidence": { "notBefore": 1541058939, "notOnOrAfter": 2147483647, "policyIssuer": "did:ishare:EU.NL.NTRNL-10000005", "target": { "accessSubject": "did:ishare:EU.NL.NTRNL-10000001" }, "policySets": [ { "maxDelegationDepth": 0, "target": { "environment": { "licenses": [ "https://licenses.ishare.eu/general-unrestricted/1.0" ] } }, "policies": [ { "target": { "resource": { "type": "GS1.CONTAINER", "identifiers": [ "180621.ABC1234" ], "attributes": [ "GS1.CONTAINER.ATTRIBUTE.ETA" ] }, "actions": [ "ISHARE.READ" ] }, "rules": [ { "effect": "Permit", "conditions": { "anyOf": [ { "leftOperand": "serviceProvider", "operator": "equal", "rightOperand": "did:ishare:EU.NL.NTRNL-10000003" }, { "leftOperand": "serviceProvider", "operator": "equal", "rightOperand": "did:ishare:EU.NL.NTRNL-10000002" } ] } } ] } ] } ] } } ``` # Delegation Policy The Delegation Policy Request endpoint is an API endpoint that can be used to request the creation of a delegation policy. {% hint style="info" %} The `POST` request to `/delegationPolicy` is an **OPTIONAL** endpoint. For more information on **OPTIONAL** specifications, see [functional requirements per role.](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role) {% endhint %} ### Request #### Headers * `Authorization`\ **String**. (Required)\ OAuth 2.0 authorisation based on a bearer token. MUST contain “Bearer “ + access token value. How to retrieve the access token can be found in the [Access Token Endpoint section](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/all-roles-common-endpoints/access-token-m2m%20\(1\).md). * `Content-Type`\ **String**.\ Defines the request body content type. MUST be equal to *application/json*. #### Parameters The body of the request contains [iSHARE Compliant JWT](/reference/ishare-jwt) delegationPolicyRequestToken. Besides the default attributes (iss, sub, aud, etc.), it contains the following attributes. The model of the delegation PolicyRequestToken [is available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=2.2#/jwtPayloadDelegationPolicyRequestToken). For convenience, the model is also described below. * `delegationPolicyRequest`\ **Object**. Root level. (Required)\ Contains information about the delegation policy that is requested to create. * `notBefore`\ **Integer**. Contained in `delegationPolicyRequest`. (Required)\ Unix timestamp indicating the start of the validity period of the requested delegation policy. * `notOnOrAfter`\ **Integer**. Contained in `delegationPolicyRequest`.\ Unix timestamp indicating the end of the validity period of the requested delegation policy. * `policyRequestor`\ **String**. Contained in `delegationPolicyRequest`. (Required)\ Identifier of the party to which the right is delegated. * `policyIssuer`\ **String**. Contained in `delegationPolicyRequest`. (Required)\ Identifier of the delegator, also known as the delegating entity. * `target`\ **Object**. Contained in `delegationPolicyRequest`. (Required)\ MUST for the root level contain an accessSubject. No other elements are allowed. It makes the entire requested delegation policy applicable only to this accessSubject. * `accessSubject`\ **Object**. Contained in `target`. (Required)\ The identifier of the delegate, also known as the entity that receives the delegated rights. It should be a party identifier for M2M cases or a human pseudonym for H2M cases. This would usually hold the same value as policyRequestor. * `policySets`\ **Array of Objects**. Contained in `delegationPolicyRequest`. (Required)\ A container for one or more objects containing policy elements with an indication for further delegation. Note that policySet elements within one delegationPolicyRequest MUST not restrict each other, but rather offer a mechanism to express additional rights. They will be evaluated by the Authorisation Registry in a *permit-override* manner, allowing a *Permit* if only one of the policySet elements evaluates to *Permit*. * `maxDelegationDepth`\ **Integer**. Contained in `policySets`. *Optional*.\ An optional element that, if present, indicates that further delegation of the rights, conveyed in the policy elements that are part of this PolicySet, is allowed. The value indicates the delegation steps that are allowed after this step in order to evaluate the entire delegation path to *Permit*. * `target` **Object**. Contained in `policySets`. *Optional.* Contains `environment`. * `environment` **Object**. Contained in `target`. *Optional.* Contains `licenses`. * `licenses` **Array of Strings and Objects**. Contained in `environment`. An array which describes which iSHARE licenses apply to this policy set. Please refer to the[Licenses model](/licenses-model) for more information about structuring this array. * `policies` **Array of Objects**. Contained in `policySets`. (Required) Used to express the actual rights for which evidence is being provided. Note that policies within one policySet object MUST not restrict each other, but rather offer a mechanism to express additional rights. They will be evaluated in a *permit-override* manner, allowing a *Permit* if only one of the policy elements evaluates to *Permit*. * `target`\ **Object**. Contained in `policies`. (Required)\ Describes the target, in terms of resource and action, this request applies. It is also the scope that is permitted through the default rule. * `resource`\ **Object**. Contained in `target`. (Required)\ Contains `type`, `identifiers` and `attributes`. * `type`\ **String**. Contained in `resource`. (Required)\ String which describes the type of resource to which the rules apply. * `identifiers`\ **Array of Strings**. Contained in `resource`. *Optional*.\ Optional array of strings containing one or more resource identifiers. * `attributes`\ **Array of Strings**. Contained in `resource`. *Optional*.\ An optional array of attributes of the resources the delegated rights apply to. * `actions`\ **Array of Strings**. Contained in `target`. (Required)\ An array of actions that apply to this policy. * `context`\ **Object**. Contained in `target`. *Optional.*\ Object containing context information that must be evaluated by the Authorisation Registry before providing Delegation Evidence. * `conditions`\ **Object**. Contained in `context`. *Optional.*\ Optional conditions which must be evaluated by the Authorisation Registry. For guidance on how to interoperably define conditions, refer to the page about [delegation evidence conditions](/reference/delegation-conditions). The condition structure is the same as the structure when conditions are part of the rules that are provided to the Service Provider/Consumer ([Delegation conditions](/reference/delegation-conditions#type-2-evaluate-conditions-by-the-service-provider)). When Delegation Evidence is requested by the Service Provider/Consumer ([Delegation conditions](/reference/delegation-conditions#type-1-conditions-evaluated-by-an-authorisation-registry)), it is expected that the context contains key/value pairs on which these conditions must be applied. The following keywords in conditions are reserved: * `serviceProviders`: reserved keyword for a condition that contains a list of party identifiers of Service Providers, which are allowed to provide services to the accessSubject. * `rules`\ **Array of Objects**. Contained in `policies`. (Required) * `effect`\ **String**. Contained in `rules`. (Required)\ Value must be equal to *Permit* or *Deny*. * `conditions`\ **Object**. Contained in `rules`. *Optional.*\ Optional conditions which must be evaluated by the Service Provider before the rule applies. The conditions must be provided as-is to the Service Provider. For guidance on how to interoperably define conditions, refer to the page about [delegation evidence conditions](/reference/delegation-conditions) ([Delegation conditions](/reference/delegation-conditions#type-2-evaluate-conditions-by-the-service-provider)). The following keywords in conditions are reserved: * `serviceProviders`: reserved keyword for a condition that contains a list of party identifiers of Service Providers, which are allowed to provide services to the accessSubject. ### Response **HTTP status codes** * **200 OK** When the creation of the delegation policy was successful, an OK result should be returned. # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} As issuer of Data Rights Credentials, the Authorisation Registry is recommended: * Not to provide long-lived Data Rights Credentials * Or maintain a list of provided credentials, so the credentials may be revoked If conditions change, or an Entitled Party decides that data access must be revoked, after issuing a Data Rights Credential, not following these recommendations may result in unwanted data access. Be aware that a large volume of recorded long-lived credentials may lead to a long list of credentials that may be revoked. The following endpoints must be provided if the DCP protocol is supported by the Authorisation Registry: * [Credential storage (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-storage-dcp) * [Credential issuance (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-issuance-dcp) * [Credential status (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-status-dcp) * [Metadata (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/metadata-dcp) * [Offers (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/offers-dcp) * [Resolution (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/resolution-dcp) # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VC**: * **OpenID4VCI**: Credential Issuance endpoints * **OpenID4VP**: Credential Presentation endpoints # OpenID4VCI Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VCI protocol is supported by the Authorisation Registry: * [Credential Issuer Metadata (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-issuer-metadata-openid4vci) * [Token Endpoint (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/token-endpoint-openid4vci) * [Credential Endpoint (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-endpoint-openid4vci) # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VP protocol is supported by the Authorisation Registry: * [Verifier Metadata (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp) * [Authorization Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/authorization-endpoint-openid4vp) * [Presentation Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/presentation-endpoint-openid4vp) # Getting started The Entitled Party is the legal person that holds one or more legitimate rights regarding access to, use of, or control over data and/or data services provided by a Service Provider (role) with which it has a legal agreement. This may include: * The right to access or consume a data service (e.g. retrieve or send data) * The right to exercise legal or contractual control over the data itself (e.g. data ownership, stewardship, or regulatory responsibility) The Entitled Party, Service Consumer and Service Provider roles can be fulfilled by the same entity, i.e. a legal entity that consumes a service based on its own entitlements to this service (for example, a trucking company's entitlement to request Estimated Time of Arrival and optimal route information), but this is not necessary. Entities entitled to a service can delegate others to consume it on their behalf. In such cases, the consuming entity operates based on another entity’s entitlements. In these cases, the Service Consumer uses a Service Provider’s service based on the Entitled Party’s entitlements, but the role of Service Consumer is performed by a different entity than the Entitled Party. The Entitled Party may make the Authorisation Registry discoverable for each capability in its /capabilities endpoint or in general or for specific dataspaces in the Participant Registry. (See [*Discovering Authorisation Registry*](/reference/authorization#discovering-authorisation-rules)*).* # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the DCP protocol is supported by the Entitled Party (usually by applying wallet technology): * [Credential storage (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-storage-dcp) * [Offers (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/offers-dcp) * [Resolution (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/resolution-dcp) {% hint style="info" %} **Note** These endpoints are expected from the Credential Store (wallets) provider for entitled parties that do not wish to have their own implementations {% endhint %} # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VP.** # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VP protocol is supported by the Entitled Party: * [Presentation Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/presentation-endpoint-openid4vp) # Getting started The Identity Provider role is fulfilled by a legal entity whose tooling identifies and authenticates entities (humans or machines). An Identity Provider: * Provides identifiers for humans; * Issues credentials (i.e. a password or electronic keycard) to humans; * Identifies humans to Service Providers based on this information. * Holds information on authorisations of humans representing a Service Consumer; i.e. information indicating which humans are authorised to act on a Service Consumer's behalf. * If a human is authorised to represent multiple Service Consumers, the Identity Provider is expected to provide a list from which the human must select the Service Consumer it wants to represent. * Can check whether a human representing a legal entity is authorised to receive the service; * Can confirm this authorisation to the Service Provider. As a result, Service Providers can outsource the identification and authentication of humans, as well as tasks related to managing the authorisations and delegation information of humans, to an Identity Provider instead of implementing their own tooling. The iSHARE specifications do not include requirements for user logout. Identity Providers may provide a logout mechanism that Service Providers can trigger when a users requests to logout from the Service Provider, for example with OpenID Connect RP-Initiated logout. To double-check if required endpoints are implemented, please use the following list as a cheat sheet: Identity Provider * [ ] [Access Token (M2M)](/all-roles-common-endpoints/access-token-m2m) * [ ] [Capabilities](/all-roles-common-endpoints/capabilities) * [ ] [Authorize](/identity-provider/authorize) * [ ] [Login](/identity-provider/login) * [ ] [Access Token (H2M)](/identity-provider/access-token) * [ ] [User Info](/identity-provider/user-info) # Authorise {% hint style="info" %} The ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} {% hint style="info" %} **Note** Since the [request object](https://dev.ishare.eu/identity-provider/authorize.html#refauthorizerequestobject) is too large for GET requests, only the POST method should be supported. {% endhint %} {% hint style="info" %} **Note** According to [RFC 6749](https://tools.ietf.org/html/rfc6749), scopes are case-sensitive. {% endhint %} ### Request #### Request Parameter JWT This parameter is an iSHARE-compliant[ JWT](/reference/ishare-jwt), with additional parameters within this token. The `request` JWT contains the modified `sub` parameter and the following additional parameters: * `sub`\ **String**.\ This parameter overrides the iSHARE-compliant JWT payload. A URN specifying the subject for this authorisation request. Since the ID or pseudonym of the user is not known upfront, the *urn: TBD* value should be used (TBD means To Be Determined). In response, a pseudonym of the user MUST be returned by the Identity Provider. * `response_type`\ **String**. (Required)\ OAuth 2.0 Response Type. To use the Authorisation Code Flow in iSHARE, a value *code* is REQUIRED. MUST be identical to the response\_type value in the body parameter of the /authorise request. * `client_id`\ **String**. (Required)\ OpenID Connect 1.0 client ID. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain a valid iSHARE identifier. MUST be identical to the client\_id value in the body parameter of the /authorise request. * `scope`\ **String**. (Required)\ OAuth 2.0 scope for OpenID Connect 1.0. The *scope* parameter MUST contain at least the *openid* and the *iSHARE* scope values. In addition to that, it MAY also contain one or more scopes identifying the attributes from the Human Service Consumer that are requested (depending on the OpenID implementation of the Identity Provider). The *iSHARE* scope contains the minimal information required for authorisations. The *scope* parameter MUST be identical to the scope value in the body parameter of the /authorise request. MUST be identical to the scope value in the body parameter of the /authorise request. * `redirect_uri`\ **String**.\ OpenID Connect 1.0 redirection URI to which the response will be sent. Note that by transporting the redirect\_uri in a signed and encrypted JWT, security considerations regarding un-pre-registered redirect\_uris are properly addressed. * `state`\ **String**.\ OpenID Connect 1.0 opaque value used to maintain state between the request and the callback. The client application needs to verify if the sent value is equal to the value which comes back from the IdP /authorise endpoint response. * `nonce`\ **String**.\ OpenID Connect 1.0 value used to associate a client session with an ID Token. The client application needs to verify if the sent value is equal to the value which comes back from the IdP /token endpoint response. * `acr_values`\ **String**.\ OpenID Connect 1.0 authentication context class reference value. Space-separated string that specifies the ACR values that the Identity Provider is being requested to use for processing this request, with the values appearing in order of preference. MUST either contain *urn:*, *urn:* or *urn:*, depending on the quality of the authentication method. To understand authentication requirements for each level of assurance, please look at the [LOA table](#levels-of-assurance). * `language`\ **String**. *Optional*.\ iSHARE specific two-letter indicator (ISO 639-1 Code) that guides the language of the user interface shown by the Identity Broker or Identity Provider. If provided, must display the login page according to the provided language; else should display the default page. **Example** ```json { "iss": "did:ishare:EU.NL.NTRLNL-10000003", "sub": "urn:TBD", "aud": "did:ishare:EU.NL.NTRLNL-10000006", "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", "iat": 1504683445, "exp": 1504683475, "response_type": "code", "client_id": "did:ishare:EU.NL.NTRLNL-10000003", "scope": "openid ishare name contact_details", "redirect_uri": "https://example.client.com/openid_connect1.0/return", "state": "af0ifjsldkj", "nonce": "c428224ca5a", "acr_values": "urn:http://eidas.europa.eu/LoA/NotNotified/high", "language": "nl" } ``` #### **Levels of Assurance** | **Level of Assurance** | **Authentication assurance** | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Low |
  • Single factor, e.g. username and password
| | Substantial |
  • Multi-factor, e.g. mobile phone + PIN
| | High |
  • Multi-factor, e.g. mobile phone + PIN
  • Must access private data/keys stored on tamper-resistant hardware token
  • Cryptographic protection of personally identifying information (PII)
| #### Example {% hint style="success" %} **Tip** `request` The parameter is encrypted, so you won’t be able to inspect its payload. However, if you’d like to see the JWT payload, please refer to the [section](/reference/ishare-jwt#jwt-payload). {% endhint %} ```json > Content-Type: application/x-www-form-urlencoded POST /connect/authorise response_type=code& client_id=did:ishare:EU.NL.NTRLNL0123456789 scope=iSHARE openid& request=eyJ0eXAiOiJKV1QiLCJ4NWMiOlsiTUlJRWdUQ0NBbW1nQXdJQkFnSUlOOVZpQ0RpM0J3c3dEUVlKS29aSWh2Y05BUUVMQlFBd1NERVpNQmNHQTFVRUF3d1FhVk5JUVZKRlZHVnpkRU5CWDFSTVV6RU5NQXNHQTFVRUN3d0VWR1Z6ZERFUE1BMEdBMVVFQ2d3R2FWTklRVkpGTVFzd0NRWURWUVFHRXdKT1REQWVGdzB4T1RBeU1UVXhNVFEyTVRWYUZ3MHlNVEF5TVRReE1UUTJNVFZhTUVJeEZUQVRCZ05WQkFNTURFRkNReUJVY25WamEybHVaekVjTUJvR0ExVUVCUk1UUlZVdVJVOVNTUzVPVERBd01EQXdNREF3TVRFTE1Ba0dBMVVFQmhNQ1Rrd3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDME80aFVoRCtWb09LVklaU05NTlRmemMwTzJrWWorWnpwUUVBQlpHdFB0eTBrS1BKZXAwK281eHN0b3UxSytVeHZIZnhFcEh4SEdUZHRxWnVjMjhMaFU0Q2VDZ29lRE1EVCtDSFMzTm9zaUVTUU13aC9aWmVUYzkvZUtDbzU2OUdDbisyWHRUaUdTcEJTd01TV3FOSGdwQVpZS2RIclQva0VNSXlUS29hdXVpS1E4Y1VwN293N21aei85SytxVjNzOUwwMzBXOElhd0xKQkpLLzJhcEF0NWpoMWo0L21GN2YwcTh6aHpockM4djAxUExsWmR1VHpqakJyZTdteit5aS92bFl6L2VhcDBlWVRqaHhJYXR5VjlGRndsbWk0RkMxQ05jTXRMaDhuc2lKb2U1Y0JtMTNMS2JRRnUzR1lINzZvZUxadldxYlBicDExbXhsSGEvS2RBZ01CQUFHamRUQnpNQXdHQTFVZEV3RUIvd1FDTUFBd0h3WURWUjBqQkJnd0ZvQVVGanpuSU9uV2xPOGY1YUx4dVB5KzZ0OHNONEV3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVIQXdFd0hRWURWUjBPQkJZRUZBUEgrOFVyWWlWTFhhS1BSR2Zsa0ErY3VzUTdNQTRHQTFVZER3RUIvd1FFQXdJRm9EQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FnRUFZbDV0V0gwWXRZUzlKeXF5bFpKV29tQTU1U2hLbGxhQlJjdnJvNkNIeGxsSldIbzBxQzlaVE1jdkN5d012MTRWSnlRZDZlRlpxY1Z0T2x1R3JSWkJrbEg5QWFua292cDJKTGFxY0Q3OXQxQ3l1WFpuSXpURmwvQmtNc0U2d2xBSlhZL3Nhcm5veGVpZWpQNEUvRWYvMGV1SUZ2QmFJQ0NGK0tkMldKWWJibjBXeTBkSDQ4NFFKYkh5TXRWZnI0Mm9JcFVOVnVMU3U4NHlLWUFlbTlKQnVZVHAzWTBLMmhpRUFXL2JPS0R2dkhldFZmNWZ1NjZ5ZmVrRFg1M2ozTktpRkpDWFMycktJWm9EdU1GdXhwU3lWa1Mya2JXazErNUpveTdxT1NOQU5SRlBscEhjZ3pMUVpwOEhyZ3Zoc21oSXQxVlRWWWt5eGNkOHFYQWxod3FWZ09xNU5nTHhrcXVsOWhOTUdpTTdzcStINzNRL0ZpOGlmN2dQOElWQVN6UUd3dUhnMlo4N2liNkEydm9uMGZSSlpxM2ZJdWJIb3hJNjNBVHdmY1JLODZ5MTcyeGJGRTNWVTBkdU4xdEk1WjBUQ2cwR0FKWXRKcGJudmV4SXQ1bGs1RklrNFRodlIwTDhtTkx5MURVYTExTitFTXhrcWJmcWxUdXJCOFpnM0NZL1FhU0ttWFk1Q01Vd1dlRUJYUkhoeWZrWlE1alBQVUhyRmFveU9SWDhwMUVyWURrdEIxSzlvNGptdUVWcEIzM2N2Z1lCRWlBeVY1ejQ0MjZGdVZDTWJIYUZEVjdpS1c5ZUJsWG94ZVpvNFhYOCtqWHlTTDVHVzhYd05SVEs1YzR2VzAyUTNWSnlZVmU1dW1lc3RzS1ErTFI4aUF6b1VTcmVLMTgrSmtBakFKVT0iXX0.eyJpc3MiOiJFVS5FT1JJLk5MMDAwMDAwMDAxIiwic3ViIjoidXJuOlRCRCIsImF1ZCI6IkVVLkVPUkkuTkwwMDAwMDAwMDAiLCJqdGkiOiJicXEwem5rY2RvQ3BjRWdRbXNuUEQyYnh3MWJoa0ZVViIsImlhdCI6MTYwMTM3Mjg2MCwiZXhwIjoxNjAxMzcyODkwLCJyZXNwb25zZV90eXBlIjoiY29kZSIsImNsaWVudF9pZCI6IkVVLkVPUkkuTkwwMDAwMDAwMDEiLCJzY29wZSI6ImlTSEFSRSBvcGVuaWQiLCJyZWRpcmVjdF91cmkiOiJodHRwczovL2V4YW1wbGUuY2xpZW50LmNvbS9vcGVuaWRfY29ubmVjdDEuMC9yZXR1cm4iLCJzdGF0ZSI6IjBGcnF5Mzlja3NmNHZaSFk0RHluRHpYQmtBVmdNbFJ5Iiwibm9uY2UiOiJlYlFqVTc1Vkl4cVczM3RITkZmRmlLbVJHUDZFMlZjNCIsImFjcl92YWx1ZXMiOiJ1cm46aHR0cDovL2VpZGFzLmV1cm9wYS5ldS9Mb0EvTm90Tm90aWZpZWQvbG93IiwibGFuZ3VhZ2UiOiJubCJ9.ZXlKcGMzTWlPaUpGVlM1RlQxSkpMazVNTURBd01EQXdNREF4SWl3aWMzVmlJam9pZFhKdU9sUkNSQ0lzSW1GMVpDSTZJa1ZWTGtWUFVra3VUa3d3TURBd01EQXdNREFpTENKcWRHa2lPaUppY1hFd2VtNXJZMlJ2UTNCalJXZFJiWE51VUVReVluaDNNV0pvYTBaVlZpSXNJbWxoZENJNk1UWXdNVE0zTWpnMk1Dd2laWGh3SWpveE5qQXhNemN5T0Rrd0xDSnlaWE53YjI1elpWOTBlWEJsSWpvaVkyOWtaU0lzSW1Oc2FXVnVkRjlwWkNJNklrVlZMa1ZQVWtrdVRrd3dNREF3TURBd01ERWlMQ0p6WTI5d1pTSTZJbWxUU0VGU1JTQnZjR1Z1YVdRaUxDSnlaV1JwY21WamRGOTFjbWtpT2lKb2RIUndjem92TDJWNFlXMXdiR1V1WTJ4cFpXNTBMbU52YlM5dmNHVnVhV1JmWTI5dWJtVmpkREV1TUM5eVpYUjFjbTRpTENKemRHRjBaU0k2SWpCR2NuRjVNemxqYTNObU5IWmFTRmswUkhsdVJIcFlRbXRCVm1kTmJGSjVJaXdpYm05dVkyVWlPaUpsWWxGcVZUYzFWa2w0Y1Zjek0zUklUa1ptUm1sTGJWSkhVRFpGTWxaak5DSXNJbUZqY2w5MllXeDFaWE1pT2lKMWNtNDZhSFIwY0RvdkwyVnBaR0Z6TG1WMWNtOXdZUzVsZFM5TWIwRXZUbTkwVG05MGFXWnBaV1F2Ykc5M0lpd2liR0Z1WjNWaFoyVWlPaUp1YkNKOQ ``` (URL encoding removed, and line breaks added for readability) ### Response #### HTTP status codes #### 302 Found * When a valid request is sent, a redirection should happen to the [Identity Provider’s login page](/identity-provider/login) to allow the user to authenticate themselves. * When an invalid request is sent, a redirection should happen to the Identity Provider’s error page. Redirection should not be made to a URI which was provided in a request JWT payload redirect\_uri parameter due to potential security risks. To learn more, please read the [OAuth 2.0 Security: OAuth Open Redirector section 2](https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-00#section-2). #### Parameters * `returnUrl`\ On a successful request, a redirection to the login should happen. Once the user has logged in, a [callback to authorise](#callback) endpoint needs to be done in order to issue a *code* to the Service Provider. This parameter value should be an encoded URL to the callback endpoint. {% hint style="warning" %} **Warning** Authorise callback endpoint usually requires the same parameters that were sent towards the authorise endpoint in order to identify which request was. Signed and encrypted JWT is too long and *MUST NOT* be included in `returnUrl`. {% endhint %} #### 302 Found Example ``` < Location: https://identity-provider/login? returnUrl=https://identity-provider/connect/authorize/callback?authzId=MDK9NtaDCdas75LKQjggWpM8 ``` (URL encoding removed, and line break added for readability) ### Callback On successful login callback towards the authorise endpoint is invoked. It’s out of iSHARE’s scope to document the Identity Provider’s internal functionality. However, there are still a few requirements because the [Service Provider’s return endpoint](/service-provider-role/return) expects a specific call. On successful callback, Identity Provider should redirect the user to the URI which was provided in the request JWT payload redirect\_uri parameter with added query parameters that are defined in a section below. #### Parameters * `code`\ An authorisation code, which is going to be used to request an [access token](/identity-provider/access-token). The authorisation code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorisation code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorisation code more than once. If an authorisation code is used more than once, the authorisation server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorisation code. The authorisation code is bound to the client identifier and redirection URI. * `state`\ OpenID Connect 1.0 opaque value used to maintain state between the request and the callback. The client application needs to verify if the sent value is equal to this returned value. #### 302 Found Example ```json < Location: https://example.client.com/openid_connect1.0/return? code=Dmn-TbSj7OcKl5ym1j5xZsgkabzVP8dMugC81nzmeW4& state=ZqVQm4zHaEDyBhzpm1ZRH7fsxy703lq2 ``` # Login {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ## Allow Conformance Test Tool (CTT) to login > The /login endpoint is required in order to pass Conformance Test Tool (CTT). The endpoint allows user to authenticate himself using username and password. After successful authentication if user grants permit to requested scopes redirection to Service Provider should happen. ```json {"openapi":"3.0.0","info":{"title":"iSHARE API specifications","version":"3.0"},"tags":[{"name":"Identity Provider (Required)","description":"Required endpoints for the iSHARE Identity Provider API."}],"servers":[{"description":"iSHARE UAT network base domain","url":"https://isharetest.net"},{"description":"iSHARE TEST network base domain","url":"https://test.ishareworks.nl"}],"paths":{"/login":{"post":{"requestBody":{"content":{"application/x-www-form-urlencoded":{"schema":{"required":["username","password"],"type":"object","properties":{"username":{"description":"Human user’s login name. Could be email, mobile phone number, nickname etc.","type":"string"},"password":{"description":"Human user’s password."}}}}},"required":true},"tags":["Identity Provider (Required)"],"parameters":[{"$ref":"#/components/parameters/content-type_form"}],"responses":{"200":{"description":"Login was successful and single page application will be responsible for redirection to returnUrl parameter."},"302":{"description":"Login was successful and back-end application redirects user to returnUrl parameter by itself."},"401":{"description":"authentication is required and has failed or has not yet been provided."}},"deprecated":false,"operationId":"authenticate-user-login","summary":"Allow Conformance Test Tool (CTT) to login","description":"The /login endpoint is required in order to pass Conformance Test Tool (CTT). The endpoint allows user to authenticate himself using username and password. After successful authentication if user grants permit to requested scopes redirection to Service Provider should happen."}}},"components":{"parameters":{"content-type_form":{"deprecated":false,"name":"Content-Type","description":"Defines request body content type. MUST be equal to application/x-www-form-urlencoded.","schema":{"type":"string"},"in":"header","required":true}}}} ``` {% hint style="info" %} CTT is going to use a low level of assurance because passing login when 2FA is enabled would be infeasible. Production environment should be way more secure, and traditional authentication using credentials could be even disabled if there is a need to use more secure ways of logging in, like biometrics, ID card logins, etc. {% endhint %} {% hint style="info" %} It is not mandatory to have the same parameter names because CTT supports any parameter names for credentials. {% endhint %} {% hint style="info" %} iSHARE documentation does not cover login failures because it’s only within the Identity Providers' scope. {% endhint %} # Access token {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} OpenID Connect endpoint for obtaining the OAuth access token and OpenID Connect ID token. Response contains, besides the OAuth access token, also an iSHARE-compliant JWT `id_token`. ### Request #### HTTP methods * POST #### Headers * `Content-Type` **String**. Defines the request body content type. MUST be equal to *application/x-www-form-urlencoded*. #### Parameters * `grant_type` **String**. OAuth 2.0 grant type. MUST be equal to *authorization\_code* because the code which was retrieved from the authorise[ endpoint](/identity-provider/authorize) will be used. * `client_id` **String**. OpenID Connect 1.0 client ID. This parameter represents the iSHARE identifier of the Service Provider, so "id" must be used. * `client_assertion_type` **String**. OpenID Connect 1.0 client assertion type. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST be qual to *urn:ietf:params:oauth:client-assertion-type:jwt-bearer*. * `client_assertion` **String (JWT)**. OpenID Connect 1.0 client assertion. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain [JWT token conforming to iSHARE specifications](/reference/ishare-jwt), signed by the client. * `redirect_uri` **String**. Redirect URI which was used in the authorisation OAuth request. * `code` **String**. OAuth 2.0 authorisation code. MUST be equal to a value of authorisation code which was received from the Identity Provider or Identity Broker in response to the /authorise request. #### Example ``` > Content-Type: application/x-www-form-urlencoded POST /connect/token grant_type=authorization_code& client_id=did:ishare:EU.NL.NTRLNL-100000001 client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHaURDQ0JIQ2dBd0lCQWdJVVJNSUwrb21nNnY1cFU2cUZPTUZjZUcxWWpEQXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRRMU5ERmFGdzB5TnpFeE1EWXhORFExTkRCYU1HWXhDekFKQmdOVkJBWVRBazVNTVI0d0hBWURWUVFLREJWVVpYTjBJRk5sY25acFkyVWdRMjl1YzNWdFpYSXhIakFjQmdOVkJBTU1GVlJsYzNRZ1UyVnlkbWxqWlNCRGIyNXpkVzFsY2pFWE1CVUdBMVVFWVF3T1RsUlNUa3d0TVRBd01EQXdNREV3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRRFlTS092bUI2VXhFYVlPUFQ3QVBnVTRtYXVTaDl2YlBhY0p0TTNhNGNkek44S2lwcGpvV1NiZ3I2SmI0RmM3dEd2Tms2bnZXWkhsSHpBREZlMGFRSUdsOElEaHVxMUJoWEpUeEhaNGtydy82QUViQy9HUmNndEpkY2FubGMzV2tNNXJNRXNvRFJkOGdPdk5Ubkw3bTUyRElXYjNSUzhiQ2l0Vkg2cW4zaG9XU3dYOVhlZVU2SnJHdTFrcDZsZlQxOXUxekpLWnVCYUIwSWE0dXptTStRU2Qxa1U2UGVDWFErdHJFZlZVUWtQOGcvcnpaR25TSDh1N05xaXd3VWZGU2lhVXlxOVA0SXArSzBKQlR0QXVROXhwUTZ3UXh0MGlvRk5GYjlpcG1jM3h4ZWtvd01SeWtaekVkb0hPL3luWTNXNHNiVFNsMmVONEVtZkh6UUdSTEpMQWdNQkFBR2pnZ0kxTUlJQ01UQU9CZ05WSFE4QkFmOEVCQU1DQmtBd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JTekdrOUNRT25ZZUoxci8vd2tzQkN4TkR6d2lUQlhCZ2dyQmdFRkJRY0JBUVJMTUVrd1J3WUlLd1lCQlFVSE1BR0dPMmgwZEhCek9pOHZZMkUzTG1semFHRnlaWFJsYzNRdWJtVjBPamcwTkRJdlpXcGlZMkV2Y0hWaWJHbGpkMlZpTDNOMFlYUjFjeTl2WTNOd01CQUdBMVVkSUFRSk1BY3dCUVlEVlIwZ01COEdBMVVkSlFRWU1CWUdDQ3NHQVFVRkJ3TUVCZ29yQmdFRUFZSTNDZ01NTUZzR0NDc0dBUVVGQndFREJFOHdUVEFUQmdZRUFJNUdBUVl3Q1FZSEJBQ09SZ0VHQWpBMkJnZ3JCZ0VGQlFjQkF3d3FWR2hwY3lCcGN5QjBaWE4wSUdWelpXRnNJR05sY25ScFptbGpZWFJsSUdadmNpQjBaWE4wYVc1bk1CNEdCV2VCREFNQkJCVXdFeE1EVGxSU0V3Sk9UQXdJTVRBd01EQXdNREV3Z2NjR0ExVWRId1NCdnpDQnZEQ0J1YUNCdHFDQnM0YUJzR2gwZEhCek9pOHZZMkUzTG1semFHRnlaWFJsYzNRdWJtVjBPamcwTkRJdlpXcGlZMkV2Y0hWaWJHbGpkMlZpTDNkbFltUnBjM1F2WTJWeWRHUnBjM1EvWTIxa1BXTnliQ1pwYzNOMVpYSTlRMDRsTTBSbFNVUkJVMlZUUlVGTVQwbEVYMGx6YzBOQlJ6UWxNa052Y21kaGJtbDZZWFJwYjI1SlpHVnVkR2xtYVdWeUpUTkVUbFJTVGt3dGFWTklRVkpGVkVWVFZDVXlRMDhsTTBScFUwaEJVa1ZVWlhOMEpUSkRReVV6UkZoWU1CMEdBMVVkRGdRV0JCUmR5VU5QaXdlMldwcnd6WWd2eVorNmZDMW9OREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBc1hackZHNWFqc0ZOZ1RmbG5iVGZENmFML1cwTzl1eXdRN1ZUVHVyWkhib0hUeERJSUwzR3E5VmovZDB2cEpKZ3JmeXNuUi9NQkhDOWZYb25WOVd1d1NLaG85MW1IcXVVYzd5dGx5RndvQU41Uk9WSVIxUkJoVW9zTUcwSmdUdzVQZ1c5eFhCb2dBWis3RUZEaU03MEJKVXIrb2pxbFoyeVlTMzI0SURDcGdGZTl5U1hpbnpUZzgrZDNqQnNRTEUwSVhuUi8rZE5OdGhIaEFsMUhMZmw2d1o5UmJQcFpncDBBZUNjZEtibjFJZlV6ZVBZTW5SeXVEalJnbm1RWVZZRDMxUWE2OGd4NVlzMXFiL2ZZd1NTcGVFUjBaZjA2UzBleFBVWVNodE93UmxZcWlhMno4TGdONFR1cmR3Y0RjVGlqbWVrRTkrL29TU0lUZWhGcm9BMmVITHNxWXRlOGpRZ0ZCUEVjeTJzeUZ3MVZGRHFUYS9HbkpKa29GQ2Y4alBubG5BSEVGSm1raEFaM3hlUDFEYWczMENQK2FvQ1FWTnlraE81WjczVjZCcE5oZHBnYVlYNEIvUVJlUFVocVVvWWJITGVmQWx5TzdTRlJhaHljVytvNjZLNUd1ZXB0Z3RRMkRycmp2Q3RhQ0c4RXRKY3ppaEFqQk4wT1Fac1FXblU4dm9vTHNzK1JtZmc5TVhUUjhrODVjWVQ5Wk1kVS80NnpsZ0FNSWFKaXp2OGo0ZUhhS2dmUkJCMWd3NzFvVzk3b1c1UUtReDg2MVVyUjF1MERKbVNRU1V3Tllsb3BLVlJuSHZYSldVSXJlT3FMZlNTQi8xdVZRZnZxMFV6c0pLZGVPQ0tSTHBYWGd4QjN3N1MyKzVLRkVUUzd0Y2JaNm1JeFpsSmxoMFZSU3M9IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAxIiwic3ViIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMSIsImF1ZCI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDYiLCJqdGkiOiJkeGhKQW1CSEJSeElza2dvVnZCTUpVN1M2MFZxMUVFSCIsImlhdCI6MTU4ODU5NzU1NiwiZXhwIjoxNTg4NTk3NTg2fQ.PHht8pqK-c4lFg5xT2qI8vRAyVBlMUkmfdigQj3czxQEntrmaYcMfHpNghtMTYx_-fVNMRS6CjPxb7IvAYAXNHpuzT30ye42dm4wqNz3gJoDdhY4OB96is70E-WftTp-TQLYoKZG95ezRVp_iwB70MTkl31RnsNS10bP4yKDtvYtzltoFvjORDxAw1kWJnMv8mZlD3iRUo98UCqTHwsXVOSJUHt8pb9-2tsQQUl7oAqKuYzcwqSt6BZYujIOrm8iQ6p7RORqeF7esoGL8-HwvJdWf2Qxgjvc-LQ4FPtiJWJ-d2jnZN8smpZC5EY5VCPLqX6_dH4l05Zl5HPlm4UsFg redirect_uri=https://example.client.com/openid_connect1.0/return& code=Dmn-TbSj7OcKl5ym1j5xZsgkabzVP8dMugC81nzmeW4 ``` (URL encoding removed, and line breaks added for readability) ### Response #### Headers * `Content-Type` **String**. Defines response body content type. MUST be equal to *application/json*. * `Cache-Control` **String**. Holds instructions for caching. MUST be equal to *no-store*. * `Pragma` **String**. It is used for backwards compatibility with HTTP/1.0 caches, where the `Cache-Control` The HTTP/1.1 header is not yet present. MUST be equal to *no-cache*. #### HTTP status codes * **200 OK** When a valid request is sent, an OK result should be returned. * **400 Bad Request** When an invalid request is sent, a Bad Request result should be returned. #### Parameters * `id_token` **String (JWT)** ID Token value associated with the authenticated session. To understand its structure, please refer to the [section below](#id-token-parameter-jwt). * `access_token` **String**. The access token will be used to access endpoints that require authorisation. * `token_type` **String**. Since we follow the OpenID Connect 1.0 specification, which is on top of the OAuth 2.0 specification, the value should be equal to *Bearer*. * `expires_in` **Integer**. Access token expiration time in seconds. Should be *3600*. #### ID Token Parameter JWT In response to the */token* endpoint request, an `id_token` is provided to the client (as an addition to the regular OAuth access token response). This `id_token` is an iSHARE-compliant JWT; however, the `sub` parameter is changed, and additional parameters are added. The `id_token` contains the modified `sub` parameter and the following additional parameters: * `sub` **String**. OpenID Connect 1.0 locally unique and never reassigned identifier within the Identity Provider for the Human Service Consumer, which is intended to be consumed by the client. Also known as the iSHARE human pseudonym. To understand more about this value, please refer to the [human pseudonym section](#human-pseudonym). * `auth_time` **String**. OpenID Connect 1.0 time when the Human Service Consumer authentication occurred. Formatted in Unix timestamp format. * `nonce` **String**. OpenID Connect 1.0 value used to associate a client session with an ID Token. Contains value as passed in to the /openid\_connect1.0/authorise endpoint. The client application needs to verify if the sent value is equal to the value which comes back from the IdP /token endpoint response. * `acr` **String**. OpenID Connect 1.0 authentication context class reference value. MUST either contain *urn:*, *urn:* or *urn:*, depending on the quality of the authentication method. To understand the requirements for each level of assurance, please look at the [LOA table](#levels-of-assurance). * `azp` **String**. *Optional*. OpenID Connect 1.0 authorised party. MUST be identical to the client\_id that requested the ID Token. Also identical to aud. * `organisationIdentifier` **String**. (Required) Identifier of the organisation that the authenticated user is representing. This value **MUST** be an ETSI/X.509 OrganizationIdentifier (OID 2.5.4.97) issued by a Trust Service Provider (TSP), using the format defined in [ETSI EN 319 412-1 V1.5.1, clause 5.1.4:](https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.05.01_60/en_31941201v010501p.pdf)`<3-letter type><2-letter country>-` **Example** ```json { "iss": "did:ishare:EU.NL.NTRLNL-87654321", "sub": "419404e1-07ce-4d80-9e8a-eca94vde0003de", "aud": "did:ishare:EU.NL.NTRLNL-12345678", "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", "iat": 1504683445, "exp": 1504683475, "auth_time": 1504683435, "nonce": "c428224ca5a", "acr": "urn:http://eidas.europa.eu/LoA/NotNotified/low", "azp": "did:ishare:EU.NL.NTRLNL-12345678", "organisationIdentifier": "VATBE-590082394654" } ``` #### **Levels of Assurance** |

Level of

Assurance

| **Identity assurance** | | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Low |
  • Present ID from authoritative source
| | Substantial |
  • Present ID from authoritative source
  • ID verification performed by registration authority
| | High |
  • In-person ID proofing at registration authority
  • ID verification using official government sources and documents
| ### **Human Pseudonym** An essential part of the Human2Machine flow is the pseudonym used to refer to humans without exposing their identity. Pseudonyms are used to obscure the real identities of the human users for privacy issues. A human user may be representing more than one organization, which the service provider may not need to know about. If such user uses a single identity then he could be unwillingly giving away this possibly sensitive information. Using pseudonyms, the user’s identities are not easily linked to each other. On the other hand, some use cases may require the user’s identities to be linkable to service the user better. In this case the use of pseudonym makes sense as a user could always link them together on his own will. The following is a list of criteria for generating pseudonyms: * The generation of a pseudonym MUST be non predictable; * The exact method of generating the pseudonym is left out to Identity Providers; * The Identity Provider MUST be able to identify the human user from the pseudonym; * The pseudonym MUST depend on the human user; * The pseudonym MUST depend on the Identity Provider; * The pseudonym MUST depend on the Service Provider. {% hint style="info" %} One of the approaches to solve this issue could be a storage with user’s identifier, service provider’s identifier and UUID/GUID assigned for the combination which in this case would be called *human pseudonym*. {% endhint %} #### 200 OK Example ```json < Content-Type: application/json < Cache-Control: no-store < Pragma: no-cache { "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHaWpDQ0JIS2dBd0lCQWdJVUFRY2VVOGN2OVNBWWRJUUJXMks1YXdPRGRzY3dEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRRek1qVmFGdzB5TnpFeE1EWXhORFF6TWpSYU1HZ3hDekFKQmdOVkJBWVRBazVNTVI4d0hRWURWUVFLREJaVVpYTjBJRWxrWlc1MGFYUjVJRkJ5YjNacFpHVnlNUjh3SFFZRFZRUUREQlpVWlhOMElFbGtaVzUwYVhSNUlGQnliM1pwWkdWeU1SY3dGUVlEVlFSaERBNU9WRkpPVEMweE1EQXdNREF3TmpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTXBCc3A1eUV4Y3NabUI5cGRCR1FKeWJEMWVzZFBnY3ZURk96V1RGNTM2aTcrQ1puTjFVNVdGTFlROFV3MHJjMkxRU0JMZ016ZWtQd3lGcVFWdjY2V01WNFhmYzFSK1IzbW40OFJCbGMweEQxU1VYWnBKZGRqbFd1NUhQWmVwYTZ0RnJwMGFOSzlHRy9ML0VNejBROExOSzdPUEszdGlXSXlaSkR5WHJSaFZJaWVPVkRmbnMrb3RZeE9ZLzJJek43REJsT1BaSHpnUEh5OGJiVlJnQ0E1TVozNW1oV2F4ejhNOEx5OE1OakFnaE85S3FjcjlLcjRKWjVOK1IveVE1OFFqWEZaaytRV0JNbEZELzBveGE2cnZ2dytvT0ViMHFMSW9UKzhvVGVWZmNpNWhpYm5aeUh0N1RRV29NbmlmNDkyQnlGZmhMc2hSYmZXZFVGVEE3KzRjQ0F3RUFBYU9DQWpVd2dnSXhNQTRHQTFVZER3RUIvd1FFQXdJR1FEQU1CZ05WSFJNQkFmOEVBakFBTUI4R0ExVWRJd1FZTUJhQUZMTWFUMEpBNmRoNG5Xdi8vQ1N3RUxFMFBQQ0pNRmNHQ0NzR0FRVUZCd0VCQkVzd1NUQkhCZ2dyQmdFRkJRY3dBWVk3YUhSMGNITTZMeTlqWVRjdWFYTm9ZWEpsZEdWemRDNXVaWFE2T0RRME1pOWxhbUpqWVM5d2RXSnNhV04zWldJdmMzUmhkSFZ6TDI5amMzQXdFQVlEVlIwZ0JBa3dCekFGQmdOVkhTQXdId1lEVlIwbEJCZ3dGZ1lJS3dZQkJRVUhBd1FHQ2lzR0FRUUJnamNLQXd3d1d3WUlLd1lCQlFVSEFRTUVUekJOTUJNR0JnUUFqa1lCQmpBSkJnY0VBSTVHQVFZQ01EWUdDQ3NHQVFVRkJ3RUREQ3BVYUdseklHbHpJSFJsYzNRZ1pYTmxZV3dnWTJWeWRHbG1hV05oZEdVZ1ptOXlJSFJsYzNScGJtY3dIZ1lGWjRFTUF3RUVGVEFURXdOT1ZGSVRBazVNREFneE1EQXdNREF3TmpDQnh3WURWUjBmQklHL01JRzhNSUc1b0lHMm9JR3pob0d3YUhSMGNITTZMeTlqWVRjdWFYTm9ZWEpsZEdWemRDNXVaWFE2T0RRME1pOWxhbUpqWVM5d2RXSnNhV04zWldJdmQyVmlaR2x6ZEM5alpYSjBaR2x6ZEQ5amJXUTlZM0pzSm1semMzVmxjajFEVGlVelJHVkpSRUZUWlZORlFVeFBTVVJmU1hOelEwRkhOQ1V5UTI5eVoyRnVhWHBoZEdsdmJrbGtaVzUwYVdacFpYSWxNMFJPVkZKT1RDMXBVMGhCVWtWVVJWTlVKVEpEVHlVelJHbFRTRUZTUlZSbGMzUWxNa05ESlRORVdGZ3dIUVlEVlIwT0JCWUVGQkFyazlNZHhQVFh4NEYrZ3orTzZZdGNDVmhiTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFDL1FPWmY5UGN0dG82cXgwMEQ1WTBFVDVGRU9mUzc3RzYvVTQ5bmJnTm9vVnlHMlY2N0lHOHNJNHozbXU0ZC9NbWdKbjJBWG81eWhONERhaStkakZmbHpXYVpmRjFneXo3V28zZmlrOHl6UjBxaUZCZWNxK2tIN09FMkFmS0lQWnNhTGFBenI4UWNZQmFKSUJ0SWx6N284dlpiL2VidnF5ZlRsb1pab2h1TEpMcjVUTUUwKzRKQWlueGgzaU44cHpxb3piVFdQMXNKdnMzdWxKUVA2eTFsNi9zbXJucnJEV2RHMjhBTVFRMEtaTjN3cHRVYUhpTnR5REd1Y1JmTVpPY0JzVGMrYXIrWmlGd09ZaE9BNGpYbzdsYVZaS0ZoZHE0eEZCdjczZkJTcTE0N2Z1VEMwSUZIVlprOVE4bzFUWjV5T1Fmc2lhcEVGKzlNU3ZoWWZWU0FzeUplZjgySnpNc2tDZ2R5eHMvWjdqa3ZPcWVkNGRWQUxlbDRDc3hUajducjB4bktZVXphOWdQWDlJOHpYOGtxYzdJRWRlNkcrNy9xb09YaVVwWHBiMzZRQ081ei8rK1FJS1pVNWF1dTNDUTZndE5kUGpwckN5SHNKNmg2MW9oRUwrc0JFOC8xMmhnTXViVFNMWjMvVDlIT0xvYTZLZjJ6dmZwQ0d5eHFpdXFPY3c4NVV3TGhiOEdodUNmWXJJQzlLR2pIZmliQXJEQXZYeERvLzg5RU5VKzI4K213NEJvNHRmcjdGQktDY0ZCVkhNeHRBdUtSMlJoY0dRZlJPNTluQ2lVM1FuQ1JIQldGeVp4bXNpQXExazJiSnRIRHpLNDFDSm1wSVBEdUUvVEVvazN6SUtya1E0UUlaNXoyaEhlcHptWGhHRkc0QVdpei9iSUdlOGY5bmc9PSIsIk1JSUYyakNDQThLZ0F3SUJBZ0lVUEczK1RBbnhWT0JjZTlOYVB0OXBUQWdtNVI0d0RRWUpLb1pJaHZjTkFRRUxCUUF3UWpFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlUZFdKRFFVY3pNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQWVGdzB5TXpBNE1qVXdPVEF4TXpKYUZ3MDBPREE0TWpVd09UQXdNRFZhTUYweEhqQWNCZ05WQkFNTUZXVkpSRUZUWlZORlFVeFBTVVJmU1hOelEwRkhOREVaTUJjR0ExVUVZUk1RVGxSU1Rrd3RhVk5JUVZKRlZFVlRWREVUTUJFR0ExVUVDaE1LYVZOSVFWSkZWR1Z6ZERFTE1Ba0dBMVVFQmhNQ1dGZ3dnZ0lpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElDRHdBd2dnSUtBb0lDQVFEYW5VZ00xL1BReVhOVFgrVU9MR3JaalM4SGFUV1IvUDR4RDhTTUNSeE9YSEt6SExRcUVRT3VIRC93K3J4OS9iRXd6SDR3VmZKMG02L3I1NktPZzB3TFVsVndPeWlrT1hHb0lURDJ1K1VpOXQyNHRZSWt4OHpqTEc3VkhWY3c0ZFhPdDkyc3ZLWTFMeWJ2bHByb1d6VEhsUndvSU8xWVE0aE8rcnlic3cvS0VERVhVYmtvd2psSEFQY3duc09XNjQzNjdFTitlelQxc1M4ZHpGSXhtRzhxQzJMck0yc1hKV3FxNXZKZUUvODZUZloyTk1PK0NVeGtqajd1UGdiVzJWL01PVWhZeUF0R0FqemQvS3dPckxNUk1ZYVhPSWo2MW04UjcxbmgvTFY5bjhkbmowd1RRT05USGh1TTdtZFpReGhxT2RrTDJja1NyQldpM2F0RVZUMU9oQlJYNEZtbWhJaG1TV3VDdGd5S2lEQ0lvdHlHQXNYMm82ODE3ZmVlNFJkdHdmdzlRNG9OM05BaHRvZDYwaU9BV0FwVnQrQlQ1dHZkZ0dPWVdQY2JNUjVwR3picDM4ZEdVeXV3WVpWNExBbklHU201eWF1Y05FMkUyeHJRQ2JFZVptNFJQc3g1SmxlV3ppcGsrNDJkN3ZxdldEODhJUWNRK2JaTTJYNHJKQlpOczE2NkNseCttNkhtS3hLQUxlYlV0anN6c2d5SDhjcTEwZCtrNEFvOG9DYU9ZanYySWFFYk1kK2ZWL1VmOGtQa3pUdEtsdHRkcWlpeG9JcXljWE1FZ0JhU2drdWI3WG9RNksyNnRSUEowdzVRa3V1aDNNS3RHRVdmVzdFRUdtcG5DcWpPdjYvckFNSmlNV3loMUlnTGdOQlVQUDd6YVZQcERBdEM4OE9TSlFJREFRQUJvNEdzTUlHcE1CSUdBMVVkRXdFQi93UUlNQVlCQWY4Q0FRRXdId1lEVlIwakJCZ3dGb0FVNHViWDBwNkRWak45REt0T1dXTVlBcytIeGRRd0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBcEJnTlZIU1VFSWpBZ0JnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3SFFZRFZSME9CQllFRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1BNEdBMVVkRHdFQi93UUVBd0lCQmpBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQWdFQVp2NUd1a3gwUEV2VlJFSXQ4TVRhUGZDSDRhd3lpaVl5aTE3aDZSNUxMazFyZXJ3UXNTU1NIZlZxZnRkd1JGMG9jTHAyUFhKaGUwNzVxVjQwNkMwNENqYW1OazNlejlaaU5IQ05qUHRmaWQ2b094cXoxWGs4WFBqTllFbGJBRm1QN2VLbC80NDF2WmhHdWsvUmhYR054UWJ0bzBRMTZnOElSY0dEdldnTmh0cnRCMUcyeFNtdEIxUzJ1VXBTYWlaVk5PcmtkelRoaUVKc2VVUkJvWHhVWElxcEx5UFRSbDZNTWdWYUxHUllSYzN2WWlqNEI3TTJoQk43L2NqbkdMc01WdGdiT3Y2Q1YyMWcyU1hvd2JnT3F6QnlINTFVVFI2T2JIaUdqMGtTQ0FMRzE0SVFQa3pRUGlTcGp1Kys5TTJqQWpQTTNvNDIxWk9VRE1QMjQ2Q3NxUFhyVEFiUFhKVlVSL2dpNHU1M2ttekMyMTBqdlZxOWhId2VseFFPVFBGaGxNNkUxQ2g0SmI0UFFSTEtEUEZsKzVOVzRGeTJKQURqeXVweVZIbmNkTEV1UHkwUGdDTDJZbzE0N0hTcFBqNHU3amMxUm1IVTdOTzEyRVYyWkNNZkZsUndkR3Y2aWY4cU83cy82bHBaSmpwUHRMRU9iQTV0RDRhaGMrYVBOQWk5V0NrMHBlUm0xS0U1VkdEV0tGTlNOQWlMSk56UDdtMlE2eThmT3kzOGNOZ0ZCaEdPRi9LZ0VJc1QxMFYrNUs1byt5bFZWdFBWZVJSRU5FdktPOUVMa3plMElIZ3NUQi82Y3dPaWo0cHhNOUp2YXVqMDZHZ2xoSWhpSUE2cTBpRFVxQjFNVVIwSHppWTlCc25XWTlrUjhod1YzT1crbnNtenRRd0dWRXcya2pVPSIsIk1JSUZqakNDQTNhZ0F3SUJBZ0lVRmo5LzNqR09SaHRJcFo5OE9MUnRSSHMwQVlzd0RRWUpLb1pJaHZjTkFRRUxCUUF3UVRFZE1Cc0dBMVVFQXd3VVpVbEVRVk5sVTBWQlRFOUpSRjlTYjI5MFJ6SXhFekFSQmdOVkJBb1RDbWxUU0VGU1JWUmxjM1F4Q3pBSkJnTlZCQVlUQWxoWU1CNFhEVEl6TURneU5UQTVNREEwTkZvWERUUTRNRGd5TlRBNU1EQXdOVm93UWpFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlUZFdKRFFVY3pNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQ0NBaUl3RFFZSktvWklodmNOQVFFQkJRQURnZ0lQQURDQ0Fnb0NnZ0lCQUw3bnpreW9GWFdnMWdoZEc2Zm51enV2QWRNV3NtL0krbVgzRGJ6M0kvS3lxTGRXdDdYRzNPV1ZTbmhvc0FEMlcyU1hubEdYcXh5ZTBoUHRFZ2tRSWRlbDdGbkZvc1dXcnNFT3JhdGdYbG5NNE5XcFlES01XRVZZcm83aHpIZ0NaMTI2WlBRVUxsczUyTmN2cFJNOFMzZFprK1hLMWtmM1ZlUzBKMmhVU0ZFQVpITHlYQ1hraFRuVUk3cW8xdXIxVG1EV1lzTlF3eERHT3U3Q1F5WllkS0l3S3FJOWVHc1JMZ002UFFsZzN2WkNyb3BPb2RNN2xvVHVpckNsM1VLdzRIckdrMmNPaUFmNElkLy9lYVZDYWZ3a2pLc0pUUXVBYWh1Uno0cU1zSFlBM2tEUXorMCtoZ25SNzRyK2lMcis4bHIwNDRnbG5hV0lXdnJFR2NpUlIrUGVjdGZyTE9RUUlXN2hhMTNkeldvemtUMGFnblQxTGsvQ0dyZ05YVnFob3NHQzBydUFRUEk2RGNQTnkySU5NOUpndENtQnNTak1NMTg1RklCWDRDeTE3bTczaDlyS2pYWk14YjZUeFg3Q0laeWVzZ0FTMGJCUmI2eElwS3NacmxyakVhenNqQzJWSFJSV09NSldZcWNYTEQ1Wk56R01aVXI2VHQyeUNVQXRhbWVjREFUS042L0dic3hlMHRBQk4wcGswcng1aWMrNFRYZEJyb045T0FaY2hINHRKQ3NPQ0tvbkN6QXBQeFZUaEROTXhzb295RnE5RG1nWGh5RVVPT29lUytGcjRGZ0gralNBTm0vbDE3OEpoOWVwZlhROWdFLzZhcVB4WWpOU0JnUzYwUzFFVnFDcHh3MnJUMW1VWWVHZndpYlZtNTNpeEdwdFI4a3RlNzBuQWdNQkFBR2pmVEI3TUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SHdZRFZSMGpCQmd3Rm9BVTJMdWJOUzFiUCsvaGE4dk1ETStpTHJwcGVvd3dHQVlEVlIwZ0JCRXdEekFGQmdOVkhTQXdCZ1lFVlIwZ0FEQWRCZ05WSFE0RUZnUVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3RGdZRFZSMFBBUUgvQkFRREFnRUdNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUI4anFZVXc3VHYrVzRaSDA2UHJhRjZ6ZmRDeFQwM0RoUkNodzRaL1FtMFhWUzJnUnlSd2NNcHRRRkVSaFBOT0EyMjF1OUxxb3paMWFLM0IzNXdrY0dEL2RGSmdKQ0pCOTZTTXR0UWwySHAvRWlRejlQRkYwMmRCU3J1WGhJYXJhUGJNK05JR2RteU4yWnl3R0dYSTFhVTdKRDNYRzI5U2gyQUFkT2t2OGRJNmdFZ3p0L0RIU0lJYmFrYmFMZEVJYzdXQjk1R1VIY0huTmo1OFR6VFN5VmZCbXRiM3ZCSzlKRzBJbzZOQVBXUVl4MlZQOCtmSXlsamEyZDEyOGhnaDBkc0RyWEZBTSs5QVg4aGFlNXZ2eFZpOFRXcy96MmluZytrK2ltbXRTTmZ6ektNaU83cjV3SkFreWp3dFVCbEJTdEtJQTZaZXIyMnBtU1RaWmV1Y0hkRVRoYWJjV1FpZFZabU1QM0lmNml4NVVleVg4VjZPQXcwZ3NJM0lVYjkxUTc2ZDRzTFdiem9HTk9OQVlGQzFJeXoweFdqNDdaZDZQN1oyR2ZoMVZpSWJNeFZpRkRsTm1iRVpmbHBFUzg3Sy95aEJVUS90bkNOR1FvU2R0c3V5dVdnM05mV2J5Sm9OWnpsVTk2Sld4Y3FTYVhrenNlOWo4d2FoYXlLTk02U1dLU1kxWjA1aDhKU2NPQ21GQjVGOFYzYmQ1blAvdUtqYTdIOE80R09BQVBNM090RytlcTM3eFcveE4wb0FzamJ2dDRvam5VYkpzMmtpQXhFZHdYeDBLN21jUGVTN3pXbVZ0OGg0UmRjRG0vUEdURGE5bThPcWhRdWNrODBRbnV4SVVXVnI3R1dhZGgxTHkvdGwwK2J2bWtjbk8yeWJSSitnYnFSRUhEVGUwc3hzdz09IiwiTUlJRmN6Q0NBMXVnQXdJQkFnSVVDdmZTdlFlcmpGRG1NMkx2bWpvVERPSW5MQXd3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQXdObG9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUlJQ0lqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FnOEFNSUlDQ2dLQ0FnRUF4Vk1LSTlSTWhuT1NBMkxvcmdFQzNZRE5kMml0bjcyTE9kZlJSVXU0NWZHNzBJZXYrRTRrUnJ6SjFrMjNXWEg1c0hUYmNzbHBFVGVBWm5qMC94S0JZZEVMdXdlNkhYOGtJd2QxczZXR2xaYzBsN2tpMWZtajRIcVNzdEdKL0JLR2oxYTcyMzZXd1BKRVdFSHFmeDlRTUVldUpLbFVTVkZGeUU0ak1zZllwODdpZklwdXdFOG9MT3c0eWtERE9QNTJUZDA2dkhDSVlycURCcnZ4RmRBdUVuRnhOeGxQWFJFNGdMc3lnZzYySE94T3VHbWhXZnN5NlRjY0lwNVhJT2RqMkN6ZW9YSjgybTUvaW1CUEp2a2VmbnJqRVFYemlTRTJtaTJJQkR0R1AvQXdGV0k3V3BzRXlEWFdJbU1TUjBUM0N1RG1rZVExNHBObWNxTXAvYnFYM2kxYWV0YWRGVFdzdWhsMG5IMmlScUtaREp4WmxTY3U5OXRvcTVHcmRjRlVjeEdSUXlsK3NGaFVoM1hjQldKVjdZMnduRkwydFk3dGh0UThaUG16VE84a1BLQ2JFbDVVNmdDU0lrcFJQTlpCUEc0ZFQwcXUrOEJkNzFQdTduQXkxaUI0VTZ5czM0Y0ZsT2xKcEdNMEZHcjM1TGVmYlBSOGJnejZNOVhOalJiZ01EUWNYRE1uZmlESjdFODFvVkJwQ1hOOXlkSGkxYmxoYWt1RUJhb2E5TS9rYXppcEdQbUF1eHJXQk1tcDJxMHd6UXA5R1MyZThrZUpJRHdKdXl6RUxhUlpDNHlqVnNWWlFNSy8vRCs0SjNib1U1ZHJDbW1tNkMxcndOUmZTWnVGR05jSVlEWmVIdGVHb0NGNEVBNWpjZ2RGYUlZckRlajZWQWFiNDJ2TjVMVUNBd0VBQWFOak1HRXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QWZCZ05WSFNNRUdEQVdnQlRZdTVzMUxWcy83K0ZyeTh3TXo2SXV1bWw2akRBZEJnTlZIUTRFRmdRVTJMdWJOUzFiUCsvaGE4dk1ETStpTHJwcGVvd3dEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQmJjSHlWMmI1bUd3SFd4Q1NiRHdyNVY3UGdTWklKYTFzY3JDbklIRDNaL3l4RzdYcDVjSWxCajRNeTRsUkhqWnRKVnZVZlRqRnBzRURFdi9QQXE3NE9Jb2xOL2tQZE1mVGN6RkJHcHZzWnIweDJ5VVBFSnpRc1RTTHgwZ3daK3d2b0tIV0UwQzdHcWdrQUJOckZXOEZMcVJ6TnFYc21NNW9JNGMzVjVzeXh3QllGRFVZNU1QV2RxSkVEZlJ2ampKUENYbUtPUDFsTytpK0UwN3ZzRnBEekhTMkZLQjVjNnNUSVprdnQrSC9DRzRoVnU2WnZjRlhYenYySksvRW9WWjZ3VWRDbHQ0cExnVFFaL1cwcVFDSjNHakZlL1BaNzRtY2tXMXgvems5ejBWUWpVcFRxejNBalBMSWpqNjBuTUxUTHA1MG9GY01ManVYc3MwdnY0dFVqQ1RwczJRZzluMEd3TGxEUjQyTnl3MlRLY01NQjZ5Y0VvTmlVRXUwbGdhMUpNMFNWU3NGUDdHU1UvVzlWcWF0Szd4cC9YVzkvR0R2Z3AzWi9wUE0wRTNpMXRxcC9uT1U0M1lvZjhXaTRKSjZ6T2dYQnpxUXhPNk1JTFpKNHFFZmVuQXRJN285NVR5NXlrOXZSYm9Vc3R5d3NmQzZDVnN1MDhOTC90dHc0T1NYT3Zia1ErN3pNeENZVDlZeVFENWwvbHRDM2JnZGovbEJaem5zQnVHWU5PQjE2d0ROY0dwdXVhZWtzZlFmQkRQSFQrdlI2Z1BWRlpweVZ3eS90ekg2TlRwVUdEam9IVnNDeFVqWTg3ME9NNEQySmNqOU9JcXFkbGtDb1dPNmk0VmVjN3NUenhpWDM5b05TcjFHN0NvYmMzc1lkaG54Zy92bGcxQmVDSjg3cDBBPT0iXX0.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDA2Iiwic3ViIjoiNDE5NDA0ZTEtMDdjZS00ZDgwLTllOGEtZWNhOTR2ZGUwMDAzZGUiLCJhdWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAxIiwianRpIjoiNzgyYmIzOWUtMjQ4YS00NzA4LWI2MmUtZWZiMDVmYzM2MDQyIiwiZXhwIjoiMTU4ODkyNjczMiIsImlhdCI6IjE1ODg5MjY3MDIiLCJhdXRoX3RpbWUiOiIxNTg4OTI2NzAyIiwibm9uY2UiOiJjNDI4MjI0Y2E1YSIsImFjciI6InVybjpodHRwOi8vZWlkYXMuZXVyb3BhLmV1L0xvQS9Ob3ROb3RpZmllZC9sb3ciLCJhenAiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAxIn0.jmw_q2n2aEfdVUJPB4-FF2uOTnHSycoecOqB59Pqf6KgMKwgZQ9N7cPBEGkZqspOnJqLfj9w9xIgJSWKcwUdv4OqWgGGCFqzupMOxGtGgNAC-tTzKFLuwgjUbO5BYizgNaz-qBhjAwBIwxhUQBWQ_Gwwz1HYhWSb-xBkllsRTGa2siO2ZGrJSD-bni339kWTv8Uf5eSK4q1gLiTfuvI1kYu2KD4laV33770TRpVSOzJsZOzlLYeSJXjNwOnsu4KmarOBupdgP3ZdPcqNm7wHTn7-OkqYMswM3mwbDNeGZopoQ2cl9ZNDxtb1JKtA73EoFDfdjQ53vLFGO_EU-ecDQQ", "access_token": "aW2ys9NGE8RjHPZ4mytQivkWJO5HGQCYJ7VyMBGGDLIOw", "expires_in": 3600, "token_type": "Bearer" } ``` # User info {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} OpenID Connect 1.0 endpoint for obtaining attributes of a Human Service Consumer conforming to the scope defined in the access token. ### Request #### HTTP methods * POST #### Parameters #### Example ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ < Content-Type: application/json; charset=UTF-8 POST /connect/userinfo ``` ### Response #### Headers * `Content-Type` **String**. Defines response body content type. MUST be equal to *application/jwt*. #### HTTP status codes * **200 OK** When a valid request is sent, an OK result should be returned. * **400 Bad Request** When an access token is valid, but the request itself is invalid. * **401 Unauthorized** When `Authorization` The header is either missing, invalid, or the token has already expired. #### Parameters Since response `Content-Type` is *application/jwt* it should be expected to retrieve a signed JWT. JWT should be [iSHARE compliant](/reference/ishare-jwt), and its payload should contain [delegation evidence](/authorisation-registry-role/delegation-endpoint#response-model). In addition, the JWT payload might also contain the following parameters: * `organisationIdentifier` **String**. (Required) Identifier of the organisation that the user is representing. **MUST** be ETSI/X.509 OrganizationIdentifier (OID 2.5.4.97) issued by a Trust Service Provider (TSP), using the format in ETSI EN 319 412-1 V1.5.1, clause 5.1.4:\ `<3-letter type><2-letter country>-` #### 200 OK Example ``` < Content-Type: application/jwt { UserinfoResponse: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlFNlRDQ0E5R2dBd0lCQWdJSVUrVkNVWmo1dCtBd0RRWUpLb1pJaHZjTkFRRUxCUUF3UERFNk1EZ0dBMVVFQXd3eFZFVlRWQ0JwVTBoQlVrVWdSVlVnU1hOemRXbHVaeUJEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVTQkhOVEFlRncweU16QTVNRGt4TWpBMk16RmFGdzB6TXpBNU1EWXhNakEyTXpCYU1IVXhHakFZQmdOVkJBTU1FV2xUU0VGU1JTQlVaWE4wSUZCSlVpQXhNUnd3R2dZRFZRUUZFeE5GVlM1RlQxSkpMazVNTURBd01EQXdNREF3TVJRd0VnWURWUVFMREF0VVpYTjBJR0Z1WkNCUlFURVdNQlFHQTFVRUNnd05hVk5JUVZKRlZHVnpkRkJKVWpFTE1Ba0dBMVVFQmhNQ1Rrd3dnZ0lpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElDRHdBd2dnSUtBb0lDQVFEQ1puQlVCM2s1R05sa0piVThIbFFhY2IxdnVScTN5UkRVZlQyUzFaSFBJVEJuWUFSQTZvMDdLNmxKZWpyRnQ1YWRsSzRsK3ZxTDFvaWlTeWdTREFLdCtXYkxpUzZFakFocFlIeTFBNWtkNVFONnFmUUpUNnI4cVZvUXdrNnM5bmdldkc2SGRIQW5qMlcvR1d1UGNicU9JaHYxSEdaYVhIUDZrNGo3QzBuT042U1NRSXhQQko4bnUvdTloaDJzS0JpN0ZzRkNnZFpxL29OQzBaZjR3R3pJbVRlc3hQMUJrTXlETmdXVVIzK1JpZUlNTXNNQlJXcEhLRFE0aTI0blJZaGhqUjJGU3NQcitiTE85YXRKWFVKc3I4bElhVDNDaDRVOUE5MnNYY1A4V3lvVjJ1Ti9hOEJBTjVJWkw1bVRBZXA4NDJROXQrS1ltcXEzY1J2a21zUUN3WmxUZm1ZNUMzbDhKOHpHYTNETTZxUTViOFlCalZoUUljcEFISDJqQ3RpRmQ2Vk9XMjl3MVg2MHhKRU14dHB1dmhVNGQzZXlveFRiLzVYU05vRVJOUERRZzRRN0NHQWQvR3ZsbFFka2wrdGJPQW9EclYwY01PZFJ4eVpqa25UZUpzcWNaOHJYZWVDQkFkOVFYZEd0cGl0SUFsNnRyRFYxbEd4TmpZVldSN3o1MEJRUEUvaGpFOFZBb3ZuemMvOWlSenQ1ZmhFQkljclVJRVpzcmdKVUg1NXY0SVA2T2JjRisxVjNFdHNqMkJMZFI4cEdTNjdtL0t5TWdNcnVHN3IrTXZ0QUhaTHlLemZrWjBXdnczWFBsb1ZPWU1ha0NOaWNXTHNSUHR1clhEMEtyKy8xeWtrekllOFIxQWllVUVKbDBnR3ltWk04OXlPSDhuakNHd1psUHdJREFRQUJvNEcxTUlHeU1COEdBMVVkSXdRWU1CYUFGRzNGWlluTDM1RlUwV3M4dHdLbExzMkthSkFkTUNjR0ExVWRKUVFnTUI0R0NDc0dBUVVGQndNQ0JnZ3JCZ0VGQlFjREJBWUlLd1lCQlFVSEF3RXdOd1lJS3dZQkJRVUhBUU1FS3pBcE1BZ0dCZ1FBamtZQkFUQUlCZ1lFQUk1R0FRUXdFd1lHQkFDT1JnRUdNQWtHQndRQWprWUJCZ0l3SFFZRFZSME9CQllFRkhIdlM2VXVCMUhIL0NtZmlvSDkzOWMxSndCR01BNEdBMVVkRHdFQi93UUVBd0lHd0RBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQVNyYjZPLzVWbVJzTkNiazZzRHo1V1FYb1oxZG84MnhxZ1NibDIzK3hXekFHV2xNeEd5elJJdTZOSDQxbFNSeGcxNzRPU1EzS0orYXVTUlB1Si82NG9HUEp4MkVmekMyckZiOU5ZeWhGT2pqcnlSZVJBVUsxZzFBbkEzQVBpMUdLVkxTZ3hnTXBYTnhwNXo0Yk5pNGpzTG92ZW85Z2IxNzR3UWVZSVFzOXdUc3JOcU43eGpkc2UwcjNqTDdhdEJCK1ZOanR5bEYvOXBqaVBWeGR3a0o2MFFXeVg4ZFBobDZ3SWh4STdtVTVMclJZZk9TSEx4V1FhbzIvZWhXUURJeHFYOWQ1bVpEYlUrd0tFc3BiNWhSNmMvOEo1SFhyYy8yMXhvcTNxNjNPNkRoNFh5WEUxSEMzZ0hUeGxmTmtzRm5aOHpNeFlPVlZMc0hleHAwbGRITzhaUT09IiwiTUlJRFNEQ0NBakNnQXdJQkFnSUlTeFIzSW16RzFCY3dEUVlKS29aSWh2Y05BUUVMQlFBd0p6RWxNQ01HQTFVRUF3d2NWRVZUVkNCcFUwaEJVa1VnUm05MWJtUmhkR2x2YmlCbFNVUkJVekFlRncweE9UQXlNakl4TURBME16RmFGdzB6T1RBeU1UY3hNREF5TkRsYU1Ed3hPakE0QmdOVkJBTU1NVlJGVTFRZ2FWTklRVkpGSUVWVklFbHpjM1ZwYm1jZ1EyVnlkR2xtYVdOaGRHbHZiaUJCZFhSb2IzSnBkSGtnUnpVd2dnRWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUURIQjJBQlFMN3p3bWkxeElrTzBhMnE2aklKZG4zUUFtMHMxbFNlUWV2OUYyRjNNNVo4cWlxUUphdXJNWnl3WmZkTnZnOStJcUdIT2pEZTZoSWh1Unp6b0FvMEFiTzROOU9kZjJSRERVOTVON3RvSm1BeUNpWUdnWmZadDdCc0tGSWVRNnA2Q3NnS2NSWFBpMGZkWGRWU0hwNGJaZlFPUWRjbE1idElUaXJuRnRVMDZOUEFob1k2NzZZejk2eEZBRTB6b202ZU1WUFBPSW0wRzhnZDQ0WGxuYkwwdzBtY2NDaTJWVVpqdkNJTDU5TzYxTzh2bFZ5THNCcU5OVEN2ZjlDMkNNWWFFYXRYWnl6L2x3Z0g2SllIdEQwdXNYdC8rTTBxS1llMW9lb0xrMFppY0ZaWGNrMWlTMDlrRmRnZ0s1QmxOb2RvV0phREJScm81MVdoWTJXbkFnTUJBQUdqWXpCaE1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0h3WURWUjBqQkJnd0ZvQVVsWk1reWJ5aEN6SzVIT0JGSEtSTytNTFNSLzR3SFFZRFZSME9CQllFRkczRlpZbkwzNUZVMFdzOHR3S2xMczJLYUpBZE1BNEdBMVVkRHdFQi93UUVBd0lCaGpBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQVpINVFqdXErTzlGcHY2MzdnMGNGNm4xSUxZQkx6MWVOWmpFQjNkb0FleHZpNUN6U3czb3N3SkNTZWRHVzNoaDBxSE9USzJnSTgzamgwVzJFQW4yaXNGZ3doTW9HMmpkMllTRlNrbThRLzJlT2ZjNk1nR1NDNXNPVEw3NUo3YnlMQ29yZHFkL040ZWFqM0VxS0xhV3E3cjd1c3RQODFQOEVJbHowRDhhN2xmZjFGU28yM0hXWFRXWDIrbTJ2b0xBRTVsOTdhR1RHUlMxVWJ4aFAyakZLWUo5WHppS2U5TVFKU1pFbFRROGpxZzJrUEZrRXgvWHFBV3FsRzFkbDF5d0xKcTVpZVB2SzFSNEFZTkkvWWJaUWs5c2xqOHYrUC82TTdFdEVyc2YydUlTZ2V3TFRjV2wyNHgzbkc1eGJRWnhyUDhsMmpTR1ltT1RJbmdLT1FTbmJmZz09IiwiTUlJRE16Q0NBaHVnQXdJQkFnSUlCTFUyY1pBWnFMRXdEUVlKS29aSWh2Y05BUUVMQlFBd0p6RWxNQ01HQTFVRUF3d2NWRVZUVkNCcFUwaEJVa1VnUm05MWJtUmhkR2x2YmlCbFNVUkJVekFlRncweE9UQXlNakl4TURBeU5EbGFGdzB6T1RBeU1UY3hNREF5TkRsYU1DY3hKVEFqQmdOVkJBTU1IRlJGVTFRZ2FWTklRVkpGSUVadmRXNWtZWFJwYjI0Z1pVbEVRVk13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ3JEUDJEV1gzL2I4dU1hcHpFQkFUU2E2aVpmdmdneklCVUV4a1dFYkc5ZTFuVnkvalFrMjBuZlNGTVVtUlQ2TmhZY2RrU1lPL1dya2k5WTRFcEN5MXh2WkhxTCs0WTZTOUpMWndKNzYwTHBZbGUrTmFWdTdtaW5NVVFjdW9qNW5LekNsdmF6YjAwQXg1Z2tKVWZSM3YzWDVHWHFRcmtXYXpNdCtrNVROTTZUV3VKMzBxT2Z3ckh4NXZUTG1UVVVpaCtCc0dMM2Y1R09zMVZUWUlDTmhpVGpONzRuMldxcDJrVUxXSWUrL1g2UlovaEtzcGFIR1puS0RWVHdJKzhabVdGZWp1eEE2RE9YN1JzWUxLdlFPMjFGbWJJQm9TczlBenY1OS9SeFdVSlZNTzBXaERoS3BRZ0NHandnVjMyb2ZOZGtGZ21kVnVsek5QSUQyUk5iVFRMQWdNQkFBR2pZekJoTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SHdZRFZSMGpCQmd3Rm9BVWxaTWt5YnloQ3pLNUhPQkZIS1JPK01MU1IvNHdIUVlEVlIwT0JCWUVGSldUSk1tOG9Rc3l1UnpnUlJ5a1R2akMwa2YrTUE0R0ExVWREd0VCL3dRRUF3SUJoakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBbHphQlZhRmhabUg5dXhzTFN2M0Zra3hXVndCUjFHaEF4d2NKbFY0eCtrcVg4dGNoSjRTRExFdVdSckY0RE50dlNSM3I2OUt6OGVZSTVYdVcxZUcxMllqR0dWbFlpamR4ckcxQU56R24ydmRvOXZMN2RFRlVFTUsxQUt4UnN0YlRkRTd5d3pJVi9DNjF3OEpyeHdMdHQ5T2pkVUVVUEh1R1RqdXY1bkZCUGRGek9jdnUrRFRNbDczQ0pQMnplWlVGZ3VqNTVNc1hZNDVNclhyYmd0K0xKcVV1NHBrQjJiTHU5RmJlUkxXWkp1a25ZU3JXNGZ5UUJaMmkrTXNHZGlCS1FjZjNmTFhqcGNoNDgvcDdTaVRrNHVmbG9CYXFUQ2x0L0V0V1hEU21GY3Y0UWpCazFtVVB1OXZ4aWtjSERrQXZKck9YR2cwYiszZUk0YTdPVGZBYjFnPT0iXX0.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDA2Iiwic3ViIjoiNDE5NDA0ZTEtMDdjZS00ZDgwLTllOGEtZWNhOTR2ZGUwMDAzZGUiLCJhdWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAxIiwianRpIjoiNzgyYmIzOWUtMjQ4YS00NzA4LWI2MmUtZWZiMDVmYzM2MDQyIiwiZXhwIjoxNzY3MTc5ODY5LCJpYXQiOjE3NjcxNzk4MzksIm9yZ2FuaXNhdGlvbklkZW50aWZpZXIiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAyIiwibmJmIjoxNzY3MTc5ODM5fQ.uqSii8f7qMMQ84ZMbWAMHas6C5uyKsT4vRzkwW6PJRjGRv3NZGGhYn_-T84Ga3qYieru60_O0mmmjzFHv7I_Q9XY6DJrW-bloDCgzl68cu2bXXz9Ev-anU4iEwpYELzmRvIqX9S9q2yC2JESaEZgCAIzGdhz-_yJda5prmuCV5uCV9SlwsOlq9nvRsePwb_HbXyGn29CYtLrs8rlcnsqWuJ6fieZtGNrR-XD6NX2fJ5BoG7TwZTu_54P2BxaNvb8zxn44udOJ1htg1rUGqywhnKxLXP2DHtKCBkRhdlabaMVww3YC_UXPe2TcNvwHd8s-9mVVStf2hR_Y5__6RVUkcHa0TqyzZrkGfQ02lOvaVZsb1e6MC5X7kNYPYsNMfpqMHj2RBnRQlM9UaXa-OLZe7d91xiwdENNw9L0eOenLzS5VCJVXq6_8dWbEOm1KFQPu-S58E6OdklqVqfyj3afvflI988zCy_A0wtCR_RqNJPH41mYbp6V_Zz_3uPC63Xz5rRNk6N3kXWaElH3GLuZl_eu-mG4BtGyr0i1OvUhh3oHXqhAec12maKI8iNZvV7XmxOBEJdjGREtV8bxvF_Mlu9uzRVI5ZsnAiy6qdRfHzccqt-devEfNdJZZ_d83kCj3NH6Jf79EpUBL25CuCtZDBxNXjZsOEJ4K6yK5xPb3_c } ``` **Decoded JWT Payload** ```json { "iss": "did:ishare:EU.NL.NTRNL-10000006", "sub": "419404e1-07ce-4d80-9e8a-eca94vde0003de", "aud": "did:ishare:EU.NL.NTRNL-10000001", "jti": "782bb39e-248a-4708-b62e-efb05fc36042", "exp": "1588926732", "iat": "1588926702", "organisationIdentifier": "did:ishare:EU.NL.NTRNL-10000002" } ``` # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the DCP protocol is supported by the Identity Provider: * [Credential storage (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-storage-dcp) * [Credential issuance (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-issuance-dcp) * [Credential status (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-status-dcp) * [Metadata (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/metadata-dcp) * [Offers (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/offers-dcp) * [Resolution (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/resolution-dcp) # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VC**: * **OpenID4VCI**: Credential Issuance endpoints * **OpenID4VP**: Credential Presentation endpoints # OpenID4VCI Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VCI protocol is supported by the Identity Provider: * [Credential Issuer Metadata (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-issuer-metadata-openid4vci) * [Token Endpoint (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/token-endpoint-openid4vci) * [Credential Endpoint (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-endpoint-openid4vci) # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VP protocol is supported by the Identity Provider: * [Verifier Metadata (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp) * [Authorization Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/authorization-endpoint-openid4vp) * [Presentation Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/presentation-endpoint-openid4vp) # Getting started 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.\ \ 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: The Participant Registry can issue Participant Credentials as Verifiable Credentials (VCs) to onboarded parties and expose them via the [DCP Endpoints.](/participant-registry-role/m2m-verifiable-credential-endpoints) Holders store these in a credential wallet and present them to verifiers when needed for onboarding or service use. Verifiers check issuer (Participant Registry), signature, schema, and status. This complements existing registry lookups and improves portability across data spaces. For the structure of the Participant Credential, see the [JSON Schema](https://schemas.ishare.eu/v3/party/schema.json). *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 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. The Party model describes a participant. Most information is clustered in [claims](/reference/claim-models). In order to double check if required endpoints are implemented, please use the following list as a cheat sheet: Participant Registry required endpoints: * [ ] [Access token (M2M)](/all-roles-common-endpoints/access-token-m2m) * [ ] [Capabilities](/all-roles-common-endpoints/capabilities) * [ ] [Parties \[GET\]](/participant-registry-role/parties) * [ ] [Parties \[OPTIONS\]](/participant-registry-role/parties-options) * [ ] [Parties (single party) \[GET\]](/participant-registry-role/single-party) * [ ] [Parties (single party) \[OPTIONS\]](/participant-registry-role/parties-single-party-options) * [ ] [Claims \[GET\]](/participant-registry-role/claims-get) * [ ] [Claims \[OPTIONS\]](/participant-registry-role/claims-options) * [ ] [Claims (single claim) \[GET\]](/participant-registry-role/claims-single-claim-get) * [ ] [Claims (single claim) \[OPTIONS\]](/participant-registry-role/claims-single-claim-options) * [ ] [Trusted list](/participant-registry-role/trusted-list) * [ ] [Data Spaces](/participant-registry-role/dataspaces) * [ ] [Frameworks](/participant-registry-role/frameworks) Participant Registry optional endpoints: * [ ] [Parties \[POST\]](/participant-registry-role/parties-post) * [ ] [Parties (single party) \[PATCH\]](/participant-registry-role/parties-single-party-put) * [ ] [Claims \[POST\]](/participant-registry-role/claims-post) * [ ] [Claims (single claim) \[PATCH\]](/participant-registry-role/claims-single-claim-patch) {% hint style="info" %} As these optional endpoints allow creating and updating parties and claims, The Participant Registry is expected to allow this method only for selected clients (for instance an onboarding portal that operates under the responsibility of the Participant Registry). The Participant Registry MAY also use the Authorisation Registry to authorise and determine which parties are allowed to use these endpoints for what specific purpose. {% endhint %} {% hint style="info" %} The endpoints /ep\_creation and /versions have been removed from version 3.0. * The /ep\_creation endpoint has been replaced by POST and PATCH operations on party and claim endpoints. * The versions endpoint has been replaced by the /frameworks endpoint. {% endhint %} # Parties \[GET] {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The `GET` request to the `/parties` endpoint returns a paginated list of parties, optionally filtered by provided query parameters. ### Request model URL query parameters may be used to filter the parties that are returned. * `id`\ **String**. Search by a party's ID. The endpoint [Parties (single party) \[GET\]](/participant-registry-role/single-party) may be used instead.\ Example: `{url}/parties?id=did:ishare:EU.NL.NLNTR-12345678` * `alsoKnownAs`\ **String**. Search for an identifier in a parties alsoKnownAs array.\ Example: {url}/parties?alsoKnownAs=did:elsi:LEIXG-724500AZSGBRY55MNS59 * `name`\ **String**. Search for a party name. May contain a single \* as wildcard.\ Example: `{url}/parties?name=*corporation` * `claimFilter`\ **Object**. One or more key/value pairs used to filter parties based on claim attributes. The key represents the property name, the value the search criterion. The filters will be processed with AND logic, which means that all filters must result in true for a party to be returned. To filter on a property inside a claim, construct the key as \.\. Boolean values must be `true` or `false`. Refer to [Claim models](/reference/claim-models) for a list of available claimTypes and propertyNames.\ Example: `{url}/parties?claimFilter[frameworkRole.roleId]=ServiceConsumer&claimFilter[frameworkRole.status]=active&claimFilter[dataspaceMembership.dataspaceId]=EU.DSP.EXAMPLE&claimFilter[dataspaceMembership.status]=active` will return all active Service Consumers in data space EU.DSP.EXAMPLE * `page`\ **Integer**. Page number to retrieve (starts at 1). Used for pagination when results exceed the page size. * `pageSize`\ **Integer**. Number of items per page (maximum 100). Used for pagination to control the number of results returned. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /parties?claimFilter[frameworkRole.roleId]=ServiceConsumer&claimFilter[frameworkRole.status]=active&claimFilter[dataspaceMembership.dataspaceId]=EU.DSP.EXAMPLE&claimFilter[dataspaceMembership.status]=active ``` ### Response model **Decoded partiesToken parameters:** The model of the `partiesToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=2.2#/jwtPayloadPartiesToken). The model contains the following attributes: * Standard [iSHARE JWT attributes](/reference/ishare-jwt): `aud`, `iss`, `sub`, `exp`, `iat`, `jti` * The `partiesInfo` object containing: * [Pagination attributes](/reference/pagination) `currentPage`, `pageSize`, `totalPages`, `totalCount` and `count.`Contained inpartiesInfo. * The `data` object, containing an **array of objects** with the following attributes: * `id`\ **String**. Contained in `data`. (Required)\ Primary identifier (iSHARE-ID) of the party. * `name`\ **String**. Contained in `data`. (Required)\ Name of the party. * `alsoKnownAs`\ **Array of strings**. Contained in `data`.\ Array of registered party ids of the party with which the party is also identified. Optional, because a party could be identified with only its iSHARE-ID (in the 'id' property). * `claims`\ **Array of objects**. Contained in `data`. (Required)\ Array of registered claims for the party. Refer to [Claim models](/reference/claim-models) for an overview of available claims. ### Example response The response contains an encoded JWT, which looks like this: ```json { "partiesToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJhdWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUkxOTC0xMDAwMDAwMSIsImlzcyI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTE5MLTEwMDAwMDAwIiwic3ViIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJMTkwtMTAwMDAwMDAiLCJleHAiOjE1OTE5NjU5MzUsImlhdCI6MTU5MTk2NTkwNSwianRpIjoiMDg2ODkwNGQ4ZWQ5NGMwMWEwYTRkNmRkNWM2NWNlOWUiLCJwYXJ0aWVzSW5mbyI6eyJjdXJyZW50UGFnZSI6MSwicGFnZVNpemUiOjEwLCJ0b3RhbFBhZ2VzIjo1LCJ0b3RhbENvdW50Ijo0NywiY291bnQiOjEwLCJkYXRhIjpbeyJpZCI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTIzNDU2NzgiLCJuYW1lIjoiRXhhbXBsZSBDb3Jwb3JhdGlvbiIsImFsc29Lbm93bkFzIjpbImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTIzNDU2NzgiLCJkaWQ6ZWxzaTpMRUlYRy03MjQ1MDBBWlNHQlJZNTVNTlM1OSIsImRpZDp3ZWI6ZXhhbXBsZS5jb20iLCJDb0M6MTIzNDU2Nzg5Il0sImNsYWltcyI6W3siaWQiOiI1ZmZiNGJiOS0yMDIwLTQwNDUtYTkyMi0zYmQ4NGU3OGY3MDkiLCJzdGF0dXMiOiJhY3RpdmUiLCJyZWdpc3RyYXJJZCI6IiBkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAwIiwic3RhcnREYXRlIjoiMjAyNS0wMS0wMVQwMDowMDowMC4wMDBaIiwiZW5kRGF0ZSI6IjIwMjYtMTItMzFUMDA6MDA6MDAuMDAwWiIsInR5cGUiOiJmcmFtZXdvcmtDb21wbGlhbmNlIiwiZnJhbWV3b3JrSWQiOiJpU0hBUkUiLCJhZGRpdGlvbmFsSW5mbyI6eyJkZXNjcmlwdGlvbiI6IkV4YW1wbGUgZGVzY3JpcHRpb24iLCJwdWJsaWNseVB1Ymxpc2hhYmxlIjp0cnVlLCJ3ZWJzaXRlIjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20ifX0seyJpZCI6IjllZDM2OGYzLTYzY2ItNDYwYS04YjllLWU5NTlhMzQ2Y2M0MCIsInN0YXR1cyI6ImFjdGl2ZSIsInJlZ2lzdHJhcklkIjoiIGRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDAiLCJzdGFydERhdGUiOiIyMDI1LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJlbmREYXRlIjoiMjAyNi0xMi0zMVQwMDowMDowMC4wMDBaIiwidHlwZSI6ImZyYW1ld29ya1JvbGUiLCJyb2xlSWQiOiJTZXJ2aWNlQ29uc3VtZXIiLCJ0aXRsZSI6IlNlcnZpY2UgQ29uc3VtZXIiLCJsb2EiOiJub3QtYXBwbGljYWJsZSIsImNvbXBsaWFuY3lWZXJpZmllZCI6InllcyIsImxlZ2FsQWRoZXJlbmNlIjoieWVzIiwiZnJhbWV3b3JrSWQiOiJpU0hBUkUifSx7ImlkIjoiMjA2NWIyOWItZWNiOC00MzhmLWExMmUtNGYyMzQwOWQ0ZTU2Iiwic3RhdHVzIjoiYWN0aXZlIiwicmVnaXN0cmFySWQiOiIgZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMCIsInN0YXJ0RGF0ZSI6IjIwMjUtMDEtMDFUMDA6MDA6MDAuMDAwWiIsImVuZERhdGUiOiIyMDI2LTEyLTMxVDAwOjAwOjAwLjAwMFoiLCJ0eXBlIjoiZnJhbWV3b3JrQWdyZWVtZW50IiwiYWdyZWVtZW50VHlwZSI6IkFjY2Vzc2lvbkFncmVlbWVudCIsImFncmVlbWVudElkIjoiZmQwNmUyMTMtN2RiMi00NjliLWI5Y2UtZGUwMGU0OGUxODE3IiwidGl0bGUiOiJBY2Nlc3Npb24gQWdyZWVtZW50IiwidmVyaWZpY2F0aW9uSGFzaCI6ImFlZjViYjVlM2FiNDkxNTBhNTNiODk2MjhhYjg1OTMzMTViNjY4NmYzZjk2NDk3Mjc3ZmViOWQ2NTg1MjdhY2IiLCJmcmFtZXdvcmtJZCI6ImlTSEFSRSJ9LHsiaWQiOiIyMDY1YjI5Yi1lY2I4LTQzOGYtYTEyZS00ZjIzNDA5ZDRlNTYiLCJzdGF0dXMiOiJhY3RpdmUiLCJyZWdpc3RyYXJJZCI6IiBkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAwIiwic3RhcnREYXRlIjoiMjAyNS0wMS0wMVQwMDowMDowMC4wMDBaIiwiZW5kRGF0ZSI6IjIwMjYtMTItMzFUMDA6MDA6MDAuMDAwWiIsInR5cGUiOiJmcmFtZXdvcmtBZ3JlZW1lbnQiLCJhZ3JlZW1lbnRUeXBlIjoiVGVybXNPZlVzZSIsImFncmVlbWVudElkIjoiM2NkZTZmZjMtMjQzZC00OGMwLTgwMDMtMzFkM2ZlYTNjMWYxIiwidGl0bGUiOiJUZXJtcyBvZiBVc2UiLCJ2ZXJpZmljYXRpb25IYXNoIjoiZjcyN2E0NTliNWNhNWEzMmU1YWZmNzFjMDNmZGFhNjk3Y2Q0NmE0NWViMDRlZWNhYWFlNTkzMWViOWE1YzAwZSIsImZyYW1ld29ya0lkIjoiaVNIQVJFIn0seyJpZCI6IjgwOGQ5N2FjLTJiYjItNGZlNC04NWI2LWIyYzMxOTAzNzU0MSIsInN0YXR1cyI6ImFjdGl2ZSIsInJlZ2lzdHJhcklkIjoiIGRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDAiLCJzdGFydERhdGUiOiIyMDI1LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJlbmREYXRlIjoiMjAyNi0xMi0zMVQwMDowMDowMC4wMDBaIiwidHlwZSI6Ing1MDlDZXJ0aWZpY2F0ZSIsInN1YmplY3ROYW1lIjoiQz1OTCxPPVRlc3QgU2VydmljZSBDb25zdW1lcixDTj1UZXN0IFNlcnZpY2UgQ29uc3VtZXIsMi41LjQuOTc9TlRSTkwtMTAwMDAwMDEiLCJjZXJ0aWZpY2F0ZVR5cGUiOiJlU2VhbCIsIng1YyI6Ik1JSUdpRENDQkhDZ0F3SUJBZ0lVUk1JTCtvbWc2djVwVTZxRk9NRmNlRzFZakRBd0RRWUpLb1pJaHZjTkFRRUxCUUF3WFRFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlKYzNORFFVYzBNUmt3RndZRFZRUmhFeEJPVkZKT1RDMXBVMGhCVWtWVVJWTlVNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQWVGdzB5TkRFeE1EWXhORFExTkRGYUZ3MHlOekV4TURZeE5EUTFOREJhTUdZeEN6QUpCZ05WQkFZVEFrNU1NUjR3SEFZRFZRUUtEQlZVWlhOMElGTmxjblpwWTJVZ1EyOXVjM1Z0WlhJeEhqQWNCZ05WQkFNTUZWUmxjM1FnVTJWeWRtbGpaU0JEYjI1emRXMWxjakVYTUJVR0ExVUVZUXdPVGxSU1Rrd3RNVEF3TURBd01ERXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFEWVNLT3ZtQjZVeEVhWU9QVDdBUGdVNG1hdVNoOXZiUGFjSnRNM2E0Y2R6TjhLaXBwam9XU2JncjZKYjRGYzd0R3ZOazZudldaSGxIekFERmUwYVFJR2w4SURodXExQmhYSlR4SFo0a3J3LzZBRWJDL0dSY2d0SmRjYW5sYzNXa001ck1Fc29EUmQ4Z092TlRuTDdtNTJESVdiM1JTOGJDaXRWSDZxbjNob1dTd1g5WGVlVTZKckd1MWtwNmxmVDE5dTF6SktadUJhQjBJYTR1em1NK1FTZDFrVTZQZUNYUSt0ckVmVlVRa1A4Zy9yelpHblNIOHU3TnFpd3dVZkZTaWFVeXE5UDRJcCtLMEpCVHRBdVE5eHBRNndReHQwaW9GTkZiOWlwbWMzeHhla293TVJ5a1p6RWRvSE8veW5ZM1c0c2JUU2wyZU40RW1mSHpRR1JMSkxBZ01CQUFHamdnSTFNSUlDTVRBT0JnTlZIUThCQWY4RUJBTUNCa0F3REFZRFZSMFRBUUgvQkFJd0FEQWZCZ05WSFNNRUdEQVdnQlN6R2s5Q1FPblllSjFyLy93a3NCQ3hORHp3aVRCWEJnZ3JCZ0VGQlFjQkFRUkxNRWt3UndZSUt3WUJCUVVITUFHR08yaDBkSEJ6T2k4dlkyRTNMbWx6YUdGeVpYUmxjM1F1Ym1WME9qZzBOREl2WldwaVkyRXZjSFZpYkdsamQyVmlMM04wWVhSMWN5OXZZM053TUJBR0ExVWRJQVFKTUFjd0JRWURWUjBnTUI4R0ExVWRKUVFZTUJZR0NDc0dBUVVGQndNRUJnb3JCZ0VFQVlJM0NnTU1NRnNHQ0NzR0FRVUZCd0VEQkU4d1RUQVRCZ1lFQUk1R0FRWXdDUVlIQkFDT1JnRUdBakEyQmdnckJnRUZCUWNCQXd3cVZHaHBjeUJwY3lCMFpYTjBJR1Z6WldGc0lHTmxjblJwWm1sallYUmxJR1p2Y2lCMFpYTjBhVzVuTUI0R0JXZUJEQU1CQkJVd0V4TURUbFJTRXdKT1RBd0lNVEF3TURBd01ERXdnY2NHQTFVZEh3U0J2ekNCdkRDQnVhQ0J0cUNCczRhQnNHaDBkSEJ6T2k4dlkyRTNMbWx6YUdGeVpYUmxjM1F1Ym1WME9qZzBOREl2WldwaVkyRXZjSFZpYkdsamQyVmlMM2RsWW1ScGMzUXZZMlZ5ZEdScGMzUS9ZMjFrUFdOeWJDWnBjM04xWlhJOVEwNGxNMFJsU1VSQlUyVlRSVUZNVDBsRVgwbHpjME5CUnpRbE1rTnZjbWRoYm1sNllYUnBiMjVKWkdWdWRHbG1hV1Z5SlRORVRsUlNUa3d0YVZOSVFWSkZWRVZUVkNVeVEwOGxNMFJwVTBoQlVrVlVaWE4wSlRKRFF5VXpSRmhZTUIwR0ExVWREZ1FXQkJSZHlVTlBpd2UyV3Byd3pZZ3Z5Wis2ZkMxb05EQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FnRUFzWFpyRkc1YWpzRk5nVGZsbmJUZkQ2YUwvVzBPOXV5d1E3VlRUdXJaSGJvSFR4RElJTDNHcTlWai9kMHZwSkpncmZ5c25SL01CSEM5ZlhvblY5V3V3U0tobzkxbUhxdVVjN3l0bHlGd29BTjVST1ZJUjFSQmhVb3NNRzBKZ1R3NVBnVzl4WEJvZ0FaKzdFRkRpTTcwQkpVcitvanFsWjJ5WVMzMjRJRENwZ0ZlOXlTWGluelRnOCtkM2pCc1FMRTBJWG5SLytkTk50aEhoQWwxSExmbDZ3WjlSYlBwWmdwMEFlQ2NkS2JuMUlmVXplUFlNblJ5dURqUmdubVFZVllEMzFRYTY4Z3g1WXMxcWIvZll3U1NwZUVSMFpmMDZTMGV4UFVZU2h0T3dSbFlxaWEyejhMZ040VHVyZHdjRGNUaWptZWtFOSsvb1NTSVRlaEZyb0EyZUhMc3FZdGU4alFnRkJQRWN5MnN5RncxVkZEcVRhL0duSkprb0ZDZjhqUG5sbkFIRUZKbWtoQVozeGVQMURhZzMwQ1ArYW9DUVZOeWtoTzVaNzNWNkJwTmhkcGdhWVg0Qi9RUmVQVWhxVW9ZYkhMZWZBbHlPN1NGUmFoeWNXK282Nks1R3VlcHRndFEyRHJyanZDdGFDRzhFdEpjemloQWpCTjBPUVpzUVduVTh2b29Mc3MrUm1mZzlNWFRSOGs4NWNZVDlaTWRVLzQ2emxnQU1JYUppenY4ajRlSGFLZ2ZSQkIxZ3c3MW9XOTdvVzVRS1F4ODYxVXJSMXUwREptU1FTVXdOWWxvcEtWUm5IdlhKV1VJcmVPcUxmU1NCLzF1VlFmdnEwVXpzSktkZU9DS1JMcFhYZ3hCM3c3UzIrNUtGRVRTN3RjYlo2bUl4WmxKbGgwVlJTcz0iLCJ4NXQjczI1NiI6IjQ2NzA1NTE0NTExMTNiMTk0MjVmOGQ2M2MzZDZjZTQ0NGI1OGRlNjA4MzExMDE3NDhlOWZiOTdiM2U4NzY2ZjgifV19XX19.QjT8Mmt59QzpyyVYIJjgjQJKjDUKdPxDYWvnoptiQqm-CqgPgd3R3cp5vn4IooDJyBJXAWNlPVpoinDqBdsuutCx2roH6xac5dfjLrO7n-YesrriQ6LrFlKZ0iDZ2kRYQVarnov6WXjjMWkqCLu_tulbztSWzjmRAUr6XS6oJ3vo28mnjllDefoArQIl4dMmV7ECWk4FgWW6pMtV64x61SyEV9p4hMxZJSpY0OZRi3TskyDY2-547Cbs0G6JJbWDEdjlmcoXGjaQlOcjWBnqFIPtn3SlEWVdqKFi8YDz2bNno2pRrguTJM4aeGM0d-EFgyHWSviecY4ndkIrJhgyqA" } ``` After decoding, the example content of the JWT looks like this: ```json { "aud": "did:ishare:EU.NL.NTRLNL-10000001", "iss": "did:ishare:EU.NL.NTRLNL-10000000", "sub": "did:ishare:EU.NL.NTRLNL-10000000", "exp": 1591965935, "iat": 1591965905, "jti": "0868904d8ed94c01a0a4d6dd5c65ce9e", "partiesInfo": { "currentPage": 1, "pageSize": 10, "totalPages": 5, "totalCount": 47, "count": 10, "data": [ { "id": "did:ishare:EU.NL.NTRNL-12345678", "name": "Example Corporation", "alsoKnownAs": [ "did:ishare:EU.NL.NTRNL-12345678", "did:elsi:LEIXG-724500AZSGBRY55MNS59", "did:web:example.com", "CoC:123456789" ], "claims": [ { "id": "5ffb4bb9-2020-4045-a922-3bd84e78f709", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkCompliance", "frameworkId": "iSHARE", "additionalInfo": { "description": "Example description", "publiclyPublishable": true, "website": "https://www.example.com" } }, { "id": "9ed368f3-63cb-460a-8b9e-e959a346cc40", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkRole", "roleId": "ServiceConsumer", "title": "Service Consumer", "loa": "not-applicable", "compliancyVerified": "yes", "legalAdherence": "yes", "frameworkId": "iSHARE" }, { "id": "2065b29b-ecb8-438f-a12e-4f23409d4e56", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "AccessionAgreement", "agreementId": "fd06e213-7db2-469b-b9ce-de00e48e1817", "title": "Accession Agreement", "verificationHash": "aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb", "frameworkId": "iSHARE" }, { "id": "2065b29b-ecb8-438f-a12e-4f23409d4e56", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "TermsOfUse", "agreementId": "3cde6ff3-243d-48c0-8003-31d3fea3c1f1", "title": "Terms of Use", "verificationHash": "f727a459b5ca5a32e5aff71c03fdaa697cd46a45eb04eecaaae5931eb9a5c00e", "frameworkId": "iSHARE" }, { "id": "808d97ac-2bb2-4fe4-85b6-b2c319037541", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "x509Certificate", "subjectName": "C=NL,O=Test Service Consumer,CN=Test Service Consumer,2.5.4.97=NTRNL-10000001", "certificateType": "eSeal", "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=", "x5t#s256": "4670551451113b19425f8d63c3d6ce444b58de60831101748e9fb97b3e8766f8" } ] } ] } } ``` # Parties \[OPTIONS] The `OPTIONS` request to the `/parties` endpoint returns a list of supported HTTP methods that can be used with the `/parties` resource. This allows clients to determine which operations are permitted by the server for this endpoint. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ OPTIONS /parties ``` ### Example response The server responds with status code 204. The response contains the following HTTP header: | Header | Example value | | ------ | ------------------ | | Allow | GET, POST, OPTIONS | # Parties \[POST] The `POST` request to the `/parties` endpoint can be used to create a new party in the Participant Registry. {% hint style="info" %} The `POST` request to the `/parties` is an **OPTIONAL** endpoint. For more information on **OPTIONAL** specifications, see [functional requirements per role.](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role) {% endhint %} ### Request model The request must be passed as JWT. The JSON model in the JWT is as follows. * `id`\ **String**. Contained in `party_info`. (Required)\ iSHARE Identifier of the party derived from original party identifiers. * `name`\ **String**. Contained in `party_info`. (Required)\ Name of the party. * `alsoKnownAs`\ **Array of Strings**. Contained in `party_info`\ Array of registered party ids of the party with which the party is also identified. Optional, because a party could be identified with only its iSHARE-ID (in the 'id' property). * `claims`\ **Array of objects**. (Required)\ Array of claims for the party. Refer to [Claim models](/reference/claim-models) for an overview of available claims. In the `POST` request the `id` and `registrarId` fields may be omitted, as they will be provided by the Participant Registry. To create a party as part of the iSHARE Framework, at minimum the following claims MUST be provided: * x509Certificate or idpAssertion * frameworkCompliance * frameworkAgreement * frameworkRole For all roles except for Service Consumer and Entitled Party an x509Certificate claim is required. Service Consumer and Entitled Party MUST either provide a x509Certificate claim or idpAssertion claim if authenticating via Identity Provider. ### Example request ```json POST /parties HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "id": "did:ishare:EU.NL.NTRNL-12345678", "name": "Example Corporation", "alsoKnownAs": [ "did:ishare:EU.NL.NTRNL-12345678", "did:elsi:LEIXG-724500AZSGBRY55MNS59", "did:web:example.com", "CoC:123456789" ], "claims": [ { "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkCompliance", "frameworkId": "iSHARE", "additionalInfo": { "description": "Example description", "publiclyPublishable": true, "website": "https://www.example.com" } }, { "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkRole", "roleId": "ServiceConsumer", "title": "Service Consumer", "loa": "not-applicable", "compliancyVerified": "yes", "legalAdherence": "yes", "frameworkId": "iSHARE" }, { "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "AccessionAgreement", "agreementId": "fd06e213-7db2-469b-b9ce-de00e48e1817", "title": "Accession Agreement", "verificationHash": "aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb", "frameworkId": "iSHARE" }, { "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "TermsOfUse", "agreementId": "3cde6ff3-243d-48c0-8003-31d3fea3c1f1", "title": "Terms of Use", "verificationHash": "f727a459b5ca5a32e5aff71c03fdaa697cd46a45eb04eecaaae5931eb9a5c00e", "frameworkId": "iSHARE" }, { "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "x509Certificate", "subjectName": "C=NL,O=Test Service Consumer,CN=Test Service Consumer,2.5.4.97=NTRNL-10000001", "certificateType": "eSeal", "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=", "x5t#s256": "4670551451113b19425f8d63c3d6ce444b58de60831101748e9fb97b3e8766f8" } ] } ``` ### Response model The response will be equal to the response of the GET request for retrieving a single party. Please refer to the [response model as defined here](/participant-registry-role/single-party#response-model). ### Example response Please also refer to the [example response](/participant-registry-role/single-party#example-response) under the GET request definition. # Parties (single party) \[GET] {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The endpoint /parties can also be used to retrieve just one party. ### Request model The following URL parameter must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party whose claims must be fetched. Can be anyone of the party id from 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. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /parties/did%3Aishare%3AEU.NL.NTRLNL-10000001 ``` ### Response model **Decoded partyToken parameters:** The model of the `partyToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=3.0#/jwtPayloadPartyToken). The model contains the following attributes: * Standard [iSHARE JWT attributes](/reference/ishare-jwt): `aud`, `iss`, `sub`, `exp`, `iat`, `jti` * The `partyInfo` object containing: * `id`\ **String**. Contained in `partyInfo`. (Required)\ Primary identifier (iSHARE-ID) of the party. * `name`\ **String**. Contained in `partyInfo`. (Required)\ Name of the party. * `alsoKnownAs`\ **Array of strings**. Contained in `partyInfo`.\ Array of registered party ids of the party with which the party is also identified. Optional, because a party could be identified with only its iSHARE-ID (in the 'id' property). * `claims`\ **Array of objects**. Contained in `partyInfo`. (Required)\ Array of registered claims for the party. Refer to [Claim models](/reference/claim-models) for an overview of available claims. ### Example response The response contains an encoded JWT, which looks like this: ```json { "party_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJhdWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAxIiwiaXNzIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMCIsInN1YiI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDAiLCJleHAiOjE3MTkzMjEzNTQsImlhdCI6MTcxOTMyMTMyNCwianRpIjoiYWRmMmU5ZWNkYjk3NGZkNjgyMDljMzkwMDA1YjEyNzYiLCJwYXJ0eUluZm8iOnsiaWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEyMzQ1Njc4IiwibmFtZSI6IkV4YW1wbGUgQ29ycG9yYXRpb24iLCJhbHNvS25vd25BcyI6WyJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEyMzQ1Njc4IiwiZGlkOmVsc2k6TEVJWEctNzI0NTAwQVpTR0JSWTU1TU5TNTkiLCJkaWQ6d2ViOmV4YW1wbGUuY29tIiwiQ29DOjEyMzQ1Njc4OSJdLCJjbGFpbXMiOlt7ImlkIjoiNWZmYjRiYjktMjAyMC00MDQ1LWE5MjItM2JkODRlNzhmNzA5Iiwic3RhdHVzIjoiYWN0aXZlIiwicmVnaXN0cmFySWQiOiIgZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMCIsInN0YXJ0RGF0ZSI6IjIwMjUtMDEtMDFUMDA6MDA6MDAuMDAwWiIsImVuZERhdGUiOiIyMDI2LTEyLTMxVDAwOjAwOjAwLjAwMFoiLCJ0eXBlIjoiZnJhbWV3b3JrQ29tcGxpYW5jZSIsImZyYW1ld29ya0lkIjoiaVNIQVJFIiwiYWRkaXRpb25hbEluZm8iOnsiZGVzY3JpcHRpb24iOiJFeGFtcGxlIGRlc2NyaXB0aW9uIiwicHVibGljbHlQdWJsaXNoYWJsZSI6dHJ1ZSwid2Vic2l0ZSI6Imh0dHBzOi8vd3d3LmV4YW1wbGUuY29tIn19LHsiaWQiOiI5ZWQzNjhmMy02M2NiLTQ2MGEtOGI5ZS1lOTU5YTM0NmNjNDAiLCJzdGF0dXMiOiJhY3RpdmUiLCJyZWdpc3RyYXJJZCI6IiBkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAwIiwic3RhcnREYXRlIjoiMjAyNS0wMS0wMVQwMDowMDowMC4wMDBaIiwiZW5kRGF0ZSI6IjIwMjYtMTItMzFUMDA6MDA6MDAuMDAwWiIsInR5cGUiOiJmcmFtZXdvcmtSb2xlIiwicm9sZUlkIjoiU2VydmljZUNvbnN1bWVyIiwidGl0bGUiOiJTZXJ2aWNlIENvbnN1bWVyIiwibG9hIjoibm90LWFwcGxpY2FibGUiLCJjb21wbGlhbmN5VmVyaWZpZWQiOiJ5ZXMiLCJsZWdhbEFkaGVyZW5jZSI6InllcyIsImZyYW1ld29ya0lkIjoiaVNIQVJFIn0seyJpZCI6IjIwNjViMjliLWVjYjgtNDM4Zi1hMTJlLTRmMjM0MDlkNGU1NiIsInN0YXR1cyI6ImFjdGl2ZSIsInJlZ2lzdHJhcklkIjoiIGRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDAiLCJzdGFydERhdGUiOiIyMDI1LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJlbmREYXRlIjoiMjAyNi0xMi0zMVQwMDowMDowMC4wMDBaIiwidHlwZSI6ImZyYW1ld29ya0FncmVlbWVudCIsImFncmVlbWVudFR5cGUiOiJBY2Nlc3Npb25BZ3JlZW1lbnQiLCJhZ3JlZW1lbnRJZCI6ImZkMDZlMjEzLTdkYjItNDY5Yi1iOWNlLWRlMDBlNDhlMTgxNyIsInRpdGxlIjoiQWNjZXNzaW9uIEFncmVlbWVudCIsInZlcmlmaWNhdGlvbkhhc2giOiJhZWY1YmI1ZTNhYjQ5MTUwYTUzYjg5NjI4YWI4NTkzMzE1YjY2ODZmM2Y5NjQ5NzI3N2ZlYjlkNjU4NTI3YWNiIiwiZnJhbWV3b3JrSWQiOiJpU0hBUkUifSx7ImlkIjoiMjA2NWIyOWItZWNiOC00MzhmLWExMmUtNGYyMzQwOWQ0ZTU2Iiwic3RhdHVzIjoiYWN0aXZlIiwicmVnaXN0cmFySWQiOiIgZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMCIsInN0YXJ0RGF0ZSI6IjIwMjUtMDEtMDFUMDA6MDA6MDAuMDAwWiIsImVuZERhdGUiOiIyMDI2LTEyLTMxVDAwOjAwOjAwLjAwMFoiLCJ0eXBlIjoiZnJhbWV3b3JrQWdyZWVtZW50IiwiYWdyZWVtZW50VHlwZSI6IlRlcm1zT2ZVc2UiLCJhZ3JlZW1lbnRJZCI6IjNjZGU2ZmYzLTI0M2QtNDhjMC04MDAzLTMxZDNmZWEzYzFmMSIsInRpdGxlIjoiVGVybXMgb2YgVXNlIiwidmVyaWZpY2F0aW9uSGFzaCI6ImY3MjdhNDU5YjVjYTVhMzJlNWFmZjcxYzAzZmRhYTY5N2NkNDZhNDVlYjA0ZWVjYWFhZTU5MzFlYjlhNWMwMGUiLCJmcmFtZXdvcmtJZCI6ImlTSEFSRSJ9LHsiaWQiOiI4MDhkOTdhYy0yYmIyLTRmZTQtODViNi1iMmMzMTkwMzc1NDEiLCJzdGF0dXMiOiJhY3RpdmUiLCJyZWdpc3RyYXJJZCI6IiBkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAwIiwic3RhcnREYXRlIjoiMjAyNS0wMS0wMVQwMDowMDowMC4wMDBaIiwiZW5kRGF0ZSI6IjIwMjYtMTItMzFUMDA6MDA6MDAuMDAwWiIsInR5cGUiOiJ4NTA5Q2VydGlmaWNhdGUiLCJzdWJqZWN0TmFtZSI6IkM9TkwsTz1UZXN0IFNlcnZpY2UgQ29uc3VtZXIsQ049VGVzdCBTZXJ2aWNlIENvbnN1bWVyLDIuNS40Ljk3PU5UUk5MLTEwMDAwMDAxIiwiY2VydGlmaWNhdGVUeXBlIjoiZVNlYWwiLCJ4NWMiOiJNSUlHaURDQ0JIQ2dBd0lCQWdJVVJNSUwrb21nNnY1cFU2cUZPTUZjZUcxWWpEQXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRRMU5ERmFGdzB5TnpFeE1EWXhORFExTkRCYU1HWXhDekFKQmdOVkJBWVRBazVNTVI0d0hBWURWUVFLREJWVVpYTjBJRk5sY25acFkyVWdRMjl1YzNWdFpYSXhIakFjQmdOVkJBTU1GVlJsYzNRZ1UyVnlkbWxqWlNCRGIyNXpkVzFsY2pFWE1CVUdBMVVFWVF3T1RsUlNUa3d0TVRBd01EQXdNREV3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRRFlTS092bUI2VXhFYVlPUFQ3QVBnVTRtYXVTaDl2YlBhY0p0TTNhNGNkek44S2lwcGpvV1NiZ3I2SmI0RmM3dEd2Tms2bnZXWkhsSHpBREZlMGFRSUdsOElEaHVxMUJoWEpUeEhaNGtydy82QUViQy9HUmNndEpkY2FubGMzV2tNNXJNRXNvRFJkOGdPdk5Ubkw3bTUyRElXYjNSUzhiQ2l0Vkg2cW4zaG9XU3dYOVhlZVU2SnJHdTFrcDZsZlQxOXUxekpLWnVCYUIwSWE0dXptTStRU2Qxa1U2UGVDWFErdHJFZlZVUWtQOGcvcnpaR25TSDh1N05xaXd3VWZGU2lhVXlxOVA0SXArSzBKQlR0QXVROXhwUTZ3UXh0MGlvRk5GYjlpcG1jM3h4ZWtvd01SeWtaekVkb0hPL3luWTNXNHNiVFNsMmVONEVtZkh6UUdSTEpMQWdNQkFBR2pnZ0kxTUlJQ01UQU9CZ05WSFE4QkFmOEVCQU1DQmtBd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JTekdrOUNRT25ZZUoxci8vd2tzQkN4TkR6d2lUQlhCZ2dyQmdFRkJRY0JBUVJMTUVrd1J3WUlLd1lCQlFVSE1BR0dPMmgwZEhCek9pOHZZMkUzTG1semFHRnlaWFJsYzNRdWJtVjBPamcwTkRJdlpXcGlZMkV2Y0hWaWJHbGpkMlZpTDNOMFlYUjFjeTl2WTNOd01CQUdBMVVkSUFRSk1BY3dCUVlEVlIwZ01COEdBMVVkSlFRWU1CWUdDQ3NHQVFVRkJ3TUVCZ29yQmdFRUFZSTNDZ01NTUZzR0NDc0dBUVVGQndFREJFOHdUVEFUQmdZRUFJNUdBUVl3Q1FZSEJBQ09SZ0VHQWpBMkJnZ3JCZ0VGQlFjQkF3d3FWR2hwY3lCcGN5QjBaWE4wSUdWelpXRnNJR05sY25ScFptbGpZWFJsSUdadmNpQjBaWE4wYVc1bk1CNEdCV2VCREFNQkJCVXdFeE1EVGxSU0V3Sk9UQXdJTVRBd01EQXdNREV3Z2NjR0ExVWRId1NCdnpDQnZEQ0J1YUNCdHFDQnM0YUJzR2gwZEhCek9pOHZZMkUzTG1semFHRnlaWFJsYzNRdWJtVjBPamcwTkRJdlpXcGlZMkV2Y0hWaWJHbGpkMlZpTDNkbFltUnBjM1F2WTJWeWRHUnBjM1EvWTIxa1BXTnliQ1pwYzNOMVpYSTlRMDRsTTBSbFNVUkJVMlZUUlVGTVQwbEVYMGx6YzBOQlJ6UWxNa052Y21kaGJtbDZZWFJwYjI1SlpHVnVkR2xtYVdWeUpUTkVUbFJTVGt3dGFWTklRVkpGVkVWVFZDVXlRMDhsTTBScFUwaEJVa1ZVWlhOMEpUSkRReVV6UkZoWU1CMEdBMVVkRGdRV0JCUmR5VU5QaXdlMldwcnd6WWd2eVorNmZDMW9OREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBc1hackZHNWFqc0ZOZ1RmbG5iVGZENmFML1cwTzl1eXdRN1ZUVHVyWkhib0hUeERJSUwzR3E5VmovZDB2cEpKZ3JmeXNuUi9NQkhDOWZYb25WOVd1d1NLaG85MW1IcXVVYzd5dGx5RndvQU41Uk9WSVIxUkJoVW9zTUcwSmdUdzVQZ1c5eFhCb2dBWis3RUZEaU03MEJKVXIrb2pxbFoyeVlTMzI0SURDcGdGZTl5U1hpbnpUZzgrZDNqQnNRTEUwSVhuUi8rZE5OdGhIaEFsMUhMZmw2d1o5UmJQcFpncDBBZUNjZEtibjFJZlV6ZVBZTW5SeXVEalJnbm1RWVZZRDMxUWE2OGd4NVlzMXFiL2ZZd1NTcGVFUjBaZjA2UzBleFBVWVNodE93UmxZcWlhMno4TGdONFR1cmR3Y0RjVGlqbWVrRTkrL29TU0lUZWhGcm9BMmVITHNxWXRlOGpRZ0ZCUEVjeTJzeUZ3MVZGRHFUYS9HbkpKa29GQ2Y4alBubG5BSEVGSm1raEFaM3hlUDFEYWczMENQK2FvQ1FWTnlraE81WjczVjZCcE5oZHBnYVlYNEIvUVJlUFVocVVvWWJITGVmQWx5TzdTRlJhaHljVytvNjZLNUd1ZXB0Z3RRMkRycmp2Q3RhQ0c4RXRKY3ppaEFqQk4wT1Fac1FXblU4dm9vTHNzK1JtZmc5TVhUUjhrODVjWVQ5Wk1kVS80NnpsZ0FNSWFKaXp2OGo0ZUhhS2dmUkJCMWd3NzFvVzk3b1c1UUtReDg2MVVyUjF1MERKbVNRU1V3Tllsb3BLVlJuSHZYSldVSXJlT3FMZlNTQi8xdVZRZnZxMFV6c0pLZGVPQ0tSTHBYWGd4QjN3N1MyKzVLRkVUUzd0Y2JaNm1JeFpsSmxoMFZSU3M9IiwieDV0I3MyNTYiOiI0NjcwNTUxNDUxMTEzYjE5NDI1ZjhkNjNjM2Q2Y2U0NDRiNThkZTYwODMxMTAxNzQ4ZTlmYjk3YjNlODc2NmY4In1dfX0.F_XtOQdw_9Ercl7q0n2NhLSm8CR2o35QC-d0Zky7QCwnJsTJRGuVTWC7RVdhqk6sTyd3H2BLnjm8YuzzvCieBeQqajgFoLNisCh2R1KHzJbhyw2UFtrtscfOB14dwwADDyuQ6LL_Lx49-BZ66LvAfR8jcB8Hl6_fBYyx0e9a7oR2JBr5JnKxKiS3lVoxixTS5edn7kp2X8MDF_q_IeO62g__lx5SllhAuIn1mKn6jziRTiQa-rYG6DhrP_n6fXciW_XJlNnOJ_Ao3QohyoDvsDi2ewZUa2wLCbNz_pnnm6D2BgEfHIB9f6Z8XIGUaMfSy6jFPu6N2b0oXEbQ74Cdnw" } ``` After decoding, the example content of the JWT looks like this: ```json { "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", "partyInfo": { "id": "did:ishare:EU.NL.NTRNL-12345678", "name": "Example Corporation", "alsoKnownAs": [ "did:ishare:EU.NL.NTRNL-12345678", "did:elsi:LEIXG-724500AZSGBRY55MNS59", "did:web:example.com", "CoC:123456789" ], "claims": [ { "id": "5ffb4bb9-2020-4045-a922-3bd84e78f709", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkCompliance", "frameworkId": "iSHARE", "additionalInfo": { "description": "Example description", "publiclyPublishable": true, "website": "https://www.example.com" } }, { "id": "9ed368f3-63cb-460a-8b9e-e959a346cc40", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkRole", "roleId": "ServiceConsumer", "title": "Service Consumer", "loa": "not-applicable", "compliancyVerified": "yes", "legalAdherence": "yes", "frameworkId": "iSHARE" }, { "id": "2065b29b-ecb8-438f-a12e-4f23409d4e56", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "AccessionAgreement", "agreementId": "fd06e213-7db2-469b-b9ce-de00e48e1817", "title": "Accession Agreement", "verificationHash": "aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb", "frameworkId": "iSHARE" }, { "id": "2065b29b-ecb8-438f-a12e-4f23409d4e56", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "TermsOfUse", "agreementId": "3cde6ff3-243d-48c0-8003-31d3fea3c1f1", "title": "Terms of Use", "verificationHash": "f727a459b5ca5a32e5aff71c03fdaa697cd46a45eb04eecaaae5931eb9a5c00e", "frameworkId": "iSHARE" }, { "id": "808d97ac-2bb2-4fe4-85b6-b2c319037541", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "x509Certificate", "subjectName": "C=NL,O=Test Service Consumer,CN=Test Service Consumer,2.5.4.97=NTRNL-10000001", "certificateType": "eSeal", "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=", "x5t#s256": "4670551451113b19425f8d63c3d6ce444b58de60831101748e9fb97b3e8766f8" } ] } } ``` # Parties (single party) \[OPTIONS] The `OPTIONS` request to the `/parties/{id}` endpoint returns a list of supported HTTP methods that can be used with the `/parties/{id}` resource. This allows clients to determine which operations are permitted by the server for this endpoint. ### Request model The following URL parameter must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party whose claims must be fetched. Can be anyone of the party id from 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. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ OPTIONS /parties/{id} ``` {% hint style="info" %} ***{id}** must be replaced by the actual party identifier for which HTTP OPTIONS are requested.* {% endhint %} ### Example response The server responds with status code 204. The response contains the following HTTP header: | Header | Example value | | ------ | ------------------- | | Allow | GET, PATCH, OPTIONS | # Parties (single party) \[PATCH] The `PATCH` request to the `/parties/{partyId}` endpoint can be used to partially update information of an iSHARE participant in the Participant Registry (name and alsoKnownAs). Only the provided fields will be updated, other fields remain unchanged. The partyId cannot be changed through this operation. To update information stored in claims, use the PATCH method on claims instead. {% hint style="info" %} The `PATCH` request to the `/parties/{partyId}` is an **OPTIONAL** endpoint. {% endhint %} ### Request model The following URL parameter must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party who must be fetched. Can be anyone of the party id from 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. The request must be passed as JWT. The JSON model in the JWT is as follows. * `name`\ **String**. Root level. (Required)\ Name of the party. * `alsoKnownAs`\ **Array of strings**. Contained in `partyInfo`.\ Array of registered party ids of the party with which the party is also identified. Optional, because a party could be identified with only its iSHARE-ID (in the 'id' property). When updating alsKnownAs all existing values must also be provided. Implementations should raise an error if any of the existing values are missing (meaning deletion) as Ids in this field cannot be deleted once registered. ### Example request ```json PUT /parties/did%3Aishare%3AEU.NL.NTRLNL-10000001 HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "name": "Example Corporation", "alsoKnownAs": [ "did:ishare:EU.NL.NTRNL-12345678", "did:ebsi:LEIXG-724500AZSGBRY55MNS59", "did:web:example.com", "CoC:123456789" ] } ``` ### Response model The response will be equal to the response of the GET request for retrieving a single party. Please refer to the [response model as defined here](/participant-registry-role/single-party#response-model). ### Example response Please also refer to the [example response](/participant-registry-role/single-party#example-response) under the GET request definition. # Claims \[GET] {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The GET request to /parties/{partyId}/claims endpoint will return all claims for the provided partyId. ### Request model The following URL parameter must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party whose claims must be fetched. Can be anyone of the party id from 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. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /parties/did%3Aishare%3AEU.NL.NTRLNL-10000001/claims ``` ### Response model **Decoded claimsToken parameters:** The model of the `claimsToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=3.0#/jwtPayloadClaimsToken). The model contains the following attributes: * Standard [iSHARE JWT attributes](/reference/ishare-jwt): `aud`, `iss`, `sub`, `exp`, `iat`, `jti` * The `claimsInfo` object containing: * `claims`\ **Array of objects**. Contained in `claimsInfo`.\ Array of registered claims for the party. Refer to [Claim models](/reference/claim-models) for an overview of available claims. ### Example response The response contains an encoded JWT, which looks like this: ```json { "claimsToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJhdWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUkxOTC0xMDAwMDAwMSIsImlzcyI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTE5MLTEwMDAwMDAwIiwic3ViIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJMTkwtMTAwMDAwMDAiLCJleHAiOjE1OTE5NjU5MzUsImlhdCI6MTU5MTk2NTkwNSwianRpIjoiMDg2ODkwNGQ4ZWQ5NGMwMWEwYTRkNmRkNWM2NWNlOWUiLCJjbGFpbXNJbmZvIjp7ImNsYWltcyI6W3siaWQiOiI1ZmZiNGJiOS0yMDIwLTQwNDUtYTkyMi0zYmQ4NGU3OGY3MDkiLCJzdGF0dXMiOiJhY3RpdmUiLCJyZWdpc3RyYXJJZCI6IiBkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAwIiwic3RhcnREYXRlIjoiMjAyNS0wMS0wMVQwMDowMDowMC4wMDBaIiwiZW5kRGF0ZSI6IjIwMjYtMTItMzFUMDA6MDA6MDAuMDAwWiIsInR5cGUiOiJmcmFtZXdvcmtDb21wbGlhbmNlIiwiZnJhbWV3b3JrSWQiOiJpU0hBUkUiLCJhZGRpdGlvbmFsSW5mbyI6eyJkZXNjcmlwdGlvbiI6IkV4YW1wbGUgZGVzY3JpcHRpb24iLCJwdWJsaWNseVB1Ymxpc2hhYmxlIjp0cnVlLCJ3ZWJzaXRlIjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20ifX0seyJpZCI6IjllZDM2OGYzLTYzY2ItNDYwYS04YjllLWU5NTlhMzQ2Y2M0MCIsInN0YXR1cyI6ImFjdGl2ZSIsInJlZ2lzdHJhcklkIjoiIGRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDAiLCJzdGFydERhdGUiOiIyMDI1LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJlbmREYXRlIjoiMjAyNi0xMi0zMVQwMDowMDowMC4wMDBaIiwidHlwZSI6ImZyYW1ld29ya1JvbGUiLCJyb2xlSWQiOiJTZXJ2aWNlQ29uc3VtZXIiLCJ0aXRsZSI6IlNlcnZpY2UgQ29uc3VtZXIiLCJsb2EiOiJub3QtYXBwbGljYWJsZSIsImNvbXBsaWFuY3lWZXJpZmllZCI6InllcyIsImxlZ2FsQWRoZXJlbmNlIjoieWVzIiwiZnJhbWV3b3JrSWQiOiJpU0hBUkUifSx7ImlkIjoiMjA2NWIyOWItZWNiOC00MzhmLWExMmUtNGYyMzQwOWQ0ZTU2Iiwic3RhdHVzIjoiYWN0aXZlIiwicmVnaXN0cmFySWQiOiIgZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMDAwMDAwMCIsInN0YXJ0RGF0ZSI6IjIwMjUtMDEtMDFUMDA6MDA6MDAuMDAwWiIsImVuZERhdGUiOiIyMDI2LTEyLTMxVDAwOjAwOjAwLjAwMFoiLCJ0eXBlIjoiZnJhbWV3b3JrQWdyZWVtZW50IiwiYWdyZWVtZW50VHlwZSI6IkFjY2Vzc2lvbkFncmVlbWVudCIsImFncmVlbWVudElkIjoiZmQwNmUyMTMtN2RiMi00NjliLWI5Y2UtZGUwMGU0OGUxODE3IiwidGl0bGUiOiJBY2Nlc3Npb24gQWdyZWVtZW50IiwidmVyaWZpY2F0aW9uSGFzaCI6ImFlZjViYjVlM2FiNDkxNTBhNTNiODk2MjhhYjg1OTMzMTViNjY4NmYzZjk2NDk3Mjc3ZmViOWQ2NTg1MjdhY2IiLCJmcmFtZXdvcmtJZCI6ImlTSEFSRSJ9LHsiaWQiOiIyMDY1YjI5Yi1lY2I4LTQzOGYtYTEyZS00ZjIzNDA5ZDRlNTYiLCJzdGF0dXMiOiJhY3RpdmUiLCJyZWdpc3RyYXJJZCI6IiBkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTEwMDAwMDAwIiwic3RhcnREYXRlIjoiMjAyNS0wMS0wMVQwMDowMDowMC4wMDBaIiwiZW5kRGF0ZSI6IjIwMjYtMTItMzFUMDA6MDA6MDAuMDAwWiIsInR5cGUiOiJmcmFtZXdvcmtBZ3JlZW1lbnQiLCJhZ3JlZW1lbnRUeXBlIjoiVGVybXNPZlVzZSIsImFncmVlbWVudElkIjoiM2NkZTZmZjMtMjQzZC00OGMwLTgwMDMtMzFkM2ZlYTNjMWYxIiwidGl0bGUiOiJUZXJtcyBvZiBVc2UiLCJ2ZXJpZmljYXRpb25IYXNoIjoiZjcyN2E0NTliNWNhNWEzMmU1YWZmNzFjMDNmZGFhNjk3Y2Q0NmE0NWViMDRlZWNhYWFlNTkzMWViOWE1YzAwZSIsImZyYW1ld29ya0lkIjoiaVNIQVJFIn0seyJpZCI6IjgwOGQ5N2FjLTJiYjItNGZlNC04NWI2LWIyYzMxOTAzNzU0MSIsInN0YXR1cyI6ImFjdGl2ZSIsInJlZ2lzdHJhcklkIjoiIGRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTAwMDAwMDAiLCJzdGFydERhdGUiOiIyMDI1LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJlbmREYXRlIjoiMjAyNi0xMi0zMVQwMDowMDowMC4wMDBaIiwidHlwZSI6Ing1MDlDZXJ0aWZpY2F0ZSIsInN1YmplY3ROYW1lIjoiQz1OTCxPPVRlc3QgU2VydmljZSBDb25zdW1lcixDTj1UZXN0IFNlcnZpY2UgQ29uc3VtZXIsMi41LjQuOTc9TlRSTkwtMTAwMDAwMDEiLCJjZXJ0aWZpY2F0ZVR5cGUiOiJlU2VhbCIsIng1YyI6Ik1JSUdpRENDQkhDZ0F3SUJBZ0lVUk1JTCtvbWc2djVwVTZxRk9NRmNlRzFZakRBd0RRWUpLb1pJaHZjTkFRRUxCUUF3WFRFZU1Cd0dBMVVFQXd3VlpVbEVRVk5sVTBWQlRFOUpSRjlKYzNORFFVYzBNUmt3RndZRFZRUmhFeEJPVkZKT1RDMXBVMGhCVWtWVVJWTlVNUk13RVFZRFZRUUtFd3BwVTBoQlVrVlVaWE4wTVFzd0NRWURWUVFHRXdKWVdEQWVGdzB5TkRFeE1EWXhORFExTkRGYUZ3MHlOekV4TURZeE5EUTFOREJhTUdZeEN6QUpCZ05WQkFZVEFrNU1NUjR3SEFZRFZRUUtEQlZVWlhOMElGTmxjblpwWTJVZ1EyOXVjM1Z0WlhJeEhqQWNCZ05WQkFNTUZWUmxjM1FnVTJWeWRtbGpaU0JEYjI1emRXMWxjakVYTUJVR0ExVUVZUXdPVGxSU1Rrd3RNVEF3TURBd01ERXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFEWVNLT3ZtQjZVeEVhWU9QVDdBUGdVNG1hdVNoOXZiUGFjSnRNM2E0Y2R6TjhLaXBwam9XU2JncjZKYjRGYzd0R3ZOazZudldaSGxIekFERmUwYVFJR2w4SURodXExQmhYSlR4SFo0a3J3LzZBRWJDL0dSY2d0SmRjYW5sYzNXa001ck1Fc29EUmQ4Z092TlRuTDdtNTJESVdiM1JTOGJDaXRWSDZxbjNob1dTd1g5WGVlVTZKckd1MWtwNmxmVDE5dTF6SktadUJhQjBJYTR1em1NK1FTZDFrVTZQZUNYUSt0ckVmVlVRa1A4Zy9yelpHblNIOHU3TnFpd3dVZkZTaWFVeXE5UDRJcCtLMEpCVHRBdVE5eHBRNndReHQwaW9GTkZiOWlwbWMzeHhla293TVJ5a1p6RWRvSE8veW5ZM1c0c2JUU2wyZU40RW1mSHpRR1JMSkxBZ01CQUFHamdnSTFNSUlDTVRBT0JnTlZIUThCQWY4RUJBTUNCa0F3REFZRFZSMFRBUUgvQkFJd0FEQWZCZ05WSFNNRUdEQVdnQlN6R2s5Q1FPblllSjFyLy93a3NCQ3hORHp3aVRCWEJnZ3JCZ0VGQlFjQkFRUkxNRWt3UndZSUt3WUJCUVVITUFHR08yaDBkSEJ6T2k4dlkyRTNMbWx6YUdGeVpYUmxjM1F1Ym1WME9qZzBOREl2WldwaVkyRXZjSFZpYkdsamQyVmlMM04wWVhSMWN5OXZZM053TUJBR0ExVWRJQVFKTUFjd0JRWURWUjBnTUI4R0ExVWRKUVFZTUJZR0NDc0dBUVVGQndNRUJnb3JCZ0VFQVlJM0NnTU1NRnNHQ0NzR0FRVUZCd0VEQkU4d1RUQVRCZ1lFQUk1R0FRWXdDUVlIQkFDT1JnRUdBakEyQmdnckJnRUZCUWNCQXd3cVZHaHBjeUJwY3lCMFpYTjBJR1Z6WldGc0lHTmxjblJwWm1sallYUmxJR1p2Y2lCMFpYTjBhVzVuTUI0R0JXZUJEQU1CQkJVd0V4TURUbFJTRXdKT1RBd0lNVEF3TURBd01ERXdnY2NHQTFVZEh3U0J2ekNCdkRDQnVhQ0J0cUNCczRhQnNHaDBkSEJ6T2k4dlkyRTNMbWx6YUdGeVpYUmxjM1F1Ym1WME9qZzBOREl2WldwaVkyRXZjSFZpYkdsamQyVmlMM2RsWW1ScGMzUXZZMlZ5ZEdScGMzUS9ZMjFrUFdOeWJDWnBjM04xWlhJOVEwNGxNMFJsU1VSQlUyVlRSVUZNVDBsRVgwbHpjME5CUnpRbE1rTnZjbWRoYm1sNllYUnBiMjVKWkdWdWRHbG1hV1Z5SlRORVRsUlNUa3d0YVZOSVFWSkZWRVZUVkNVeVEwOGxNMFJwVTBoQlVrVlVaWE4wSlRKRFF5VXpSRmhZTUIwR0ExVWREZ1FXQkJSZHlVTlBpd2UyV3Byd3pZZ3Z5Wis2ZkMxb05EQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FnRUFzWFpyRkc1YWpzRk5nVGZsbmJUZkQ2YUwvVzBPOXV5d1E3VlRUdXJaSGJvSFR4RElJTDNHcTlWai9kMHZwSkpncmZ5c25SL01CSEM5ZlhvblY5V3V3U0tobzkxbUhxdVVjN3l0bHlGd29BTjVST1ZJUjFSQmhVb3NNRzBKZ1R3NVBnVzl4WEJvZ0FaKzdFRkRpTTcwQkpVcitvanFsWjJ5WVMzMjRJRENwZ0ZlOXlTWGluelRnOCtkM2pCc1FMRTBJWG5SLytkTk50aEhoQWwxSExmbDZ3WjlSYlBwWmdwMEFlQ2NkS2JuMUlmVXplUFlNblJ5dURqUmdubVFZVllEMzFRYTY4Z3g1WXMxcWIvZll3U1NwZUVSMFpmMDZTMGV4UFVZU2h0T3dSbFlxaWEyejhMZ040VHVyZHdjRGNUaWptZWtFOSsvb1NTSVRlaEZyb0EyZUhMc3FZdGU4alFnRkJQRWN5MnN5RncxVkZEcVRhL0duSkprb0ZDZjhqUG5sbkFIRUZKbWtoQVozeGVQMURhZzMwQ1ArYW9DUVZOeWtoTzVaNzNWNkJwTmhkcGdhWVg0Qi9RUmVQVWhxVW9ZYkhMZWZBbHlPN1NGUmFoeWNXK282Nks1R3VlcHRndFEyRHJyanZDdGFDRzhFdEpjemloQWpCTjBPUVpzUVduVTh2b29Mc3MrUm1mZzlNWFRSOGs4NWNZVDlaTWRVLzQ2emxnQU1JYUppenY4ajRlSGFLZ2ZSQkIxZ3c3MW9XOTdvVzVRS1F4ODYxVXJSMXUwREptU1FTVXdOWWxvcEtWUm5IdlhKV1VJcmVPcUxmU1NCLzF1VlFmdnEwVXpzSktkZU9DS1JMcFhYZ3hCM3c3UzIrNUtGRVRTN3RjYlo2bUl4WmxKbGgwVlJTcz0iLCJ4NXQjczI1NiI6IjQ2NzA1NTE0NTExMTNiMTk0MjVmOGQ2M2MzZDZjZTQ0NGI1OGRlNjA4MzExMDE3NDhlOWZiOTdiM2U4NzY2ZjgifV19fQ.dmbWUulYsiz8ME1hamtaZfrMEfpQSzOIE6pdQN_nUP8qlwqjbJw4DvSuvAtDzEazdmSb4BGBmvSgySCOyLnGTTWtxwvc0C-mZd6HK1rzPtS-RPm2z3niZjgIeTRMKbSV7vBHZX0bR8TJ1Z1B6gfRM_2ClJXUMECPiKnfzI3t8dW26AblV5aGg5X_RAo51e0e6cXKvWekul2sp7Q6WXw278muvEQKtl82vuMO9ZNpkHvi0MNQMBqVAHZRkka3NuRCm2RQJGMBxUd5IwdQDJdNvFKVdfoexlbLtzQjhb2Yw2hafUGX7Ds3649bOHlv47pFzf-LiFn8ziWuJ-S0d-0i3w" } ``` After decoding, the example content of the JWT looks like this: ```json { "aud": "did:ishare:EU.NL.NTRLNL-10000001", "iss": "did:ishare:EU.NL.NTRLNL-10000000", "sub": "did:ishare:EU.NL.NTRLNL-10000000", "exp": 1591965935, "iat": 1591965905, "jti": "0868904d8ed94c01a0a4d6dd5c65ce9e", "claimsInfo": { "claims": [ { "id": "5ffb4bb9-2020-4045-a922-3bd84e78f709", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkCompliance", "frameworkId": "iSHARE", "additionalInfo": { "description": "Example description", "publiclyPublishable": true, "website": "https://www.example.com" } }, { "id": "9ed368f3-63cb-460a-8b9e-e959a346cc40", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkRole", "roleId": "ServiceConsumer", "title": "Service Consumer", "loa": "not-applicable", "compliancyVerified": "yes", "legalAdherence": "yes", "frameworkId": "iSHARE" }, { "id": "2065b29b-ecb8-438f-a12e-4f23409d4e56", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "AccessionAgreement", "agreementId": "fd06e213-7db2-469b-b9ce-de00e48e1817", "title": "Accession Agreement", "verificationHash": "aef5bb5e3ab49150a53b89628ab8593315b6686f3f96497277feb9d658527acb", "frameworkId": "iSHARE" }, { "id": "2065b29b-ecb8-438f-a12e-4f23409d4e56", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "frameworkAgreement", "agreementType": "TermsOfUse", "agreementId": "3cde6ff3-243d-48c0-8003-31d3fea3c1f1", "title": "Terms of Use", "verificationHash": "f727a459b5ca5a32e5aff71c03fdaa697cd46a45eb04eecaaae5931eb9a5c00e", "frameworkId": "iSHARE" }, { "id": "808d97ac-2bb2-4fe4-85b6-b2c319037541", "status": "active", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "type": "x509Certificate", "subjectName": "C=NL,O=Test Service Consumer,CN=Test Service Consumer,2.5.4.97=NTRNL-10000001", "certificateType": "eSeal", "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=", "x5t#s256": "4670551451113b19425f8d63c3d6ce444b58de60831101748e9fb97b3e8766f8" } ] } } ``` # Claims \[OPTIONS] The `OPTIONS` request to the `/parties/{partyId}/claims` endpoint returns a list of supported HTTP methods that can be used with the `/parties/{partyId}/claims` resource. This allows clients to determine which operations are permitted by the server for this endpoint. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ OPTIONS /parties/did%3Aishare%3AEU.NL.NTRLNL-10000001/claims ``` ### Example response The server provides the response with status code 204. The response contains the following HTTP header: | Header | Example value | | ------ | ------------------ | | Allow | GET, POST, OPTIONS | # Claims \[POST] The `POST` request to the `/parties/{partyId}/claims` endpoint can be used to create a new claim for a party in the Participant Registry. {% hint style="info" %} The `POST` request to the `/parties/{partyId}/claims` is an **OPTIONAL** endpoint. {% endhint %} ### Request model The following URL parameter must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party for who a new claim must be registered. Can be anyone of the party id from 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. The request must be passed as JWT. The JSON body must contain a claim. Refer to [Claim models](/reference/claim-models) for an overview of available claims. In the `POST` request the `id` and `registrarId` fields may be omitted, as they will be provided by the Participant Registry. ### Example request ```json POST /parties/ HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "id": "5ffb4bb9-2020-4045-a922-3bd84e78f709", "registrarId": " did:ishare:NTRNL-10000000", "type": "frameworkCompliance", "frameworkId": "iSHARE", "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "additionalInfo": { "description": "Example description", "publiclyPublishable": true, "website": "https://www.example.com" } } ``` ### Response model The response will be equal to the response of the [GET request for retrieving a single claim](/participant-registry-role/claims-single-claim-get). Refer to the response model as defined here. ### Example response Refer to the example response under the [GET request](/participant-registry-role/claims-single-claim-get) definition. # Claims (single claim) \[GET] {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The GET request to /parties/{partyId}/claims/{claimId} endpoint will return a single claim. ### Request model The following URL parameters must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party whose claims must be fetched. Can be anyone of the party id from 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. * `claimId` {url}/parties/{partyId}/claims/{**claimId**} (Required)\ **String**. The id of the claims that must be fetched. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /parties/did%3Aishare%3AEU.NL.NTRLNL-10000001/claims/724ef843-68c3-4a9a-a244-8b17bcae33e1 ``` ### Response model **Decoded claimsToken parameters:** The model of the `claimToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=3.0#/jwtPayloadClaimToken). The model contains the following attributes: * Standard [iSHARE JWT attributes](/reference/ishare-jwt): `aud`, `iss`, `sub`, `exp`, `iat`, `jti` * The `claimInfo` object containing: * `claim`\ **Objects**. Contained in `claimInfo`.\ Registered claim. Refer to [Claim models](/reference/claim-models) for an overview of available claims. ### Example response The response contains an encoded JWT, which looks like this: ```json { "claimToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJhdWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUkxOTC0xMDAwMDAwMSIsImlzcyI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTE5MLTEwMDAwMDAwIiwic3ViIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJMTkwtMTAwMDAwMDAiLCJleHAiOjE1OTE5NjU5MzUsImlhdCI6MTU5MTk2NTkwNSwianRpIjoiMDg2ODkwNGQ4ZWQ5NGMwMWEwYTRkNmRkNWM2NWNlOWUiLCJjbGFpbXNJbmZvIjp7ImNsYWltIjp7ImlkIjoiNzI0ZWY4NDMtNjhjMy00YTlhLWEyNDQtOGIxN2JjYWUzM2UxIiwicmVnaXN0cmFySWQiOiIgZGlkOmlzaGFyZTpOVFJOTC0xMDAwMDAwMCIsInR5cGUiOiJmcmFtZXdvcmtDb21wbGlhbmNlIiwiZnJhbWV3b3JrSWQiOiJpU0hBUkUiLCJzdGF0dXMiOiJhY3RpdmUiLCJzdGFydERhdGUiOiIyMDI1LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJlbmREYXRlIjoiMjAyNi0xMi0zMVQwMDowMDowMC4wMDBaIiwiYWRkaXRpb25hbEluZm8iOnsiZGVzY3JpcHRpb24iOiJFeGFtcGxlIGRlc2NyaXB0aW9uIiwicHVibGljbHlQdWJsaXNoYWJsZSI6dHJ1ZSwid2Vic2l0ZSI6Imh0dHBzOi8vd3d3LmV4YW1wbGUuY29tIn19fX0.ZVORI8Jc9L-rdfRcGyDbsQBotWSpVSQU_nDd80_28Be_m9D5a5Q3YB-XQxTO0CoVZ_VxWVqwtPZT-e0dgfVfSRE9TCEGbr4_xuAa8IGPTSydRcXHli_C40rkM4ZXI76reHspYAsw7UXDOQ0MZIGWoEC9F2LK5AcZP7fGIrB0IFJYhxsy8XVbuz79FK3ljz0NtX2Lex1JnHlpjkfwZQ7KXXaqpVI50M-rHs8MRK5DbZjoFPJ6O-ozZmcFjIqMFV39LSswOkCalGuqgmKidF_KKrToZlytU8KdMJFHuHsM0zeR_qdlWR6Ytfj7jt3_1yJ1f7GrjAtT5CdgA8WL-6y4-A" } ``` After decoding, the example content of the JWT looks like this: ```json { "aud": "did:ishare:EU.NL.NTRLNL-10000001", "iss": "did:ishare:EU.NL.NTRLNL-10000000", "sub": "did:ishare:EU.NL.NTRLNL-10000000", "exp": 1591965935, "iat": 1591965905, "jti": "0868904d8ed94c01a0a4d6dd5c65ce9e", "claimInfo": { "claim": { "id": "724ef843-68c3-4a9a-a244-8b17bcae33e1", "registrarId": " did:ishare:EU.NL.NTRNL-10000000", "type": "frameworkCompliance", "frameworkId": "iSHARE", "status": "active", "startDate": "2025-01-01T00:00:00.000Z", "endDate": "2026-12-31T00:00:00.000Z", "additionalInfo": { "description": "Example description", "publiclyPublishable": true, "website": "https://www.example.com" } } } } ``` # Claims (single claim) \[OPTIONS] The `OPTIONS` request to the `/parties/{partyId}/claims/{claimId}` endpoint returns a list of supported HTTP methods that can be used with the `/parties/{partyId}/claims/{claimId}` resource. This allows clients to determine which operations are permitted by the server for this endpoint. ### Request model The following URL parameters must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party whose claims must be fetched. Can be anyone of the party id from 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. * `claimId` {url}/parties/{partyId}/claims/{**claimId**} (Required)\ **String**. The id of the claims that must be fetched. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ OPTIONS /parties/did%3Aishare%3AEU.NL.NTRLNL-10000001/claims/724ef843-68c3-4a9a-a244-8b17bcae33e1 ``` ### Example response The server provides the response with status code 204. The response contains the following HTTP header: | Header | Example value | | ------ | ------------------- | | Allow | GET, PATCH, OPTIONS | # Claims (single claim) \[PATCH] The `PATCH` request to the `/parties/{partyId}/claims/{claimId}` endpoint can be used to update a claim for a party in the Participant Registry. {% hint style="info" %} The `PATCH` request to the `/parties/{partyId}/claims/{claimId}` is an **OPTIONAL** endpoint. {% endhint %} ### Request model The following URL parameters must be used. * `partyId` {url}/parties/{**partyId**} (Required)\ **String**. The id of the party for who a claim must be updated. Can be anyone of the party id from 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. * `claimId` {url}/parties/{partyId}/claims/{**claimId**} (Required)\ **String**. The id of the claims that must be updated. The body may contain any number of key/value pairs that define what properties must be updated **in the specified claimId only**. * The **key** represents the property path within the claim (using dot notation for nested properties) * The **value** is the new value to set. Take into account the following: * Only the provided fields will be updated, other fields remain unchanged. * Note that claims cannot be deleted, but instead the status can be set to revoked or inactive. * Because the {claimId} must be provided in the URL, only the properties of that\ specific claim may be updated in one request. If you want to update multiple claims, you must make multiple requests. * The claim ID and type cannot be changed through this operation. Examples of property paths: * "status" - Update claim status * "validFrom" - Update validity start time (ISO 8601 date-time) * "validUntil" - Update validity end time (ISO 8601 date-time) * "roleId" - Update role ID in role claim * "additionalInfo.companyEmail" - Update contact email in additional info The request must be passed as JWT. The JSON body must contain a claim. Refer to [Claim models](/reference/claim-models) for an overview of available claims. ### Example request The following is an example request to update a frameworkRole claim. ```json POST /parties/ HTTP/1.1 Authorization: Bearer YOUR_SECRET_TOKEN Content-Type: application/json { "status": "active", "startDate": "2024-01-01T00:00:00.000Z", "endDate": "2024-12-31T23:59:59.999Z", "roleId": "ServiceProvider", "loa": 2, } ``` ### Response model The response will be equal to the response of the [GET request for retrieving a single claim](/participant-registry-role/claims-single-claim-get). Refer to the response model as defined here. ### Example response Refer to the example response under the [GET request](/participant-registry-role/claims-single-claim-get) definition. # Trusted list {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ### Response model The model of the `trustedListToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=3.0#/jwtPayloadTrustedListToken). **Decoded trusted\_list\_token parameters:** It contains [iSHARE-compliant JWT claims](/reference/ishare-jwt#jwt-payload). In addition to that, it also contains the following parameters: * `trustedList` **Array of Objects**. Root level. Contains a collection of trusted certificate authorities. * `subject` **String**. Contained in the object of `trustedList`. Certificate authority subject name. * `certificateFingerprint` **String**. Contained in the object of `trustedList`. SHA256 fingerprint of the certificate. * `validity` **String**. Contained in the object of `trustedList`. Validity of the certificate. Available values are *valid* or *invalid*. * `status` **String**. Contained in the object of `trustedList`. Status of the certificate. Available values are *granted*, *withdrawn*, *supervision ceased* and *undersupervision*. ### Example request 
> Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ

GET /trusted_list
### Example response The response contains an encoded JWT, which looks like this: ```json { "trusted_list_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJpc3MiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUkxOTC0xMDAwMDAwMCIsInN1YiI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTE5MLTEwMDAwMDAwIiwianRpIjoiOTc3NGQ5MjRiOGMwNGI5N2JkM2YwODA3ZGViMTU0YjYiLCJpYXQiOjE1OTE5NjYwMTAsImV4cCI6MTU5MTk2NjA0MCwiYXVkIjoiZGlkOmlzaGFyZTpFVS5OTC5OVFJMTkwtMTAwMDAwMDEiLCJ0cnVzdGVkTGlzdCI6W3sic3ViamVjdCI6IkM9TkwsIE89U3RhYXQgZGVyIE5lZGVybGFuZGVuLCBDTj1URVNUIFN0YWF0IGRlciBOZWRlcmxhbmRlbiBPcmdhbmlzYXRpZSBTZXJ2aWNlcyBDQSAtIEczIiwiY2VydGlmaWNhdGVGaW5nZXJwcmludCI6IkRDMTNGQzk0RkYwMTQ5REUxQjA3Rjc5NjVGNjU1QUVENTRDNkE2QkRBN0FERjcxQTczMkZGQ0ZBQkM0NTRDN0EiLCJ2YWxpZGl0eSI6InZhbGlkIiwic3RhdHVzIjoiZ3JhbnRlZCJ9LHsic3ViamVjdCI6IkM9TkwsIE89aVNIQVJFIEZvdW5kYXRpb24sIENOPVRFU1QgaVNIQVJFIEZvdW5kYXRpb24gUEtJb3ZlcmhlaWQgT3JnYW5pc2F0aWUgU2VydmVyIENBIC0gRzMiLCJjZXJ0aWZpY2F0ZUZpbmdlcnByaW50IjoiRjIxODEzM0NEM0FDMkQ5NzBEMTBDQTQ2QkIwM0Y4MzI0NTMzMjRCMEY0QUY1QzNGNjFCQUQ2RkRFRUM1RUI4MyIsInZhbGlkaXR5IjoidmFsaWQiLCJzdGF0dXMiOiJncmFudGVkIn0seyJzdWJqZWN0IjoiQz1OTCwgTz1URVNUIFN0YWF0IGRlciBOZWRlcmxhbmRlbiwgQ049VEVTVCBTdGFhdCBkZXIgTmVkZXJsYW5kZW4gUm9vdCBDQSAtIEczIiwiY2VydGlmaWNhdGVGaW5nZXJwcmludCI6Ijk4QzlDMTRGN0YxRjlBODNBNzQ0RTBBQ0JBOURBNkE0N0VFOTZFMDUzRDcyNzk1NDU3QTVCQzAyMDcyMjlENDMiLCJ2YWxpZGl0eSI6InZhbGlkIiwic3RhdHVzIjoiZ3JhbnRlZCJ9LHsic3ViamVjdCI6IkNOPVRFU1QgaVNIQVJFIEZvdW5kYXRpb24gZUlEQVMiLCJjZXJ0aWZpY2F0ZUZpbmdlcnByaW50IjoiOEMzOUREMDZFMzVERTg0NjcwMDRBNTQyRDBDQTRCOEZEQzdENkY4RjcxM0Y0MEEzNUJEOUU2NTkzOEExOTFDRiIsInZhbGlkaXR5IjoidmFsaWQiLCJzdGF0dXMiOiJncmFudGVkIn0seyJzdWJqZWN0IjoiQz1OTCwgTz1pU0hBUkUsIE9VPVRlc3QsIENOPWlTSEFSRVRlc3RDQSIsImNlcnRpZmljYXRlRmluZ2VycHJpbnQiOiJBNzhGREY3QkExM0JCRDk1QzYyMzY5NzJERDAwM0ZBRTA3RjRFNDQ3Qjc5MUI2RUY2NzM3QUQyMkYwQjYxODYyIiwidmFsaWRpdHkiOiJ2YWxpZCIsInN0YXR1cyI6ImdyYW50ZWQifSx7InN1YmplY3QiOiJDTj1URVNUIGlTSEFSRSBFVSBJc3N1aW5nIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEc1IiwiY2VydGlmaWNhdGVGaW5nZXJwcmludCI6IkZENTU5M0RDODc0RUNDMTEzM0MyMUE3NzI1OUMzNTkyNTUyRUMwQzg5REZDRDdBQjNDMEJEQ0ZENzNGMEY1Q0MiLCJ2YWxpZGl0eSI6InZhbGlkIiwic3RhdHVzIjoiZ3JhbnRlZCJ9LHsic3ViamVjdCI6IkM9TkwsIE89aVNIQVJFLCBPVT1UZXN0LCBDTj1pU0hBUkVUZXN0Q0FfVExTIiwiY2VydGlmaWNhdGVGaW5nZXJwcmludCI6IkRGMkZGNTFEMUIyNTU5RDY4NjcyM0M5NzAzN0RDOUQ1QzU4OTQwNkNBQzRGODRDMjlBQjNENDNFMDEyNjI1MUQiLCJ2YWxpZGl0eSI6InZhbGlkIiwic3RhdHVzIjoiZ3JhbnRlZCJ9XX0.IZk38yM21ZNmKHtIxsKTqGxTLlqQXJxwX4WO6GpXzI91CL5NGRPupKQgiBFahYn9SIFy_PNoSZXdkRxA1JBXpxlQPImuoC8trZrJiYCWHa2IjVTCoChglZ0O70wYubLnvhLajtsd8iu_wLH5kmw78BrtfYEnmTYxfNF3zaJgHSmJ17hHstkbzB-bApRXUA1IG21rHsGbBecmJxWV6Dpw745nntDu_70q6RRnqwGbgOOo4Dd4BJ9xtIEpb10p9nmdN-K-jEn6Cg-imFsaXIJuZXKHpefuhSXUGxprU7-55ghymfME93wtmUNrhqDvpU97yhFjoPXnUAzIBeAFFrGy5A" } ``` After decoding, the example content of the JWT looks like this: ```json { "iss": "did:ishare:EU.NL.NTRLNL-10000000", "sub": "did:ishare:EU.NL.NTRLNL-10000000", "jti": "9774d924b8c04b97bd3f0807deb154b6", "iat": 1591966010, "exp": 1591966040, "aud": "did:ishare:EU.NL.NTRLNL-10000001", "trustedList": [ { "subject": "C=NL, O=Staat der Nederlanden, CN=TEST Staat der Nederlanden Organisatie Services CA - G3", "certificateFingerprint": "DC13FC94FF0149DE1B07F7965F655AED54C6A6BDA7ADF71A732FFCFABC454C7A", "validity": "valid", "status": "granted" }, { "subject": "C=NL, O=iSHARE Foundation, CN=TEST iSHARE Foundation PKIoverheid Organisatie Server CA - G3", "certificateFingerprint": "F218133CD3AC2D970D10CA46BB03F832453324B0F4AF5C3F61BAD6FDEEC5EB83", "validity": "valid", "status": "granted" }, { "subject": "C=NL, O=TEST Staat der Nederlanden, CN=TEST Staat der Nederlanden Root CA - G3", "certificateFingerprint": "98C9C14F7F1F9A83A744E0ACBA9DA6A47EE96E053D72795457A5BC0207229D43", "validity": "valid", "status": "granted" }, { "subject": "CN=TEST iSHARE Foundation eIDAS", "certificateFingerprint": "8C39DD06E35DE8467004A542D0CA4B8FDC7D6F8F713F40A35BD9E65938A191CF", "validity": "valid", "status": "granted" }, { "subject": "C=NL, O=iSHARE, OU=Test, CN=iSHARETestCA", "certificateFingerprint": "A78FDF7BA13BBD95C6236972DD003FAE07F4E447B791B6EF6737AD22F0B61862", "validity": "valid", "status": "granted" }, { "subject": "CN=TEST iSHARE EU Issuing Certification Authority G5", "certificateFingerprint": "FD5593DC874ECC1133C21A77259C3592552EC0C89DFCD7AB3C0BDCFD73F0F5CC", "validity": "valid", "status": "granted" }, { "subject": "C=NL, O=iSHARE, OU=Test, CN=iSHARETestCA_TLS", "certificateFingerprint": "DF2FF51D1B2559D686723C97037DC9D5C589406CAC4F84C29AB3D43E0126251D", "validity": "valid", "status": "granted" } ] } ``` # Data Spaces {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ### Request model URL query parameters may be used for [Pagination](/reference/pagination). * `page`\ **Integer**. Page number to retrieve (starts at 1). Used for pagination when results exceed the page size. * `pageSize`\ **Integer**. Number of items per page (maximum 100). Used for pagination to control the number of results returned. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /dataspaces?page=18pageSize=20 ``` ### Response model **Decoded dataspacesToken parameters:** The model of the `dataspacesToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=3.0#/jwtPayloadDataspacesToken). The model contains the following attributes: * Standard [iSHARE JWT attributes](/reference/ishare-jwt): `aud`, `iss`, `sub`, `exp`, `iat`, `jti` * The `dataspacesInfo` object containing: * [Pagination attributes](/reference/pagination) `currentPage`, `pageSize`, `totalPages`, `totalCount` and `count.` Contained in dataspacesInfo. * The `data` object, containing an **array of dataspace objects** with the following attributes: * `id` (Required)\ **String**. Contained in dataspace object.\ Unique ID of the data space. This is in format of \.DS.<3 letter code for data spaces>.<3 letter code for data spaces>.\.\, for example EU.DS.GND.NL.DVU. * Continent is a 2 letter code (EU, AS, NA, SA, OC, AF, AN) * "DS": stands for dataspace * 3 letter code of common EU data spaces. One of the following list:
AGRAgriculture
CUHCultural Heritage
ENREnergy
FINFinance
GNDGreen deal
HLTHealth
LANLanguage
MFGManufacturing
MEDMedia
MOBMobility
PUBPublic administration
RNIResearch and Innovation
SKLSkills
TURTourism
* ISO 3166-1 alpha-2 2 letter country code (for example DE or FR) * Name/title of the data space. Name may not contain spaces or dot "." or other special characters. Maximum length of name can be 64 characters. * `title` (Required)\ **String**. Contained in dataspace object.\ Title of dataspace. * `dataSpaceDescriptionUrl`\ **String**. Contained in dataspace object.\ URL pointing to the dataspace definition. This is expected to be based on OpenDEI model of building blocks for dataspaces. The machine readable format definition is currently under development. The specifications will be made available once published. * `defaultParticipantIdentifierName`\ **String**. Name of the default participant identifier used in the dataspace, which must be mentioned in the dataspace description (e.g., iSHARE-DID). If no default identifier has been selected, the default identifier must be assumed to be ishare:did. * `defaultParticipantIdentifierPrefix`\ **String**. Prefix of the default participant identifier used in the dataspace, which must be mentioned in the dataspace description. If no default identifier has been selected, the default identifier must be assumed to be ishare:did. * `website`\ **String**. Contained in dataspace object\ Website address of the dataspace, typically dataspace authority. The website details out more information about the dataspace and guides (potential) participants (to become member of) the dataspace. * `govBody`\ **String**. Contained in dataspace object\ Name of the governing body of the dataspace. This is typically legal entity (company, association, foundation) that governs the dataspace and its operations. * `govBodyId`\ **String**. Contained in dataspace object\ Unique ID of the governing body of the dataspace. * `registrarIds`\ **Array of strings**. Contained in dataspace object\ Array of ids of Participant Registries that are authorized to register (potential) participants in the dataspace. * `tags`\ **String**. Contained in dataspace object\ Free text field for adding relevant tags that are relevant in the context of dataspace. It useful for searching for specific dataspaces based on tags. * `status`\ **String**. Contained in dataspace object\ Status of the dataspace. Available values are new, in progress, active and not active. * `countryRegistration`\ **String**. Contained in dataspace object\ Country in which the dataspace is registered in. * `countriesOperation`\ **Array of strings**. Contained in dataspace object\ Array of country names in which the dataspace operates. * `sectors`\ **Array of strings**. Contained in dataspace object\ Array of sector names in which the dataspace operates. * `agreements`\ **Array of objects.** Contained in dataspace object\ Array of agreements that are relevant in the context of the dataspace. * `id` (Required)\ **String**. Contained in agreement object\ ID of the agreement. * `title` (Required)\ **String**. Contained in agreement object\ Title of the agreement. * `required` (Required)\ **Boolean**. Contained in agreement object\ Whether accepting the agreement is required to join the dataspace. * `roles`\ **Array of objects**. Contained in dataspace object\ Array of roles that are declared in the dataspace. * `id` (Required)\ **String**. Contained in role object\ ID of the role. * `title` (Required)\ **String**. Contained in role object\ Title of the role. * `x509CertificateRequired`\ **String**. Contained in role object\ Whether a participant in this role is required to have an x.509 certificate. May be yes or no. * `agreements`\ **Array of strings**. Contained in role object\ Array of agreement IDs that a participant in this role is required to accept to join the dataspace. * `loaRequired`\ **String**. Contained in role object\ Whether a participant in this role must provide a Level of Assurance (LoA) statement. May be yes or no. * `technicalComplianceRequired`\ **String**. Contained in role object\ Whether a participant in this role must provide a technical compliance statement. May be yes or no. ### Example response The response contains an encoded JWT, which looks like this: ```json < Content-Type: application/json { "dataspacesToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJkYXRhc3BhY2VzSW5mbyI6eyJjdXJyZW50UGFnZSI6MSwicGFnZVNpemUiOjEwLCJ0b3RhbFBhZ2VzIjo1LCJ0b3RhbENvdW50Ijo0NywiY291bnQiOjEwLCJkYXRhIjpbeyJpZCI6IkVVLkRTLk1PQi5OTC5ETERTX0xvZ2lzdGljcyIsInRpdGxlIjoiRExEU19Mb2dpc3RpY3NfRGF0YVNwYWNlIiwiZGVmVXJsIjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vZGVmaW5pdGlvbiIsIndlYnNpdGUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbSIsImdvdkJvZHkiOiJMb2dpc3RpY3MgRGF0YSBTcGFjZSIsImdvdkJvZHlJZCI6ImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTIzNDU2NzgiLCJyZWdpc3RyYXJJZHMiOlsiZGlkOmlzaGFyZTpFVS5OTC5OVFJOTC0xMjM0NTY3OCIsImRpZDppc2hhcmU6RVUuTkwuTlRSTkwtMTIzNDU2NzkiXSwidGFncyI6IiNsb2dpc3RpY3MgI05MIiwic3RhdHVzIjoiYWN0aXZlIiwiY291bnRyeVJlZ2lzdHJhdGlvbiI6Ik5MIiwiY291bnRyaWVzT3BlcmF0aW9uIjpbIlRoZSBOZXRoZXJsYW5kcyIsIkdlcm1hbnkiXSwic2VjdG9ycyI6WyJJbmZvcm1hdGlvbiBUZWNobm9sb2d5IiwiTG9naXN0aWNzIl0sImFncmVlbWVudHMiOlt7ImlkIjoiVGVybXNvZlVzZSIsInRpdGxlIjoiVGVybXMgb2YgVXNlIiwicmVxdWlyZWQiOnRydWV9LHsiaWQiOiJBY2Nlc3Npb25BZ3JlZW1lbnQiLCJ0aXRsZSI6IkFjY2Vzc2lvbiBBZ3JlZW1lbnQiLCJyZXF1aXJlZCI6dHJ1ZX1dLCJyb2xlcyI6W3siaWQiOiJzZXJ2aWNlQnJva2VyIiwidGl0bGUiOiJTZXJ2aWNlIEJyb2tlciIsIng1MDlDZXJ0aWZpY2F0ZVJlcXVpcmVkIjp0cnVlLCJhZ3JlZW1lbnRzIjpbIlRlcm1zb2ZVc2UiLCJBY2Nlc3Npb25BZ3JlZW1lbnQiXSwibG9hUmVxdWlyZWQiOnRydWUsInRlY2huaWNhbENvbXBsaWFuY2UiOiJ5ZXMifV19XX19.fkYSXrEz8l-4GdMX4ESglPPDE8JQQGENghDJjxqiKCCXK6GRM-TXQJQmbSG37zRpXlBuAG5tx9GVJUpkgRcRjodO-oV_UB920T8wA5TFLW-6U_gi4SqQudlkJZtSvLR9zqkJT-Umk8j_VhQcUekJR7u_4bra6_ut1YV4k6SjMiRAWtyRQblgpDi-PWpLLgGIAnGPJ7u0ZqJczMytUHLnCV65xXNFo13kzgIlwy8PcG6vfdtFF3O6zDYKn6Jw0ydRnopp_BDIAKNQ7pWdvPhR44URhP99SkhFUxSNO7VJxCdx29f7Wr4JcRxMuvRdQvyxHKfC4g5m1tTxO8dfKQRq4Q" } ``` After decoding, the example content of the JWT looks like this: ```json { "dataspacesInfo": { "currentPage": 1, "pageSize": 10, "totalPages": 5, "totalCount": 47, "count": 10, "data": [ { "id": "EU.DS.MOB.NL.DLDS_Logistics", "title": "DLDS_Logistics_DataSpace", "dataSpaceDescriptionUrl": "https://url-pointing-to/description.json", "defaultParticipantIdentifierName": "NL Chamber of Commerce (Kamer van Koophandel)", "defaultParticipantIdentifierPrefix": "kvk", "website": "https://www.example.com", "govBody": "Logistics Data Space", "govBodyId": "did:ishare:EU.NL.NTRNL-12345678", "registrarIds": ["did:ishare:EU.NL.NTRNL-12345678", "did:ishare:EU.NL.NTRNL-12345679"], "tags": "#logistics #NL", "status": "active", "countryRegistration": "NL", "countriesOperation": ["The Netherlands", "Germany"], "sectors": ["Information Technology", "Logistics"], "agreements": [ { "id": "TermsofUse", "title": "Terms of Use", "required": true }, { "id": "AccessionAgreement", "title": "Accession Agreement", "required": true } ], "roles": [ { "id": "serviceBroker", "title": "Service Broker", "x509CertificateRequired": true, "agreements": ["TermsofUse", "AccessionAgreement"], "loaRequired": true, "technicalCompliance": "yes" } ] } ] } } ``` # Frameworks {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ### Request model URL query parameters may be used for [Pagination](/reference/pagination). * `page`\ **Integer**. Page number to retrieve (starts at 1). Used for pagination when results exceed the page size. * `pageSize`\ **Integer**. Number of items per page (maximum 100). Used for pagination to control the number of results returned. ### Example request ``` > Authorization: Bearer IIeDIrdnYo2ngwDQYJKoZIhvcNAQELBQAwSDEZMBcGA1UEAwwQaVNIQ GET /frameworks?page=1&pageSize=20 ``` ### Response model **Decoded frameworksToken parameters:** The model of the `frameworksToken` JWT response is [available on the iSHARE OpenAPI documentation](https://openapi.ishare.eu/index.html?version=3.0#/jwtPayloadFrameworksToken). The model contains the following attributes: * Standard [iSHARE JWT attributes](/reference/ishare-jwt): `aud`, `iss`, `sub`, `exp`, `iat`, `jti` * The `frameworksInfo` object containing: * [Pagination attributes](/reference/pagination) `currentPage`, `pageSize`, `totalPages`, `totalCount` and `count.` Contained in frameworksInfo. * The `data` object, containing an **array of framework objects** with the following attributes: * `id` (Required)\ **String**. Contained in framework object.\ Unique ID of the framework. Format is unspecified. * `title` (Required)\ **String**. Contained in framework object.\ Title of framework. * `defUrl`\ **String**. Contained in framework object.\ URL pointing to the framework definition. * `website`\ **String**. Contained in framework object\ Website address of the framework. * `frameworkOwner`\ **String**. Contained in framework object\ Name of the owner of the framework. This is typically legal entity (company, association, foundation) that governs the framework and its operations. * `frameworkOwnerId`\ **String**. Contained in framework object\ Unique ID of the owner of the framework. This is expected to be a Decentralized Identifier (DID) that uniquely identifies the governing body. * `tags`\ **String**. Contained in framework object\ Free text field for adding relevant tags that are relevant in the context of framework. It useful for searching for specific frameworks based on tags. * `agreements`\ **Array of objects.** Contained in framework object\ Array of agreements that are relevant in the context of the dataspace. * `id` (Required)\ **String**. Contained in agreement object\ ID of the agreement. * `title` (Required)\ **String**. Contained in agreement object\ Title of the agreement. * `required` (Required)\ **Boolean**. Contained in agreement object\ Whether accepting the agreement is required to join the framework. * `versions`\ **Array of objects**. Contained in framework object\ Array of official versions of the framework. * `version` (Required)\ **String**. Contained in version object\ Identifier of the version. * `status` (Required)\ **String**. Contained in version object\ Status of the version. Available values are active, planned and deprecated. * `roles`\ **Array of objects**. Contained in framework object\ Array of roles that are declared in the framework. * `id` (Required)\ **String**. Contained in role object\ ID of the role. * `title` (Required)\ **String**. Contained in role object\ Title of the role. * `x509CertificateRequired`\ **String**. Contained in role object\ Whether a participant in this role is required to have an x.509 certificate. May be yes or no. * `agreements`\ **Array of strings**. Contained in role object\ Array of agreement IDs that a participant in this role is required to accept to join the dataspace. * `loaRequired`\ **String**. Contained in role object\ Whether a participant in this role must provide a Level of Assurance (LoA) statement. May be yes or no. * `technicalComplianceRequired`\ **String**. Contained in role object\ Whether a participant in this role must provide a technical compliance statement. May be yes or no. ### Example response The response contains an encoded JWT, which looks like this: ```json < Content-Type: application/json { "frameworksToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHa0RDQ0JIaWdBd0lCQWdJVUpYckNOdm56eTV5alU5V0ErTmprQzNPekdpSXdEUVlKS29aSWh2Y05BUUVMQlFBd1hURWVNQndHQTFVRUF3d1ZaVWxFUVZObFUwVkJURTlKUkY5SmMzTkRRVWMwTVJrd0Z3WURWUVJoRXhCT1ZGSk9UQzFwVTBoQlVrVlVSVk5VTVJNd0VRWURWUVFLRXdwcFUwaEJVa1ZVWlhOME1Rc3dDUVlEVlFRR0V3SllXREFlRncweU5ERXhNRFl4TkRNeU1URmFGdzB5TnpFeE1EWXhORE15TVRCYU1HNHhDekFKQmdOVkJBWVRBazVNTVNJd0lBWURWUVFLREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVNJd0lBWURWUVFEREJsVVpYTjBJRkJoY25ScFkybHdZVzUwSUZKbFoybHpkSEo1TVJjd0ZRWURWUVJoREE1T1ZGSk9UQzB4TURBd01EQXdNRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMVHNBRWVBVWs5NUI2bHZkZ1hPcjRoekUxTjJRL2E1UmUwcmsvZEJiRmZCTVBEMWN0ekVMeHJ4a0hLSEFKWjBNZmxjOWdPMitYMjdIVkRoUHF3SkZ1ZWg0VTlpend5dnF6czFWRys5U1Fzbnd6V1p5Q1RQNDBsWGx2cUtHMWtyVWlmRjJsRjNMSmVRRml3UmRSd2txZzRPM2dSU2RvTmdFU0hjOVJReVZTMHNPQUhLVlh4em1rS0NON2FTcGE3bVBVQ290SWVSRmIydFV2R1hiNWxOUUJoejdPd01jQW1NVjU4N3V6VWxuZFZLc0EwbU40UGtySWZQWjNWVmVZOHF1clByTHNPWFBYbVJyRjArWFZmcHoyeGJDMDc2M1M1bHI2VWlrNmJhWE9kQ2NWczd0MWIvNzhaTWV0NEMzVzFuS0dFYmVtcGxidjBoYXpMdUdlbExYV2tDQXdFQUFhT0NBalV3Z2dJeE1BNEdBMVVkRHdFQi93UUVBd0lHUURBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkxNYVQwSkE2ZGg0bld2Ly9DU3dFTEUwUFBDSk1GY0dDQ3NHQVFVRkJ3RUJCRXN3U1RCSEJnZ3JCZ0VGQlFjd0FZWTdhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2YzNSaGRIVnpMMjlqYzNBd0VBWURWUjBnQkFrd0J6QUZCZ05WSFNBd0h3WURWUjBsQkJnd0ZnWUlLd1lCQlFVSEF3UUdDaXNHQVFRQmdqY0tBd3d3V3dZSUt3WUJCUVVIQVFNRVR6Qk5NQk1HQmdRQWprWUJCakFKQmdjRUFJNUdBUVlDTURZR0NDc0dBUVVGQndFRERDcFVhR2x6SUdseklIUmxjM1FnWlhObFlXd2dZMlZ5ZEdsbWFXTmhkR1VnWm05eUlIUmxjM1JwYm1jd0hnWUZaNEVNQXdFRUZUQVRFd05PVkZJVEFrNU1EQWd4TURBd01EQXdNRENCeHdZRFZSMGZCSUcvTUlHOE1JRzVvSUcyb0lHemhvR3dhSFIwY0hNNkx5OWpZVGN1YVhOb1lYSmxkR1Z6ZEM1dVpYUTZPRFEwTWk5bGFtSmpZUzl3ZFdKc2FXTjNaV0l2ZDJWaVpHbHpkQzlqWlhKMFpHbHpkRDlqYldROVkzSnNKbWx6YzNWbGNqMURUaVV6UkdWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5DVXlRMjl5WjJGdWFYcGhkR2x2Ymtsa1pXNTBhV1pwWlhJbE0wUk9WRkpPVEMxcFUwaEJVa1ZVUlZOVUpUSkRUeVV6UkdsVFNFRlNSVlJsYzNRbE1rTkRKVE5FV0Znd0hRWURWUjBPQkJZRUZGUDZERGMvK2Qya2ZJcm1uSkF1VDc0ODEzY2JNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUNBUUJIcDVXWGk4Vk5vRDBNYzhicnNmS213dXVRbjVhUEdQWWgrejVQY1FXelI0MEh2TzFGZTl2b3laTlp1Vk5xcENFSmNJMDRPZUJlWm9uL2x6WW9URkdTTENTUHBaeTkyaHFmaGE0SnJMa0p2RjAwaTdvSU81SFNjay9KUXhqdWFHdW1xMHVRMDJhQTZtRjNXYjlaV2tyaElvWFJVcFNpZ0c0a01Kc0MyclZkZlhpejZVUGRqdktLNWszYThCSXpmZkc3MGdKRFBqMCtzSXpjcHhacmUrTVBFSW56QkRtUWdrYmtsL1JYNFJEaG5TMWovNEI2VHNoYjJSZW1BM3E2YkFZb045SWhLbGhGdU1kOXovTUlwbkRwU3dIaElyaG5tUlpVLzRDQkVwdGF0NE1VRXRScWkyUUU1SDhQRU1MbFQvNTZwYW5uaW15RnlRTlNJeGJUcHVjSlEzeUkzUElUb0xLZ3pOY2dUVGlpaGFla3R2dHoydWorVWtkbjAwM2ZhekYzTlF2VUU3Y3g5RjdUV0JEbWs0aEdkQS9Qb2ZWQUFUeXAwVHU3a1dMZ3ZoblNNVEc4eWxpZG1ZY3FSVE1GaVNpWGhid0l1QnU4NXl5QWVXSkpvcGpPOUlBVUNxZ3FtTlNCS05WbWhFekViazhtMW9yYkRVZ2grWkFHU2FqZyt3U0FjMWduT2RqMWlKay81TDFDTHlWNmlVYlMvejY1Z2kzN3dTeW1hc2wvcE9nOUpCeGJGU3dpUER1VTY1NGh2WDFpYWpDL0gyS3JER1RXaTVMaGJ6RFRjd0JUbWhjcTZHOVpOeG8rOVlvTmxkdWVsWHAwd1ZJRzJaOU9FZ1kvcUZ2bE5xL1R6RzBSVnVvZ3Ezd2dSbU5sZ3hQU3YyQjlUYTNFREdUbGs0TlZtQT09IiwiTUlJRjJqQ0NBOEtnQXdJQkFnSVVQRzMrVEFueFZPQmNlOU5hUHQ5cFRBZ201UjR3RFFZSktvWklodmNOQVFFTEJRQXdRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RBZUZ3MHlNekE0TWpVd09UQXhNekphRncwME9EQTRNalV3T1RBd01EVmFNRjB4SGpBY0JnTlZCQU1NRldWSlJFRlRaVk5GUVV4UFNVUmZTWE56UTBGSE5ERVpNQmNHQTFVRVlSTVFUbFJTVGt3dGFWTklRVkpGVkVWVFZERVRNQkVHQTFVRUNoTUthVk5JUVZKRlZHVnpkREVMTUFrR0ExVUVCaE1DV0Znd2dnSWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUNEd0F3Z2dJS0FvSUNBUURhblVnTTEvUFF5WE5UWCtVT0xHclpqUzhIYVRXUi9QNHhEOFNNQ1J4T1hIS3pITFFxRVFPdUhEL3crcng5L2JFd3pINHdWZkowbTYvcjU2S09nMHdMVWxWd095aWtPWEdvSVREMnUrVWk5dDI0dFlJa3g4empMRzdWSFZjdzRkWE90OTJzdktZMUx5YnZscHJvV3pUSGxSd29JTzFZUTRoTytyeWJzdy9LRURFWFVia293amxIQVBjd25zT1c2NDM2N0VOK2V6VDFzUzhkekZJeG1HOHFDMkxyTTJzWEpXcXE1dkplRS84NlRmWjJOTU8rQ1V4a2pqN3VQZ2JXMlYvTU9VaFl5QXRHQWp6ZC9Ld09yTE1STVlhWE9JajYxbThSNzFuaC9MVjluOGRuajB3VFFPTlRIaHVNN21kWlF4aHFPZGtMMmNrU3JCV2kzYXRFVlQxT2hCUlg0Rm1taElobVNXdUN0Z3lLaURDSW90eUdBc1gybzY4MTdmZWU0UmR0d2Z3OVE0b04zTkFodG9kNjBpT0FXQXBWdCtCVDV0dmRnR09ZV1BjYk1SNXBHemJwMzhkR1V5dXdZWlY0TEFuSUdTbTV5YXVjTkUyRTJ4clFDYkVlWm00UlBzeDVKbGVXemlways0MmQ3dnF2V0Q4OElRY1ErYlpNMlg0ckpCWk5zMTY2Q2x4K202SG1LeEtBTGViVXRqc3pzZ3lIOGNxMTBkK2s0QW84b0NhT1lqdjJJYUViTWQrZlYvVWY4a1BrelR0S2x0dGRxaWl4b0lxeWNYTUVnQmFTZ2t1YjdYb1E2SzI2dFJQSjB3NVFrdXVoM01LdEdFV2ZXN0VFR21wbkNxak92Ni9yQU1KaU1XeWgxSWdMZ05CVVBQN3phVlBwREF0Qzg4T1NKUUlEQVFBQm80R3NNSUdwTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFFd0h3WURWUjBqQkJnd0ZvQVU0dWJYMHA2RFZqTjlES3RPV1dNWUFzK0h4ZFF3R0FZRFZSMGdCQkV3RHpBRkJnTlZIU0F3QmdZRVZSMGdBREFwQmdOVkhTVUVJakFnQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRR0Npc0dBUVFCZ2pjS0F3d3dIUVlEVlIwT0JCWUVGTE1hVDBKQTZkaDRuV3YvL0NTd0VMRTBQUENKTUE0R0ExVWREd0VCL3dRRUF3SUJCakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBWnY1R3VreDBQRXZWUkVJdDhNVGFQZkNINGF3eWlpWXlpMTdoNlI1TExrMXJlcndRc1NTU0hmVnFmdGR3UkYwb2NMcDJQWEpoZTA3NXFWNDA2QzA0Q2phbU5rM2V6OVppTkhDTmpQdGZpZDZvT3hxejFYazhYUGpOWUVsYkFGbVA3ZUtsLzQ0MXZaaEd1ay9SaFhHTnhRYnRvMFExNmc4SVJjR0R2V2dOaHRydEIxRzJ4U210QjFTMnVVcFNhaVpWTk9ya2R6VGhpRUpzZVVSQm9YeFVYSXFwTHlQVFJsNk1NZ1ZhTEdSWVJjM3ZZaWo0QjdNMmhCTjcvY2puR0xzTVZ0Z2JPdjZDVjIxZzJTWG93YmdPcXpCeUg1MVVUUjZPYkhpR2owa1NDQUxHMTRJUVBrelFQaVNwanUrKzlNMmpBalBNM280MjFaT1VETVAyNDZDc3FQWHJUQWJQWEpWVVIvZ2k0dTUza216QzIxMGp2VnE5aEh3ZWx4UU9UUEZobE02RTFDaDRKYjRQUVJMS0RQRmwrNU5XNEZ5MkpBRGp5dXB5VkhuY2RMRXVQeTBQZ0NMMllvMTQ3SFNwUGo0dTdqYzFSbUhVN05PMTJFVjJaQ01mRmxSd2RHdjZpZjhxTzdzLzZscFpKanBQdExFT2JBNXRENGFoYythUE5BaTlXQ2swcGVSbTFLRTVWR0RXS0ZOU05BaUxKTnpQN20yUTZ5OGZPeTM4Y05nRkJoR09GL0tnRUlzVDEwVis1SzVvK3lsVlZ0UFZlUlJFTkV2S085RUxremUwSUhnc1RCLzZjd09pajRweE05SnZhdWowNkdnbGhJaGlJQTZxMGlEVXFCMU1VUjBIemlZOUJzbldZOWtSOGh3VjNPVytuc216dFF3R1ZFdzJralU9IiwiTUlJRmpqQ0NBM2FnQXdJQkFnSVVGajkvM2pHT1JodElwWjk4T0xSdFJIczBBWXN3RFFZSktvWklodmNOQVFFTEJRQXdRVEVkTUJzR0ExVUVBd3dVWlVsRVFWTmxVMFZCVEU5SlJGOVNiMjkwUnpJeEV6QVJCZ05WQkFvVENtbFRTRUZTUlZSbGMzUXhDekFKQmdOVkJBWVRBbGhZTUI0WERUSXpNRGd5TlRBNU1EQTBORm9YRFRRNE1EZ3lOVEE1TURBd05Wb3dRakVlTUJ3R0ExVUVBd3dWWlVsRVFWTmxVMFZCVEU5SlJGOVRkV0pEUVVjek1STXdFUVlEVlFRS0V3cHBVMGhCVWtWVVpYTjBNUXN3Q1FZRFZRUUdFd0pZV0RDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTDduemt5b0ZYV2cxZ2hkRzZmbnV6dXZBZE1Xc20vSSttWDNEYnozSS9LeXFMZFd0N1hHM09XVlNuaG9zQUQyVzJTWG5sR1hxeHllMGhQdEVna1FJZGVsN0ZuRm9zV1dyc0VPcmF0Z1hsbk00TldwWURLTVdFVllybzdoekhnQ1oxMjZaUFFVTGxzNTJOY3ZwUk04UzNkWmsrWEsxa2YzVmVTMEoyaFVTRkVBWkhMeVhDWGtoVG5VSTdxbzF1cjFUbURXWXNOUXd4REdPdTdDUXlaWWRLSXdLcUk5ZUdzUkxnTTZQUWxnM3ZaQ3JvcE9vZE03bG9UdWlyQ2wzVUt3NEhyR2syY09pQWY0SWQvL2VhVkNhZndraktzSlRRdUFhaHVSejRxTXNIWUEza0RReiswK2hnblI3NHIraUxyKzhscjA0NGdsbmFXSVd2ckVHY2lSUitQZWN0ZnJMT1FRSVc3aGExM2R6V296a1QwYWduVDFMay9DR3JnTlhWcWhvc0dDMHJ1QVFQSTZEY1BOeTJJTk05Smd0Q21Cc1NqTU0xODVGSUJYNEN5MTdtNzNoOXJLalhaTXhiNlR4WDdDSVp5ZXNnQVMwYkJSYjZ4SXBLc1pybHJqRWF6c2pDMlZIUlJXT01KV1lxY1hMRDVaTnpHTVpVcjZUdDJ5Q1VBdGFtZWNEQVRLTjYvR2JzeGUwdEFCTjBwazByeDVpYys0VFhkQnJvTjlPQVpjaEg0dEpDc09DS29uQ3pBcFB4VlRoRE5NeHNvb3lGcTlEbWdYaHlFVU9Pb2VTK0ZyNEZnSCtqU0FObS9sMTc4Smg5ZXBmWFE5Z0UvNmFxUHhZak5TQmdTNjBTMUVWcUNweHcyclQxbVVZZUdmd2liVm01M2l4R3B0UjhrdGU3MG5BZ01CQUFHamZUQjdNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdId1lEVlIwakJCZ3dGb0FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0dBWURWUjBnQkJFd0R6QUZCZ05WSFNBd0JnWUVWUjBnQURBZEJnTlZIUTRFRmdRVTR1YlgwcDZEVmpOOURLdE9XV01ZQXMrSHhkUXdEZ1lEVlIwUEFRSC9CQVFEQWdFR01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQjhqcVlVdzdUditXNFpIMDZQcmFGNnpmZEN4VDAzRGhSQ2h3NFovUW0wWFZTMmdSeVJ3Y01wdFFGRVJoUE5PQTIyMXU5THFveloxYUszQjM1d2tjR0QvZEZKZ0pDSkI5NlNNdHRRbDJIcC9FaVF6OVBGRjAyZEJTcnVYaElhcmFQYk0rTklHZG15TjJaeXdHR1hJMWFVN0pEM1hHMjlTaDJBQWRPa3Y4ZEk2Z0VnenQvREhTSUliYWtiYUxkRUljN1dCOTVHVUhjSG5OajU4VHpUU3lWZkJtdGIzdkJLOUpHMElvNk5BUFdRWXgyVlA4K2ZJeWxqYTJkMTI4aGdoMGRzRHJYRkFNKzlBWDhoYWU1dnZ4Vmk4VFdzL3oyaW5nK2sraW1tdFNOZnp6S01pTzdyNXdKQWt5and0VUJsQlN0S0lBNlplcjIycG1TVFpaZXVjSGRFVGhhYmNXUWlkVlptTVAzSWY2aXg1VWV5WDhWNk9BdzBnc0kzSVViOTFRNzZkNHNMV2J6b0dOT05BWUZDMUl5ejB4V2o0N1pkNlA3WjJHZmgxVmlJYk14VmlGRGxObWJFWmZscEVTODdLL3loQlVRL3RuQ05HUW9TZHRzdXl1V2czTmZXYnlKb05aemxVOTZKV3hjcVNhWGt6c2U5ajh3YWhheUtOTTZTV0tTWTFaMDVoOEpTY09DbUZCNUY4VjNiZDVuUC91S2phN0g4TzRHT0FBUE0zT3RHK2VxMzd4Vy94TjBvQXNqYnZ0NG9qblViSnMya2lBeEVkd1h4MEs3bWNQZVM3eldtVnQ4aDRSZGNEbS9QR1REYTltOE9xaFF1Y2s4MFFudXhJVVdWcjdHV2FkaDFMeS90bDArYnZta2NuTzJ5YlJKK2dicVJFSERUZTBzeHN3PT0iLCJNSUlGY3pDQ0ExdWdBd0lCQWdJVUN2ZlN2UWVyakZEbU0yTHZtam9URE9JbkxBd3dEUVlKS29aSWh2Y05BUUVMQlFBd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNQjRYRFRJek1EZ3lOVEE1TURBd05sb1hEVFE0TURneU5UQTVNREF3TlZvd1FURWRNQnNHQTFVRUF3d1VaVWxFUVZObFUwVkJURTlKUkY5U2IyOTBSekl4RXpBUkJnTlZCQW9UQ21sVFNFRlNSVlJsYzNReEN6QUpCZ05WQkFZVEFsaFlNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXhWTUtJOVJNaG5PU0EyTG9yZ0VDM1lETmQyaXRuNzJMT2RmUlJVdTQ1Zkc3MEllditFNGtScnpKMWsyM1dYSDVzSFRiY3NscEVUZUFabmowL3hLQllkRUx1d2U2SFg4a0l3ZDFzNldHbFpjMGw3a2kxZm1qNEhxU3N0R0ovQktHajFhNzIzNld3UEpFV0VIcWZ4OVFNRWV1SktsVVNWRkZ5RTRqTXNmWXA4N2lmSXB1d0U4b0xPdzR5a0RET1A1MlRkMDZ2SENJWXJxREJydnhGZEF1RW5GeE54bFBYUkU0Z0xzeWdnNjJIT3hPdUdtaFdmc3k2VGNjSXA1WElPZGoyQ3plb1hKODJtNS9pbUJQSnZrZWZucmpFUVh6aVNFMm1pMklCRHRHUC9Bd0ZXSTdXcHNFeURYV0ltTVNSMFQzQ3VEbWtlUTE0cE5tY3FNcC9icVgzaTFhZXRhZEZUV3N1aGwwbkgyaVJxS1pESnhabFNjdTk5dG9xNUdyZGNGVWN4R1JReWwrc0ZoVWgzWGNCV0pWN1kyd25GTDJ0WTd0aHRROFpQbXpUTzhrUEtDYkVsNVU2Z0NTSWtwUlBOWkJQRzRkVDBxdSs4QmQ3MVB1N25BeTFpQjRVNnlzMzRjRmxPbEpwR00wRkdyMzVMZWZiUFI4Ymd6Nk05WE5qUmJnTURRY1hETW5maURKN0U4MW9WQnBDWE45eWRIaTFibGhha3VFQmFvYTlNL2themlwR1BtQXV4cldCTW1wMnEwd3pRcDlHUzJlOGtlSklEd0p1eXpFTGFSWkM0eWpWc1ZaUU1LLy9EKzRKM2JvVTVkckNtbW02QzFyd05SZlNadUZHTmNJWURaZUh0ZUdvQ0Y0RUE1amNnZEZhSVlyRGVqNlZBYWI0MnZONUxVQ0F3RUFBYU5qTUdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZkJnTlZIU01FR0RBV2dCVFl1NXMxTFZzLzcrRnJ5OHdNejZJdXVtbDZqREFkQmdOVkhRNEVGZ1FVMkx1Yk5TMWJQKy9oYTh2TURNK2lMcnBwZW93d0RnWURWUjBQQVFIL0JBUURBZ0VHTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElDQVFCYmNIeVYyYjVtR3dIV3hDU2JEd3I1VjdQZ1NaSUphMXNjckNuSUhEM1oveXhHN1hwNWNJbEJqNE15NGxSSGpadEpWdlVmVGpGcHNFREV2L1BBcTc0T0lvbE4va1BkTWZUY3pGQkdwdnNacjB4MnlVUEVKelFzVFNMeDBnd1ord3ZvS0hXRTBDN0dxZ2tBQk5yRlc4RkxxUnpOcVhzbU01b0k0YzNWNXN5eHdCWUZEVVk1TVBXZHFKRURmUnZqakpQQ1htS09QMWxPK2krRTA3dnNGcER6SFMyRktCNWM2c1RJWmt2dCtIL0NHNGhWdTZadmNGWFh6djJKSy9Fb1ZaNndVZENsdDRwTGdUUVovVzBxUUNKM0dqRmUvUFo3NG1ja1cxeC96azl6MFZRalVwVHF6M0FqUExJamo2MG5NTFRMcDUwb0ZjTUxqdVhzczB2djR0VWpDVHBzMlFnOW4wR3dMbERSNDJOeXcyVEtjTU1CNnljRW9OaVVFdTBsZ2ExSk0wU1ZTc0ZQN0dTVS9XOVZxYXRLN3hwL1hXOS9HRHZncDNaL3BQTTBFM2kxdHFwL25PVTQzWW9mOFdpNEpKNnpPZ1hCenFReE82TUlMWko0cUVmZW5BdEk3bzk1VHk1eWs5dlJib1VzdHl3c2ZDNkNWc3UwOE5ML3R0dzRPU1hPdmJrUSs3ek14Q1lUOVl5UUQ1bC9sdEMzYmdkai9sQlp6bnNCdUdZTk9CMTZ3RE5jR3B1dWFla3NmUWZCRFBIVCt2UjZnUFZGWnB5Vnd5L3R6SDZOVHBVR0Rqb0hWc0N4VWpZODcwT000RDJKY2o5T0lxcWRsa0NvV082aTRWZWM3c1R6eGlYMzlvTlNyMUc3Q29iYzNzWWRobnhnL3ZsZzFCZUNKODdwMEE9PSJdfQ.eyJmcmFtZXdvcmtzSW5mbyI6eyJjdXJyZW50UGFnZSI6MSwicGFnZVNpemUiOjEwLCJ0b3RhbFBhZ2VzIjoxLCJ0b3RhbENvdW50IjoxLCJjb3VudCI6MSwiZGF0YSI6W3siaWQiOiJpU0hBUkUiLCJ0aXRsZSI6ImlTSEFSRSBGcmFtZXdvcmsiLCJkZWZVcmwiOiJodHRwczovL2ZyYW1ld29yay5pc2hhcmUuZXUiLCJ3ZWJzaXRlIjoiaHR0cHM6Ly93d3cuaXNoYXJlLmV1IiwiZnJhbWV3b3JrT3duZXIiOiJpU0hBUkUgRm91bmRhdGlvbiIsImZyYW1ld29ya093bmVySWQiOiJkaWQ6aXNoYXJlOkVVLk5MLk5UUk5MLTczMDU4Mjg5IiwidGFncyI6IiN0cnVzdGZyYW1ld29yayAjZGF0YXNvdmVyZWlnbnR5ICNkYXRhcmlnaHRzIiwiYWdyZWVtZW50cyI6W3siaWQiOiJUZXJtc29mVXNlIiwidGl0bGUiOiJUZXJtcyBvZiBVc2UiLCJyZXF1aXJlZCI6dHJ1ZX0seyJpZCI6IkFjY2Vzc2lvbkFncmVlbWVudCIsInRpdGxlIjoiQWNjZXNzaW9uIEFncmVlbWVudCIsInJlcXVpcmVkIjp0cnVlfV0sInZlcnNpb25zIjpbeyJ2ZXJzaW9uIjoiMi4yIiwic3RhdHVzIjoiYWN0aXZlIn0seyJ2ZXJzaW9uIjoiMy4wIiwic3RhdHVzIjoiYWN0aXZlIn1dLCJyb2xlcyI6W3siaWQiOiJzZXJ2aWNlUHJvdmlkZXIiLCJ0aXRsZSI6IlNlcnZpY2UgUHJvdmlkZXIiLCJ4NTA5Q2VydGlmaWNhdGVSZXF1aXJlZCI6dHJ1ZSwiYWdyZWVtZW50cyI6WyJUZXJtc29mVXNlIiwiQWNjZXNzaW9uQWdyZWVtZW50Il0sImxvYVJlcXVpcmVkIjp0cnVlLCJ0ZWNobmljYWxDb21wbGlhbmNlIjoieWVzIn0seyJpZCI6InNlcnZpY2VDb25zdW1lciIsInRpdGxlIjoiU2VydmljZSBDb25zdW1lciIsIng1MDlDZXJ0aWZpY2F0ZVJlcXVpcmVkIjpmYWxzZSwiYWdyZWVtZW50cyI6WyJUZXJtc29mVXNlIiwiQWNjZXNzaW9uQWdyZWVtZW50Il0sImxvYVJlcXVpcmVkIjp0cnVlLCJ0ZWNobmljYWxDb21wbGlhbmNlIjoibm8ifV19XX19.eBwCY_K-PSt_DBYLhK2iQoJeQRnMz1LqfK4C-ykju9KMLsN0cvM4y-yy_ZxKUebHUzwZbMBNKImHNwMxmdrdHLhLYYiu8U24A1Cb0-_ZBDKsV7WJeInvGaZ87bspptJ8TDku0NXFHOHVsyQzy3rtD_L91mObgGy3zmaQ0QsrSrQ3VJ3wB0m6PCvQyYlwpYy7flE7lJLq9zMeFGNPXCKywrxVkcchSvI-Iyevxcw6H5CS88mY13w3zG7yFSdhrj7gqvE9Pa3B1Hpz6JoK-FX_Y8b5SrNtehS2xqdzPzhGumEFt9J66iVIwXq_jkwtuyAT2238KXjV4GrIKAgGuYa0Lw" } ``` After decoding, the example content of the JWT looks like this: ```json { "frameworksInfo": { "currentPage": 1, "pageSize": 10, "totalPages": 1, "totalCount": 1, "count": 1, "data": [ { "id": "iSHARE", "title": "iSHARE Framework", "defUrl": "https://framework.ishare.eu", "website": "https://www.ishare.eu", "frameworkOwner": "iSHARE Foundation", "frameworkOwnerId": "did:ishare:EU.NL.NTRNL-73058289", "tags": "#trustframework #datasovereignty #datarights", "agreements": [ { "id": "TermsofUse", "title": "Terms of Use", "required": true }, { "id": "AccessionAgreement", "title": "Accession Agreement", "required": true } ], "versions": [ { "version": "2.2", "status": "active" }, { "version": "3.0", "status": "active" } ], "roles": [ { "id": "serviceProvider", "title": "Service Provider", "x509CertificateRequired": true, "agreements": ["TermsofUse", "AccessionAgreement"], "loaRequired": true, "technicalCompliance": "yes" }, { "id": "serviceConsumer", "title": "Service Consumer", "x509CertificateRequired": false, "agreements": ["TermsofUse", "AccessionAgreement"], "loaRequired": true, "technicalCompliance": "no" } ] } ] } } ``` # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the DCP protocol is supported by the Participant Registry: * [Credential storage (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-storage-dcp) * [Credential issuance (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-issuance-dcp) * [Credential status (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-status-dcp) * [Metadata (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/metadata-dcp) * [Offers (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/offers-dcp) * [Resolution (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/resolution-dcp) # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VC**: * **OpenID4VCI**: Credential Issuance endpoints * **OpenID4VP**: Credential Presentation endpoints # OpenID4VCI Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VCI protocol is supported by the Participant Registry: * [Credential Issuer Metadata (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-issuer-metadata-openid4vci) * [Token Endpoint (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/token-endpoint-openid4vci) * [Credential Endpoint (OpenID4VCI)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vci-endpoints/credential-endpoint-openid4vci) # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VP protocol is supported by the Participant Registry: * [Verifier Metadata (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp) * [Authorization Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/authorization-endpoint-openid4vp) * [Presentation Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/presentation-endpoint-openid4vp) # Getting started This page describes the steps you have to undertake to consume services provided by iSHARE-compliant Service Providers (this page assumes general knowledge of the [iSHARE framework and roles](https://framework.ishare.eu/is/framework-and-roles)). ### Prerequisites Make sure you execute the following steps before trying to consume services provided by Service Providers. 1. **Obtain a valid identity (private key + certificate)** * **Staging:** [Click here](https://ca7.isharetest.net:8442/ejbca/ra/index.xhtml) to request a test certificate. More information on the [Get Test Certificate section](/introduction/getting-started/test-certificates). * **Production:** Acquire a certificate from an eIDAS certificate provider. 2. **Register yourself as an iSHARE Consumer** * **Staging:** If you want to register at a specific Participant Registry, contact the Participant Registry through their communication channels. A registration via the Scheme Owner is also possible: [Contact the Scheme Owner](https://ishare.eu/home/contact/). * **Production:** Register yourself with any Participant Registry using their registration procedure. If you intend to join a data space then you must contact the relevant data space/participant registry in that data space. ### Implementation Every iSHARE Service Provider has implemented 2 standardised endpoints: \* Access Token (M2M) \* Capabilities As an iSHARE Service Consumer, a minimum implementation requires connecting to the Access Token endpoint. For more information about requesting an Access Token, refer to the section about the [Access Token Endpoint](/all-roles-common-endpoints/access-token-m2m). The request includes an iSHARE JWT, which is documented [here](/reference/ishare-jwt). After obtaining an Access Token, this token can be used to consume services from the Service Provider. These services themselves are not standardised by iSHARE. Service Consumer should contact the intended Service Provider to retrieve the requisites of the request For your implementation, choose one of the following scenarios. A combination of scenarios is possible. All scenarios assume that a protected service will be consumed. #### Scenario 1: Minimum implementation The endpoint and specifications of the service that will be consumed are already available. Delegation evidence is acquired by the Service Provider. *Connection with the Service Provider* 1. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 2. Use the Access Token to consume the service
#### Scenario 2: Using the /capabilities endpoint to discover services The endpoints of the service that will be consumed are obtained through the /capabilities endpoint. Further specifications are assumed to be already available. Delegation evidence is acquired by the Service Provider. *Connection with the Service Provider* 1. Consume [/capabilities](/all-roles-common-endpoints/capabilities) endpoint to discover where to get an Access Token 2. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 3. Use the Access Token to consume /capabilities endpoint to discover where to consume services 4. Use the result of the /capabilities endpoint + Access Token to consume services
#### Scenario 3: Perform pre-checks on the Service Provider If the Service Consumer provides data to a Service Provider (i.e. data that belongs to an Entitled Party), for full legal coverage, it is advised to check adherence of the Service Provider before a service is consumed. The implementation would then be as follows. *Connection with Participant Registry* 1. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 2. Use the Access Token to request the /trusted\_list endpoint 3. Validate adherence of the Service Provider by invoking the /parties endpoint, searching for the "id" of the Service Provider that should be used at the Participant Registry. Check if the party can be found, if the certificate is valid (check with the trusted list) and if the party has the role of Service Provider. *Connection with the Service Provider* 1. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 2. Use the Access Token to consume the service
#### Scenario 4: Full implementation, with prechecks and delegation evidence If the Service Consumer wishes to provide delegation evidence to the Service Provider, the minimum implementation is as follows. *Connection with Participant Registry* 1. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 2. Use Access Token to request the [/trusted\_list ](/participant-registry-role/trusted-list)endpoint (also see [Get trusted CA List](/reference/authentication/get-trusted-ca-list)) 3. Discover the Authorisation Registry for the relevant Entitled Party and capability through an implemented discovery mechanism. Validate adherence of the Authorisation Registry by invoking the [/parties ](/participant-registry-role/parties)endpoint, searching for the party\_id of the Authorisation Registry that should be used at the Participant Registry. Check if the party can be found, if the certificate is valid (check with the trusted list) and if the party has the role of Authorisation Registry. 4. Service consumer may also know the ID of Authorisation Registry out of band from Entitled Party and use that to find the capabilities endpoint of that Authorisation Registry from Participant Registry. 5. Validate adherence of the Service Provider by invoking the /parties endpoint, searching for the party\_id of the Service Provider that should be used at the Participant Registry. Check if the party can be found, if the certificate is valid (check with the trusted list) and if the party has the role of Service Provider. *Connection with the Authorisation Registry* 1. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 2. Use the Access Token to invoke the Delegation endpoint to obtain Delegation Evidence *Connection with the Service Provider* 1. [Get Access Token](/all-roles-common-endpoints/access-token-m2m) 2. Use the Access Token and Delegation Evidence to consume the service
The eSEAL Guide can be referred to below. {% embed url="" %} # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the DCP protocol is supported by the Service Consumer (usually by applying wallet technology): * [Credential storage (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-storage-dcp) * [Offers (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/offers-dcp) * [Resolution (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/resolution-dcp) # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VP.** # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VP protocol is supported by the Service Consumer: * [Presentation Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/presentation-endpoint-openid4vp) # Getting started The Service Provider role is fulfilled by a legal entity that provides a service, in the form of data, for consumption by a Service Consumer. This legal entity provides the result of a service that Service Consumer(s) need; for example, the party that uses a truck’s time and location to calculate and communicate the truck’s optimal route and estimated time of arrival. Before requesting delegation evidence, the Service Provider MUST know which Authorisation Registry holds the evidence for that capability. Service Providers could also have that directly registered with them. ## Prerequisites Make sure you execute the following steps before trying to provide as an iSHARE Service Provider. 1. **Obtain a valid identity (private key + certificate)** * **Staging:** [Click here](https://ca7.isharetest.net:8442/ejbca/ra/index.xhtml) to request a test certificate. More information on the [Get Test Certificate section](/introduction/getting-started/test-certificates). * **Production:** Acquire a certificate from an eIDAS certificate provider. 2. **Register yourself as Service Provider** * **Staging:** If you want to register at a specific Participant Registry, contact the Participant Registry through their communication channels. A registration via the Scheme Owner is also possible: [Contact the Scheme Owner](https://ishare.eu/home/contact/). * **Production:** Register yourself with any Participant Registry using their registration procedure, using the [admission process](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/admission). ## Implementation of required endpoints Any Service Provider is required to implement the following endpoints. These endpoints will be the subject of the conformance test, as part of the [admission process](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/admission). * [ ] [Access Token](/all-roles-common-endpoints/access-token-m2m) * [ ] [Capabilities](/all-roles-common-endpoints/capabilities) * [ ] [Return](/service-provider-role/return) (for human-to-machine (H2M) consumption of its services using an Identity Provider) ## Example implementation of a REST endpoint If the Service Provider wants to expose a REST endpoint as part of its services as an iSHARE Service Provider, it can do so following the example implementation given in the following endpoint: * [ ] [Service](/service-provider-role/getting-started/service) # Service This page contains an example implementation for a REST endpoint of a Service Provider, using the token obtained from the iSHARE [/token](/all-roles-common-endpoints/access-token-m2m) endpoint and the delegation evidence obtained from the [/delegation](/authorisation-registry-role/delegation-endpoint) endpoint. ### Delegation path example In certain use cases, it could be relevant to provide information about a delegation path. A delegation path is the delegation of a delegation from one delegated party to another party. The iSHARE Framework does not specify how a delegation path should be provided to a Service Provider. More information about delegation paths is included in the [iSHARE Knowledge Base](https://trustbok.ishare.eu/apply-ishare/authorisation/delegation-chains). An example of how a delegation path could be provided to the Service Provider is by using a header that contains party identifiers of the parties involved in the path. These identifiers can be used to obtain or evaluate a chain of delegation evidence. ``` Delegation-Path: [party-id-entitled-party, party-id-data-consumer, party-id-delegated-consumer, etc.] ``` ## Example endpoint for Service Provider (parameters apply to other HTTP methods as well) > This is an example service (business specific) endpoint to show how any Service Provider that adheres to iSHARE MUST apply iSHARE conformant OAuth to every iSHARE enabled service.\ > Request can make use of any HTTP method and can contain any extra headers. For convenience this documentation only defines the GET method. Parameters are undefined because they vary for each Service Provider due to their business specific logic. Note: Additional headers for security, statefulnes, application functionality could be added and is out of scope of this specification. ```json {"openapi":"3.0.0","info":{"title":"iSHARE API specifications","version":"3.0"},"tags":[{"name":"Service Provider (Example)","description":"Example endpoints for the iSHARE Service Provider API."}],"servers":[{"description":"iSHARE UAT network base domain","url":"https://isharetest.net"},{"description":"iSHARE TEST network base domain","url":"https://test.ishareworks.nl"}],"security":[{"BearerAuth":[]}],"components":{"securitySchemes":{"BearerAuth":{"type":"http","scheme":"bearer","description":"OAuth 2.0 authorization based on bearer token. MUST contain “Bearer “ + access token value. Must be provided if restricted endpoints are needed."}},"parameters":{"delegationEvidenceHeader":{"name":"delegationEvidence","description":"iSHARE delegation evidence regarding the requested service. The Service Consumer can obtain this evidence from an Authorization Registry / Entitled Party before requesting a specific service.","schema":{"type":"string"},"in":"header"},"serviceConsumerIdTokenSc":{"name":"serviceConsumerAssertion","description":"iSHARE specific optional client assertion. Used when a Service Consumer is requesting a service on behalf of another Service Consumer in a 'service broker' pattern. It is used to prove that the 'brokering' Service Consumer indeed has had a request from the original Service Consumer","schema":{"type":"string"},"in":"header"},"purpose":{"name":"LicensePurpose","description":"Optional iSHARE specific value describing the purpose of the license the Service Consuming Entity requests for the data in the service response","schema":{"type":"string"},"in":"header"},"serviceHeaders":{"name":"Service-Headers","description":"Any service specific headers","schema":{"type":"string"},"in":"header"}},"schemas":{"serviceContent":{"properties":{"serviceContent01":{"type":"string"},"serviceContentXX":{"type":"string"}}}}},"paths":{"/service":{"get":{"tags":["Service Provider (Example)"],"parameters":[{"$ref":"#/components/parameters/delegationEvidenceHeader"},{"$ref":"#/components/parameters/serviceConsumerIdTokenSc"},{"$ref":"#/components/parameters/purpose"},{"$ref":"#/components/parameters/serviceHeaders"}],"responses":{"200":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/serviceContent"}}},"description":"OK"},"401":{"description":"authentication is required and has failed or has not yet been provided."}},"operationId":"service-example","summary":"Example endpoint for Service Provider (parameters apply to other HTTP methods as well)","description":"This is an example service (business specific) endpoint to show how any Service Provider that adheres to iSHARE MUST apply iSHARE conformant OAuth to every iSHARE enabled service.\nRequest can make use of any HTTP method and can contain any extra headers. For convenience this documentation only defines the GET method. Parameters are undefined because they vary for each Service Provider due to their business specific logic. Note: Additional headers for security, statefulnes, application functionality could be added and is out of scope of this specification."}}}} ``` # Return {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ## Receiving the redirect from the Identity Provider > OpenID Connect 1.0 endpoint for receiving the redirect from the Identity Provider or Identity Broker after successful human authentication. ```json {"openapi":"3.0.0","info":{"title":"iSHARE API specifications","version":"3.0"},"tags":[{"name":"Service Provider (Required)","description":"Required endpoints for the iSHARE Service Provider API."}],"servers":[{"description":"iSHARE UAT network base domain","url":"https://isharetest.net"},{"description":"iSHARE TEST network base domain","url":"https://test.ishareworks.nl"}],"paths":{"/return":{"get":{"tags":["Service Provider (Required)"],"operationId":"handle-authorization-return","summary":"Receiving the redirect from the Identity Provider","description":"OpenID Connect 1.0 endpoint for receiving the redirect from the Identity Provider or Identity Broker after successful human authentication.","parameters":[{"name":"code","in":"query","description":"Authorization code which is going to be used to request for an access token. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once.","required":true,"deprecated":false,"schema":{"type":"string"}},{"name":"state","in":"query","description":"OpenID Connect 1.0 opaque value used to maintain state between the request and the callback. The Service Provider needs to verify if initially sent value towards authorize endpoint is equal to this returned value.","required":true,"deprecated":false,"schema":{"type":"string"}}],"responses":{"200":{"description":"On successful user redirect to the Service Provider, the Service Provider needs to verify state parameter and make use of code parameter in order to retrieve the access token. There are no specific response requirements for this endpoint."},"400":{"description":"bad request or request is malformed"}}}}}} ``` {% hint style="info" %} Not bound to name *return*. May have any name the Service Provider chooses. {% endhint %} #### Example ``` GET /return? code=Dmn-TbSj7OcKl5ym1j5xZsgkabzVP8dMugC81nzmeW4& state=ZqVQm4zHaEDyBhzpm1ZRH7fsxy703lq2 ``` # M2M Verifiable Credential Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the DCP protocol is supported by the Service Consumer (usually by applying wallet technology): * [Credential storage (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/credential-storage-dcp) * [Offers (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/offers-dcp) * [Resolution (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/resolution-dcp) # H2M Verifiable Credential Endpoints This section groups all Human-to-Machine (H2M) Verifiable Credential endpoints in the iSHARE framework. Section for dataspaces who implement credential issuance and presentation using **OpenID4VP.** # OpenID4VP Endpoints {% hint style="info" %} Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments. {% endhint %} The following endpoints must be provided if the OpenID4VP protocol is supported by the Service Provider: * [Verifier Metadata (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/verifier-metadata-openid4vp) * [Authorization Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/authorization-endpoint-openid4vp) * [Presentation Endpoint (OpenID4VP)](/all-roles-common-endpoints/h2m-verifiable-credential-endpoints/openid4vp-endpoints/presentation-endpoint-openid4vp) # iSHARE JWT {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} The following section describes the requirements for an iSHARE Signed JWT. ## JWT Signing (JWS) All iSHARE JWTs MUST be signed using the JSON Web Signature (JWS) standard, which can be found at [RFC 7515](https://tools.ietf.org/html/rfc7515). ## JWT Header * Signed JWTs MUST use and specify the `RS256`, `RS384` or `RS512` algorithm in the `alg` header parameter. * Signed JWTs MUST contain an array of the complete certificate chain that should be used for validating the JWT’s signature in the x5c header parameter, including the root certificate of the issuing CA that is listed in the [iSHARE Trusted List](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/ishare-satellite-role/trusted-list.md). * Certificates MUST be formatted as base64 encoded DER without headers and footers. * The certificate of the client MUST be the first in the array, and the root certificate MUST be the last. * The JWT header MUST contain alg, typ and x5c header parameters. It MAY contain additional parameters in the header. If these additional parameters are not understood, they shall be ignored. Example JWT Header: ```json { "alg": "RS256", "typ": "JWT", "x5c": [ "MIIGkDCCBHigAwIBAgIUJXrCNvnzy5yjU9WA+NjkC3OzGiIwDQYJKoZIhvcNAQELBQAwXTEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9Jc3NDQUc0MRkwFwYDVQRhExBOVFJOTC1pU0hBUkVURVNUMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDAeFw0yNDExMDYxNDMyMTFaFw0yNzExMDYxNDMyMTBaMG4xCzAJBgNVBAYTAk5MMSIwIAYDVQQKDBlUZXN0IFBhcnRpY2lwYW50IFJlZ2lzdHJ5MSIwIAYDVQQDDBlUZXN0IFBhcnRpY2lwYW50IFJlZ2lzdHJ5MRcwFQYDVQRhDA5OVFJOTC0xMDAwMDAwMDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTsAEeAUk95B6lvdgXOr4hzE1N2Q/a5Re0rk/dBbFfBMPD1ctzELxrxkHKHAJZ0Mflc9gO2+X27HVDhPqwJFueh4U9izwyvqzs1VG+9SQsnwzWZyCTP40lXlvqKG1krUifF2lF3LJeQFiwRdRwkqg4O3gRSdoNgESHc9RQyVS0sOAHKVXxzmkKCN7aSpa7mPUCotIeRFb2tUvGXb5lNQBhz7OwMcAmMV587uzUlndVKsA0mN4PkrIfPZ3VVeY8qurPrLsOXPXmRrF0+XVfpz2xbC0763S5lr6Uik6baXOdCcVs7t1b/78ZMet4C3W1nKGEbemplbv0hazLuGelLXWkCAwEAAaOCAjUwggIxMA4GA1UdDwEB/wQEAwIGQDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFLMaT0JA6dh4nWv//CSwELE0PPCJMFcGCCsGAQUFBwEBBEswSTBHBggrBgEFBQcwAYY7aHR0cHM6Ly9jYTcuaXNoYXJldGVzdC5uZXQ6ODQ0Mi9lamJjYS9wdWJsaWN3ZWIvc3RhdHVzL29jc3AwEAYDVR0gBAkwBzAFBgNVHSAwHwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwWwYIKwYBBQUHAQMETzBNMBMGBgQAjkYBBjAJBgcEAI5GAQYCMDYGCCsGAQUFBwEDDCpUaGlzIGlzIHRlc3QgZXNlYWwgY2VydGlmaWNhdGUgZm9yIHRlc3RpbmcwHgYFZ4EMAwEEFTATEwNOVFITAk5MDAgxMDAwMDAwMDCBxwYDVR0fBIG/MIG8MIG5oIG2oIGzhoGwaHR0cHM6Ly9jYTcuaXNoYXJldGVzdC5uZXQ6ODQ0Mi9lamJjYS9wdWJsaWN3ZWIvd2ViZGlzdC9jZXJ0ZGlzdD9jbWQ9Y3JsJmlzc3Vlcj1DTiUzRGVJREFTZVNFQUxPSURfSXNzQ0FHNCUyQ29yZ2FuaXphdGlvbklkZW50aWZpZXIlM0ROVFJOTC1pU0hBUkVURVNUJTJDTyUzRGlTSEFSRVRlc3QlMkNDJTNEWFgwHQYDVR0OBBYEFFP6DDc/+d2kfIrmnJAuT74813cbMA0GCSqGSIb3DQEBCwUAA4ICAQBHp5WXi8VNoD0Mc8brsfKmwuuQn5aPGPYh+z5PcQWzR40HvO1Fe9voyZNZuVNqpCEJcI04OeBeZon/lzYoTFGSLCSPpZy92hqfha4JrLkJvF00i7oIO5HSck/JQxjuaGumq0uQ02aA6mF3Wb9ZWkrhIoXRUpSigG4kMJsC2rVdfXiz6UPdjvKK5k3a8BIzffG70gJDPj0+sIzcpxZre+MPEInzBDmQgkbkl/RX4RDhnS1j/4B6Tshb2RemA3q6bAYoN9IhKlhFuMd9z/MIpnDpSwHhIrhnmRZU/4CBEptat4MUEtRqi2QE5H8PEMLlT/56pannimyFyQNSIxbTpucJQ3yI3PIToLKgzNcgTTiihaektvtz2uj+Ukdn003fazF3NQvUE7cx9F7TWBDmk4hGdA/PofVAATyp0Tu7kWLgvhnSMTG8ylidmYcqRTMFiSiXhbwIuBu85yyAeWJJopjO9IAUCqgqmNSBKNVmhEzEbk8m1orbDUgh+ZAGSajg+wSAc1gnOdj1iJk/5L1CLyV6iUbS/z65gi37wSymasl/pOg9JBxbFSwiPDuU654hvX1iajC/H2KrDGTWi5LhbzDTcwBTmhcq6G9ZNxo+9YoNlduelXp0wVIG2Z9OEgY/qFvlNq/TzG0RVuogq3wgRmNlgxPSv2B9Ta3EDGTlk4NVmA==", "MIIF2jCCA8KgAwIBAgIUPG3+TAnxVOBce9NaPt9pTAgm5R4wDQYJKoZIhvcNAQELBQAwQjEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9TdWJDQUczMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDAeFw0yMzA4MjUwOTAxMzJaFw00ODA4MjUwOTAwMDVaMF0xHjAcBgNVBAMMFWVJREFTZVNFQUxPSURfSXNzQ0FHNDEZMBcGA1UEYRMQTlRSTkwtaVNIQVJFVEVTVDETMBEGA1UEChMKaVNIQVJFVGVzdDELMAkGA1UEBhMCWFgwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDanUgM1/PQyXNTX+UOLGrZjS8HaTWR/P4xD8SMCRxOXHKzHLQqEQOuHD/w+rx9/bEwzH4wVfJ0m6/r56KOg0wLUlVwOyikOXGoITD2u+Ui9t24tYIkx8zjLG7VHVcw4dXOt92svKY1LybvlproWzTHlRwoIO1YQ4hO+rybsw/KEDEXUbkowjlHAPcwnsOW64367EN+ezT1sS8dzFIxmG8qC2LrM2sXJWqq5vJeE/86TfZ2NMO+CUxkjj7uPgbW2V/MOUhYyAtGAjzd/KwOrLMRMYaXOIj61m8R71nh/LV9n8dnj0wTQONTHhuM7mdZQxhqOdkL2ckSrBWi3atEVT1OhBRX4FmmhIhmSWuCtgyKiDCIotyGAsX2o6817fee4Rdtwfw9Q4oN3NAhtod60iOAWApVt+BT5tvdgGOYWPcbMR5pGzbp38dGUyuwYZV4LAnIGSm5yaucNE2E2xrQCbEeZm4RPsx5JleWzipk+42d7vqvWD88IQcQ+bZM2X4rJBZNs166Clx+m6HmKxKALebUtjszsgyH8cq10d+k4Ao8oCaOYjv2IaEbMd+fV/Uf8kPkzTtKlttdqiixoIqycXMEgBaSgkub7XoQ6K26tRPJ0w5Qkuuh3MKtGEWfW7EEGmpnCqjOv6/rAMJiMWyh1IgLgNBUPP7zaVPpDAtC88OSJQIDAQABo4GsMIGpMBIGA1UdEwEB/wQIMAYBAf8CAQEwHwYDVR0jBBgwFoAU4ubX0p6DVjN9DKtOWWMYAs+HxdQwGAYDVR0gBBEwDzAFBgNVHSAwBgYEVR0gADApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwHQYDVR0OBBYEFLMaT0JA6dh4nWv//CSwELE0PPCJMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAZv5Gukx0PEvVREIt8MTaPfCH4awyiiYyi17h6R5LLk1rerwQsSSSHfVqftdwRF0ocLp2PXJhe075qV406C04CjamNk3ez9ZiNHCNjPtfid6oOxqz1Xk8XPjNYElbAFmP7eKl/441vZhGuk/RhXGNxQbto0Q16g8IRcGDvWgNhtrtB1G2xSmtB1S2uUpSaiZVNOrkdzThiEJseURBoXxUXIqpLyPTRl6MMgVaLGRYRc3vYij4B7M2hBN7/cjnGLsMVtgbOv6CV21g2SXowbgOqzByH51UTR6ObHiGj0kSCALG14IQPkzQPiSpju++9M2jAjPM3o421ZOUDMP246CsqPXrTAbPXJVUR/gi4u53kmzC210jvVq9hHwelxQOTPFhlM6E1Ch4Jb4PQRLKDPFl+5NW4Fy2JADjyupyVHncdLEuPy0PgCL2Yo147HSpPj4u7jc1RmHU7NO12EV2ZCMfFlRwdGv6if8qO7s/6lpZJjpPtLEObA5tD4ahc+aPNAi9WCk0peRm1KE5VGDWKFNSNAiLJNzP7m2Q6y8fOy38cNgFBhGOF/KgEIsT10V+5K5o+ylVVtPVeRRENEvKO9ELkze0IHgsTB/6cwOij4pxM9Jvauj06GglhIhiIA6q0iDUqB1MUR0HziY9BsnWY9kR8hwV3OW+nsmztQwGVEw2kjU=", "MIIFjjCCA3agAwIBAgIUFj9/3jGORhtIpZ98OLRtRHs0AYswDQYJKoZIhvcNAQELBQAwQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMB4XDTIzMDgyNTA5MDA0NFoXDTQ4MDgyNTA5MDAwNVowQjEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9TdWJDQUczMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL7nzkyoFXWg1ghdG6fnuzuvAdMWsm/I+mX3Dbz3I/KyqLdWt7XG3OWVSnhosAD2W2SXnlGXqxye0hPtEgkQIdel7FnFosWWrsEOratgXlnM4NWpYDKMWEVYro7hzHgCZ126ZPQULls52NcvpRM8S3dZk+XK1kf3VeS0J2hUSFEAZHLyXCXkhTnUI7qo1ur1TmDWYsNQwxDGOu7CQyZYdKIwKqI9eGsRLgM6PQlg3vZCropOodM7loTuirCl3UKw4HrGk2cOiAf4Id//eaVCafwkjKsJTQuAahuRz4qMsHYA3kDQz+0+hgnR74r+iLr+8lr044glnaWIWvrEGciRR+PectfrLOQQIW7ha13dzWozkT0agnT1Lk/CGrgNXVqhosGC0ruAQPI6DcPNy2INM9JgtCmBsSjMM185FIBX4Cy17m73h9rKjXZMxb6TxX7CIZyesgAS0bBRb6xIpKsZrlrjEazsjC2VHRRWOMJWYqcXLD5ZNzGMZUr6Tt2yCUAtamecDATKN6/Gbsxe0tABN0pk0rx5ic+4TXdBroN9OAZchH4tJCsOCKonCzApPxVThDNMxsooyFq9DmgXhyEUOOoeS+Fr4FgH+jSANm/l178Jh9epfXQ9gE/6aqPxYjNSBgS60S1EVqCpxw2rT1mUYeGfwibVm53ixGptR8kte70nAgMBAAGjfTB7MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU2LubNS1bP+/ha8vMDM+iLrppeowwGAYDVR0gBBEwDzAFBgNVHSAwBgYEVR0gADAdBgNVHQ4EFgQU4ubX0p6DVjN9DKtOWWMYAs+HxdQwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQB8jqYUw7Tv+W4ZH06PraF6zfdCxT03DhRChw4Z/Qm0XVS2gRyRwcMptQFERhPNOA221u9LqozZ1aK3B35wkcGD/dFJgJCJB96SMttQl2Hp/EiQz9PFF02dBSruXhIaraPbM+NIGdmyN2ZywGGXI1aU7JD3XG29Sh2AAdOkv8dI6gEgzt/DHSIIbakbaLdEIc7WB95GUHcHnNj58TzTSyVfBmtb3vBK9JG0Io6NAPWQYx2VP8+fIylja2d128hgh0dsDrXFAM+9AX8hae5vvxVi8TWs/z2ing+k+immtSNfzzKMiO7r5wJAkyjwtUBlBStKIA6Zer22pmSTZZeucHdEThabcWQidVZmMP3If6ix5UeyX8V6OAw0gsI3IUb91Q76d4sLWbzoGNONAYFC1Iyz0xWj47Zd6P7Z2Gfh1ViIbMxViFDlNmbEZflpES87K/yhBUQ/tnCNGQoSdtsuyuWg3NfWbyJoNZzlU96JWxcqSaXkzse9j8wahayKNM6SWKSY1Z05h8JScOCmFB5F8V3bd5nP/uKja7H8O4GOAAPM3OtG+eq37xW/xN0oAsjbvt4ojnUbJs2kiAxEdwXx0K7mcPeS7zWmVt8h4RdcDm/PGTDa9m8OqhQuck80QnuxIUWVr7GWadh1Ly/tl0+bvmkcnO2ybRJ+gbqREHDTe0sxsw==", "MIIFczCCA1ugAwIBAgIUCvfSvQerjFDmM2LvmjoTDOInLAwwDQYJKoZIhvcNAQELBQAwQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMB4XDTIzMDgyNTA5MDAwNloXDTQ4MDgyNTA5MDAwNVowQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxVMKI9RMhnOSA2LorgEC3YDNd2itn72LOdfRRUu45fG70Iev+E4kRrzJ1k23WXH5sHTbcslpETeAZnj0/xKBYdELuwe6HX8kIwd1s6WGlZc0l7ki1fmj4HqSstGJ/BKGj1a7236WwPJEWEHqfx9QMEeuJKlUSVFFyE4jMsfYp87ifIpuwE8oLOw4ykDDOP52Td06vHCIYrqDBrvxFdAuEnFxNxlPXRE4gLsygg62HOxOuGmhWfsy6TccIp5XIOdj2CzeoXJ82m5/imBPJvkefnrjEQXziSE2mi2IBDtGP/AwFWI7WpsEyDXWImMSR0T3CuDmkeQ14pNmcqMp/bqX3i1aetadFTWsuhl0nH2iRqKZDJxZlScu99toq5GrdcFUcxGRQyl+sFhUh3XcBWJV7Y2wnFL2tY7thtQ8ZPmzTO8kPKCbEl5U6gCSIkpRPNZBPG4dT0qu+8Bd71Pu7nAy1iB4U6ys34cFlOlJpGM0FGr35LefbPR8bgz6M9XNjRbgMDQcXDMnfiDJ7E81oVBpCXN9ydHi1blhakuEBaoa9M/kazipGPmAuxrWBMmp2q0wzQp9GS2e8keJIDwJuyzELaRZC4yjVsVZQMK//D+4J3boU5drCmmm6C1rwNRfSZuFGNcIYDZeHteGoCF4EA5jcgdFaIYrDej6VAab42vN5LUCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTYu5s1LVs/7+Fry8wMz6Iuuml6jDAdBgNVHQ4EFgQU2LubNS1bP+/ha8vMDM+iLrppeowwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQBbcHyV2b5mGwHWxCSbDwr5V7PgSZIJa1scrCnIHD3Z/yxG7Xp5cIlBj4My4lRHjZtJVvUfTjFpsEDEv/PAq74OIolN/kPdMfTczFBGpvsZr0x2yUPEJzQsTSLx0gwZ+wvoKHWE0C7GqgkABNrFW8FLqRzNqXsmM5oI4c3V5syxwBYFDUY5MPWdqJEDfRvjjJPCXmKOP1lO+i+E07vsFpDzHS2FKB5c6sTIZkvt+H/CG4hVu6ZvcFXXzv2JK/EoVZ6wUdClt4pLgTQZ/W0qQCJ3GjFe/PZ74mckW1x/zk9z0VQjUpTqz3AjPLIjj60nMLTLp50oFcMLjuXss0vv4tUjCTps2Qg9n0GwLlDR42Nyw2TKcMMB6ycEoNiUEu0lga1JM0SVSsFP7GSU/W9VqatK7xp/XW9/GDvgp3Z/pPM0E3i1tqp/nOU43Yof8Wi4JJ6zOgXBzqQxO6MILZJ4qEfenAtI7o95Ty5yk9vRboUstywsfC6CVsu08NL/ttw4OSXOvbkQ+7zMxCYT9YyQD5l/ltC3bgdj/lBZznsBuGYNOB16wDNcGpuuaeksfQfBDPHT+vR6gPVFZpyVwy/tzH6NTpUGDjoHVsCxUjY870OM4D2Jcj9OIqqdlkCoWO6i4Vec7sTzxiX39oNSr1G7Cobc3sYdhnxg/vlg1BeCJ87p0A==" ] } ``` ## JWT Payload * The JWT payload MUST conform to the `private_key_jwt` method as specified in [OpenID Connect 1.0 Chapter 9](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) (2). * The JWT MUST always contain the `iat` claim. * The `iss` and `sub` claims MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the party that creates and signs the JWT (unless specified otherwise). * The `aud` claim MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the party receiving the JWT. * Both `iat` and `exp` MUST be formatted as Unix Timestamp. * Client Assertions used at the access token endpoint (`/connect/token`) MUST be set to expire in 30 seconds to mitigate replay attacks. The combination of `iat` and `exp` claims MUST reflect that. * JWTs other then Client Assertions MAY shorten or elongate the time difference of the validity of the JWT as per their requirements. 30 second difference is recommended as default.\ \&#xNAN;*Example: Delegation Evidence provided as JWT may be valid for 5 minutes. It is up to the involved parties to determine what is appropriate value.* * The JWT MUST contain the `jti` claim for audit trail purposes. The `jti` is not necessary a GUID/UUID. A new `jti` key must be used for each JWT to avoid replay attacks. * Depending on the use of the JWT, other JWT payload data MAY be defined. ### Additional rationale (1) In OAuth 2.0, clients are generally pre-registered. Since in iSHARE servers interact with clients that have been previously unknown, this is not a workable requirement. Therefore, iSHARE implements a generic client identification and authentication scheme, based on iSHARE whitelisted [PKIs](/introduction/specific-technical-standards/pki). (2) Since OAuth 2.0 doesn't specify a PKI-based authentication scheme, but OpenID Connect 1.0 does, iSHARE chooses to use the scheme specified by OpenID Connect in all use cases. This is preferred over defining a new proprietary scheme. (3) iSHARE implementation is compatible with the following RFC extensions of OAuth: * RFC7522: SAML 2.0 Assertions * RFC7523: JSON Web Tokens (JWTs) Example JWT Payload: ```json { "iss": "did:ishare:EU.NL.NTRNL-10000001", "sub": "did:ishare:EU.NL.NTRNL-10000001", "aud": "did:ishare:EU.NL.NTRNL-10000000", "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", "exp": 1504683475, "iat": 1504683445 } ``` ## JWT Processing * A server SHALL NOT accept a JWT more than once for authentication of the Client. However, within its time to live, a Service Provider MAY forward a JWT from a Service Consumer to one or more other servers (Entitled Party or Authorisation Registry) to obtain additional evidence on behalf of the Service Consumer. These other servers SHALL accept the JWT for indirect authentication of the Service Consumer during the JWT’s complete time to live. * A server SHALL only accept a forwarded JWT if the aud claim of the forwarded JWT matches the iss claim of the JWT from the client that forwards the JWT. * JWT contents that are not specified within the iSHARE scope SHOULD be ignored. # Client Assertion {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} This page defines the JWT payload that should be provided to generate an iSHARE JWT client assertion for the [access token endpoint.](https://gitlab.com/ishare-foundation/cab/developer-portal/-/blob/main/all-roles-common-endpoints/access-token-m2m%20\(1\).md) ## JWT Payload Instead of the default [iSHARE JWT ](/reference/ishare-jwt)payload requirements, the following apply: * The `iss` and `sub` claims MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the client that wishes to authenticate. * The `aud` The claim MUST contain only a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the party that authenticates the client. Including multiple audiences creates a risk of impersonation and is therefore not allowed. In OAuth 2.0, clients are generally pre-registered. Since in iSHARE servers interact with clients that may have been previously unknown, this is not a workable requirement. Therefore, iSHARE implements a generic client identification and authentication scheme, based on iSHARE whitelisted PKIs. Since OAuth 2.0 doesn’t specify a PKI-based authentication scheme, but OpenID Connect 1.0 does, iSHARE chooses to use the scheme specified by OpenID Connect in all use cases. This is preferred over defining a new proprietary scheme. Example Client Assertion JWT Payload: ```json { "iss": "did:ishare:EU.NL.NTRNL-10000001", "sub": "did:ishare:EU.NL.NTRNL-10000001", "aud": "did:ishare:EU.NL.NTRNL-10000000", "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", "exp": 1504683475, "iat": 1504683445 } ``` # Authentication {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ## Machine-to-Machine (M2M) Authentication iSHARE refers to the OAuth 2.0 protocol for authenticating parties and providing access tokens based on the iSHARE agreements when requesting access to an iSHARE-compliant service. For the most recent version of the OAuth 2.0 specification, visit [oauth.net](https://oauth.net/2/). In addition to or overriding the OAuth 2.0 specifications, the following requirements apply for iSHARE: * Clients MUST NOT be pre-registered. A look-up in the Participant Registry is sufficient. It is up to the server to create a new entry for Clients that perform requests for the first time. * The client\_id MUST contain a valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the client. * In case of potential HTTP message size restrictions on the server, a POST call alternative MUST be offered to the /oauth2.0/token endpoint. Therefore, to avoid unaccepted HTTP GET calls, HTTP GET calls MUST be disabled to the /oauth2.0/token endpoint. * Servers MUST NOT issue refresh tokens In OAuth 2.0, clients are generally pre-registered. Since in iSHARE, servers interact with clients that have been previously unknown, this is not a workable requirement. Therefore, this spec implements a client identification and authentication scheme, which allows participants to still establish the connection with each other based on the claims about themselves, which are digitally signed with a PKI certificate which are trusted in the iSHARE Trust Framework and thereby trusted by its members. {% hint style="info" %} M2M Interaction sections explain how authentication and authorisation happen between participants of iSHARE. The authentication part requires a proper `/token` endpoint implementation. If you are already familiar with how authentication works within iSHARE and are ready to implement the endpoint, please visit the [access token section](/all-roles-common-endpoints/access-token-m2m). {% endhint %} ### M2M Generic Authentication Flow Based on the described standards and specifications in this scheme, the generic iSHARE Authentication flow is described in the following sequence diagram. For a deeper understanding of the various roles within the iSHARE network, take a look at the [Framework and Roles page](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) in the iSHARE Trust Framework.
The sequence diagram refers to the Service Consumer, Service Provider and Participant Registry. Please note that this Authentication flow applies to various possible interactions. Each party that needs to authenticate another party requesting data or services can be authenticated through this flow. In the demo section, you can find [Postman Collections](/introduction/getting-started/postman-collections) that demo this authentication flow from the perspective of a Service Provider. In the following flowchart, we describe the steps within the authentication flow in greater detail.

Flowchart for validating an iSHARE Access Token

### Certificate Validation Validating the certificate mainly consists of two steps: 1. Verifying the validity of the certificate (steps 2.2.2 and 2.2.3 of the above generic authentication flow). 2. Verifying the iSHARE Status of the party (step 2.2.6 of the above generic authentication flow). It is always the responsibility of the receiving iSHARE Party to verify the certificate and the status of the requesting iSHARE Party. During conformance testing (see [Conformance Test Tool](/introduction/conformance-test-tool)), it can only be tested how test certificates are validated. It is important to make sure that real certificates are validated in a proper way, as described below. **1. Verifying the validity of the certificate** A request in iSHARE must always be signed by a certificate that is issued by a certificate authority on the trusted list of iSHARE. Retrieve this list as described in [Get trusted CA List.](/reference/authentication/get-trusted-ca-list) The trusted CA list consists of certificate authorities of the qualified Trust Service Providers. The party receiving the request signed by such a certificate is responsible for verifying that the certificate is issued by a certificate authority on the trusted list. For eIDAS eSEALs, it is “Is the Key Usage ( 2.5.29.15 ) equal to 'Non-Repudiation". Any other best practices for validating certificates (such as a check on revocation lists) still apply. **2. Verifying the iSHARE Status** Within iSHARE, it is necessary to match the identity on the certificate that is used to sign the client\_assertion with the party identifier within that client\_assertion. It is possible that the party identifier is not recorded on the certificate. Therefore, the standard procedure to verify the status of an iSHARE Party is as follows: 1. Authenticate yourself with the Participant Registry at the /token endpoint. 2. Send a request to the [/parties endpoint](/participant-registry-role/parties) of the Participant Registry. Parameter `party_id` value should be `client_id` from request (it should be equal to `iss` or `sub` in `client_assertion`). 3. Decode the parties\_token received and check the signature. 4. In the information, the status of the party is listed under “status” and should be equal to “Active”. The `x5c` value or `x5t#s256` of the certificate can be compared with the certificate which has been signed by the client assertion in the request. {% hint style="info" %} **Note** The old method of validating participants using the certificate subject name is highly discouraged, as in practice, that method was quite unreliable. In any case, the party validating the token request (client\_assertion) is responsible for proper validation of the incoming requests, and with the whole certificate provided in the parties\_token must be used for those purposes. These specifications can only provide guidance about it. {% endhint %} *** **Example of iSHARE status verification of Test Service Consumer (see** [Test participants](/introduction/getting-started/test-participants))**:** 1. The `x5c` value of Test Service Consumer’s request: ``` [ "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=", "MIIF2jCCA8KgAwIBAgIUPG3+TAnxVOBce9NaPt9pTAgm5R4wDQYJKoZIhvcNAQELBQAwQjEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9TdWJDQUczMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDAeFw0yMzA4MjUwOTAxMzJaFw00ODA4MjUwOTAwMDVaMF0xHjAcBgNVBAMMFWVJREFTZVNFQUxPSURfSXNzQ0FHNDEZMBcGA1UEYRMQTlRSTkwtaVNIQVJFVEVTVDETMBEGA1UEChMKaVNIQVJFVGVzdDELMAkGA1UEBhMCWFgwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDanUgM1/PQyXNTX+UOLGrZjS8HaTWR/P4xD8SMCRxOXHKzHLQqEQOuHD/w+rx9/bEwzH4wVfJ0m6/r56KOg0wLUlVwOyikOXGoITD2u+Ui9t24tYIkx8zjLG7VHVcw4dXOt92svKY1LybvlproWzTHlRwoIO1YQ4hO+rybsw/KEDEXUbkowjlHAPcwnsOW64367EN+ezT1sS8dzFIxmG8qC2LrM2sXJWqq5vJeE/86TfZ2NMO+CUxkjj7uPgbW2V/MOUhYyAtGAjzd/KwOrLMRMYaXOIj61m8R71nh/LV9n8dnj0wTQONTHhuM7mdZQxhqOdkL2ckSrBWi3atEVT1OhBRX4FmmhIhmSWuCtgyKiDCIotyGAsX2o6817fee4Rdtwfw9Q4oN3NAhtod60iOAWApVt+BT5tvdgGOYWPcbMR5pGzbp38dGUyuwYZV4LAnIGSm5yaucNE2E2xrQCbEeZm4RPsx5JleWzipk+42d7vqvWD88IQcQ+bZM2X4rJBZNs166Clx+m6HmKxKALebUtjszsgyH8cq10d+k4Ao8oCaOYjv2IaEbMd+fV/Uf8kPkzTtKlttdqiixoIqycXMEgBaSgkub7XoQ6K26tRPJ0w5Qkuuh3MKtGEWfW7EEGmpnCqjOv6/rAMJiMWyh1IgLgNBUPP7zaVPpDAtC88OSJQIDAQABo4GsMIGpMBIGA1UdEwEB/wQIMAYBAf8CAQEwHwYDVR0jBBgwFoAU4ubX0p6DVjN9DKtOWWMYAs+HxdQwGAYDVR0gBBEwDzAFBgNVHSAwBgYEVR0gADApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwHQYDVR0OBBYEFLMaT0JA6dh4nWv//CSwELE0PPCJMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAZv5Gukx0PEvVREIt8MTaPfCH4awyiiYyi17h6R5LLk1rerwQsSSSHfVqftdwRF0ocLp2PXJhe075qV406C04CjamNk3ez9ZiNHCNjPtfid6oOxqz1Xk8XPjNYElbAFmP7eKl/441vZhGuk/RhXGNxQbto0Q16g8IRcGDvWgNhtrtB1G2xSmtB1S2uUpSaiZVNOrkdzThiEJseURBoXxUXIqpLyPTRl6MMgVaLGRYRc3vYij4B7M2hBN7/cjnGLsMVtgbOv6CV21g2SXowbgOqzByH51UTR6ObHiGj0kSCALG14IQPkzQPiSpju++9M2jAjPM3o421ZOUDMP246CsqPXrTAbPXJVUR/gi4u53kmzC210jvVq9hHwelxQOTPFhlM6E1Ch4Jb4PQRLKDPFl+5NW4Fy2JADjyupyVHncdLEuPy0PgCL2Yo147HSpPj4u7jc1RmHU7NO12EV2ZCMfFlRwdGv6if8qO7s/6lpZJjpPtLEObA5tD4ahc+aPNAi9WCk0peRm1KE5VGDWKFNSNAiLJNzP7m2Q6y8fOy38cNgFBhGOF/KgEIsT10V+5K5o+ylVVtPVeRRENEvKO9ELkze0IHgsTB/6cwOij4pxM9Jvauj06GglhIhiIA6q0iDUqB1MUR0HziY9BsnWY9kR8hwV3OW+nsmztQwGVEw2kjU=", "MIIFjjCCA3agAwIBAgIUFj9/3jGORhtIpZ98OLRtRHs0AYswDQYJKoZIhvcNAQELBQAwQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMB4XDTIzMDgyNTA5MDA0NFoXDTQ4MDgyNTA5MDAwNVowQjEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9TdWJDQUczMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL7nzkyoFXWg1ghdG6fnuzuvAdMWsm/I+mX3Dbz3I/KyqLdWt7XG3OWVSnhosAD2W2SXnlGXqxye0hPtEgkQIdel7FnFosWWrsEOratgXlnM4NWpYDKMWEVYro7hzHgCZ126ZPQULls52NcvpRM8S3dZk+XK1kf3VeS0J2hUSFEAZHLyXCXkhTnUI7qo1ur1TmDWYsNQwxDGOu7CQyZYdKIwKqI9eGsRLgM6PQlg3vZCropOodM7loTuirCl3UKw4HrGk2cOiAf4Id//eaVCafwkjKsJTQuAahuRz4qMsHYA3kDQz+0+hgnR74r+iLr+8lr044glnaWIWvrEGciRR+PectfrLOQQIW7ha13dzWozkT0agnT1Lk/CGrgNXVqhosGC0ruAQPI6DcPNy2INM9JgtCmBsSjMM185FIBX4Cy17m73h9rKjXZMxb6TxX7CIZyesgAS0bBRb6xIpKsZrlrjEazsjC2VHRRWOMJWYqcXLD5ZNzGMZUr6Tt2yCUAtamecDATKN6/Gbsxe0tABN0pk0rx5ic+4TXdBroN9OAZchH4tJCsOCKonCzApPxVThDNMxsooyFq9DmgXhyEUOOoeS+Fr4FgH+jSANm/l178Jh9epfXQ9gE/6aqPxYjNSBgS60S1EVqCpxw2rT1mUYeGfwibVm53ixGptR8kte70nAgMBAAGjfTB7MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU2LubNS1bP+/ha8vMDM+iLrppeowwGAYDVR0gBBEwDzAFBgNVHSAwBgYEVR0gADAdBgNVHQ4EFgQU4ubX0p6DVjN9DKtOWWMYAs+HxdQwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQB8jqYUw7Tv+W4ZH06PraF6zfdCxT03DhRChw4Z/Qm0XVS2gRyRwcMptQFERhPNOA221u9LqozZ1aK3B35wkcGD/dFJgJCJB96SMttQl2Hp/EiQz9PFF02dBSruXhIaraPbM+NIGdmyN2ZywGGXI1aU7JD3XG29Sh2AAdOkv8dI6gEgzt/DHSIIbakbaLdEIc7WB95GUHcHnNj58TzTSyVfBmtb3vBK9JG0Io6NAPWQYx2VP8+fIylja2d128hgh0dsDrXFAM+9AX8hae5vvxVi8TWs/z2ing+k+immtSNfzzKMiO7r5wJAkyjwtUBlBStKIA6Zer22pmSTZZeucHdEThabcWQidVZmMP3If6ix5UeyX8V6OAw0gsI3IUb91Q76d4sLWbzoGNONAYFC1Iyz0xWj47Zd6P7Z2Gfh1ViIbMxViFDlNmbEZflpES87K/yhBUQ/tnCNGQoSdtsuyuWg3NfWbyJoNZzlU96JWxcqSaXkzse9j8wahayKNM6SWKSY1Z05h8JScOCmFB5F8V3bd5nP/uKja7H8O4GOAAPM3OtG+eq37xW/xN0oAsjbvt4ojnUbJs2kiAxEdwXx0K7mcPeS7zWmVt8h4RdcDm/PGTDa9m8OqhQuck80QnuxIUWVr7GWadh1Ly/tl0+bvmkcnO2ybRJ+gbqREHDTe0sxsw==", "MIIFczCCA1ugAwIBAgIUCvfSvQerjFDmM2LvmjoTDOInLAwwDQYJKoZIhvcNAQELBQAwQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMB4XDTIzMDgyNTA5MDAwNloXDTQ4MDgyNTA5MDAwNVowQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxVMKI9RMhnOSA2LorgEC3YDNd2itn72LOdfRRUu45fG70Iev+E4kRrzJ1k23WXH5sHTbcslpETeAZnj0/xKBYdELuwe6HX8kIwd1s6WGlZc0l7ki1fmj4HqSstGJ/BKGj1a7236WwPJEWEHqfx9QMEeuJKlUSVFFyE4jMsfYp87ifIpuwE8oLOw4ykDDOP52Td06vHCIYrqDBrvxFdAuEnFxNxlPXRE4gLsygg62HOxOuGmhWfsy6TccIp5XIOdj2CzeoXJ82m5/imBPJvkefnrjEQXziSE2mi2IBDtGP/AwFWI7WpsEyDXWImMSR0T3CuDmkeQ14pNmcqMp/bqX3i1aetadFTWsuhl0nH2iRqKZDJxZlScu99toq5GrdcFUcxGRQyl+sFhUh3XcBWJV7Y2wnFL2tY7thtQ8ZPmzTO8kPKCbEl5U6gCSIkpRPNZBPG4dT0qu+8Bd71Pu7nAy1iB4U6ys34cFlOlJpGM0FGr35LefbPR8bgz6M9XNjRbgMDQcXDMnfiDJ7E81oVBpCXN9ydHi1blhakuEBaoa9M/kazipGPmAuxrWBMmp2q0wzQp9GS2e8keJIDwJuyzELaRZC4yjVsVZQMK//D+4J3boU5drCmmm6C1rwNRfSZuFGNcIYDZeHteGoCF4EA5jcgdFaIYrDej6VAab42vN5LUCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTYu5s1LVs/7+Fry8wMz6Iuuml6jDAdBgNVHQ4EFgQU2LubNS1bP+/ha8vMDM+iLrppeowwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQBbcHyV2b5mGwHWxCSbDwr5V7PgSZIJa1scrCnIHD3Z/yxG7Xp5cIlBj4My4lRHjZtJVvUfTjFpsEDEv/PAq74OIolN/kPdMfTczFBGpvsZr0x2yUPEJzQsTSLx0gwZ+wvoKHWE0C7GqgkABNrFW8FLqRzNqXsmM5oI4c3V5syxwBYFDUY5MPWdqJEDfRvjjJPCXmKOP1lO+i+E07vsFpDzHS2FKB5c6sTIZkvt+H/CG4hVu6ZvcFXXzv2JK/EoVZ6wUdClt4pLgTQZ/W0qQCJ3GjFe/PZ74mckW1x/zk9z0VQjUpTqz3AjPLIjj60nMLTLp50oFcMLjuXss0vv4tUjCTps2Qg9n0GwLlDR42Nyw2TKcMMB6ycEoNiUEu0lga1JM0SVSsFP7GSU/W9VqatK7xp/XW9/GDvgp3Z/pPM0E3i1tqp/nOU43Yof8Wi4JJ6zOgXBzqQxO6MILZJ4qEfenAtI7o95Ty5yk9vRboUstywsfC6CVsu08NL/ttw4OSXOvbkQ+7zMxCYT9YyQD5l/ltC3bgdj/lBZznsBuGYNOB16wDNcGpuuaeksfQfBDPHT+vR6gPVFZpyVwy/tzH6NTpUGDjoHVsCxUjY870OM4D2Jcj9OIqqdlkCoWO6i4Vec7sTzxiX39oNSr1G7Cobc3sYdhnxg/vlg1BeCJ87p0A==" ] ``` 2. The call to `/parties/{party_id}` endpoint to verify the iSHARE status: ``` GET /parties/did:ishare:EU.NL.NTRLNL-10000001 ``` (URL encoding removed) 3. The decoded response lists Test Service Consumer as “Active” and includes certificate x5c and x5t#s256 values of the certificate used during registration. One of these certificates should match the certificate used for signing the JWT (client assertion): ```json { "party_info": { "party_id": ["did:ishare:EU.NL.NTRNL-10000001"], "party_name": "Test Service Consumer", "capability_url": "", "registrar_id": "did:ishare:EU.NL.NTRNL-1000000", "adherence": { "status": "Active", "start_date": "2024-01-31T00:00:00.000Z", "end_date": "2025-02-01T00:00:00.000Z" }, "additional_info": { "description": "", "logo": "", "website": "", "company_phone": "", "company_email": "", "publicly_publishable": "false", "countriesOfOperation": [], "sectorIndustry": [], "tags": "" }, "agreements": [ { "type": "TermsOfUse", "title": "Terms of use", "status": "Accepted", "sign_date": "2024-01-31T00:00:00.000Z", "expiry_date": "2025-01-31T00:00:00.000Z", "hash_file": "614331b0003219f2d2d123b0cd6105fb", "framework": "iSHARE", "dataspace_id": "", "dataspace_title": "", "compliancy_verified": "yes" }, { "type": "AccessionAgreement", "title": "Accession agreement", "status": "Accepted", "sign_date": "2024-01-31T00:00:00.000Z", "expiry_date": "2025-01-31T00:00:00.000Z", "hash_file": "f50a036402b3b243910ce572930be9f5", "framework": "iSHARE", "dataspace_id": "", "dataspace_title": "", "compliancy_verified": "yes" } ], "certificates": [ { "subject_name": "C=NL, O=Test Service Consumer, CN=Test Service Consumer, organizationIdentifier=NTRNL-10000001", "certificate_type": "PKIo", "enabled_from": "2024-12-20T00: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=", "MIIF2jCCA8KgAwIBAgIUPG3+TAnxVOBce9NaPt9pTAgm5R4wDQYJKoZIhvcNAQELBQAwQjEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9TdWJDQUczMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDAeFw0yMzA4MjUwOTAxMzJaFw00ODA4MjUwOTAwMDVaMF0xHjAcBgNVBAMMFWVJREFTZVNFQUxPSURfSXNzQ0FHNDEZMBcGA1UEYRMQTlRSTkwtaVNIQVJFVEVTVDETMBEGA1UEChMKaVNIQVJFVGVzdDELMAkGA1UEBhMCWFgwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDanUgM1/PQyXNTX+UOLGrZjS8HaTWR/P4xD8SMCRxOXHKzHLQqEQOuHD/w+rx9/bEwzH4wVfJ0m6/r56KOg0wLUlVwOyikOXGoITD2u+Ui9t24tYIkx8zjLG7VHVcw4dXOt92svKY1LybvlproWzTHlRwoIO1YQ4hO+rybsw/KEDEXUbkowjlHAPcwnsOW64367EN+ezT1sS8dzFIxmG8qC2LrM2sXJWqq5vJeE/86TfZ2NMO+CUxkjj7uPgbW2V/MOUhYyAtGAjzd/KwOrLMRMYaXOIj61m8R71nh/LV9n8dnj0wTQONTHhuM7mdZQxhqOdkL2ckSrBWi3atEVT1OhBRX4FmmhIhmSWuCtgyKiDCIotyGAsX2o6817fee4Rdtwfw9Q4oN3NAhtod60iOAWApVt+BT5tvdgGOYWPcbMR5pGzbp38dGUyuwYZV4LAnIGSm5yaucNE2E2xrQCbEeZm4RPsx5JleWzipk+42d7vqvWD88IQcQ+bZM2X4rJBZNs166Clx+m6HmKxKALebUtjszsgyH8cq10d+k4Ao8oCaOYjv2IaEbMd+fV/Uf8kPkzTtKlttdqiixoIqycXMEgBaSgkub7XoQ6K26tRPJ0w5Qkuuh3MKtGEWfW7EEGmpnCqjOv6/rAMJiMWyh1IgLgNBUPP7zaVPpDAtC88OSJQIDAQABo4GsMIGpMBIGA1UdEwEB/wQIMAYBAf8CAQEwHwYDVR0jBBgwFoAU4ubX0p6DVjN9DKtOWWMYAs+HxdQwGAYDVR0gBBEwDzAFBgNVHSAwBgYEVR0gADApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwHQYDVR0OBBYEFLMaT0JA6dh4nWv//CSwELE0PPCJMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAZv5Gukx0PEvVREIt8MTaPfCH4awyiiYyi17h6R5LLk1rerwQsSSSHfVqftdwRF0ocLp2PXJhe075qV406C04CjamNk3ez9ZiNHCNjPtfid6oOxqz1Xk8XPjNYElbAFmP7eKl/441vZhGuk/RhXGNxQbto0Q16g8IRcGDvWgNhtrtB1G2xSmtB1S2uUpSaiZVNOrkdzThiEJseURBoXxUXIqpLyPTRl6MMgVaLGRYRc3vYij4B7M2hBN7/cjnGLsMVtgbOv6CV21g2SXowbgOqzByH51UTR6ObHiGj0kSCALG14IQPkzQPiSpju++9M2jAjPM3o421ZOUDMP246CsqPXrTAbPXJVUR/gi4u53kmzC210jvVq9hHwelxQOTPFhlM6E1Ch4Jb4PQRLKDPFl+5NW4Fy2JADjyupyVHncdLEuPy0PgCL2Yo147HSpPj4u7jc1RmHU7NO12EV2ZCMfFlRwdGv6if8qO7s/6lpZJjpPtLEObA5tD4ahc+aPNAi9WCk0peRm1KE5VGDWKFNSNAiLJNzP7m2Q6y8fOy38cNgFBhGOF/KgEIsT10V+5K5o+ylVVtPVeRRENEvKO9ELkze0IHgsTB/6cwOij4pxM9Jvauj06GglhIhiIA6q0iDUqB1MUR0HziY9BsnWY9kR8hwV3OW+nsmztQwGVEw2kjU=", "MIIFjjCCA3agAwIBAgIUFj9/3jGORhtIpZ98OLRtRHs0AYswDQYJKoZIhvcNAQELBQAwQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMB4XDTIzMDgyNTA5MDA0NFoXDTQ4MDgyNTA5MDAwNVowQjEeMBwGA1UEAwwVZUlEQVNlU0VBTE9JRF9TdWJDQUczMRMwEQYDVQQKEwppU0hBUkVUZXN0MQswCQYDVQQGEwJYWDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL7nzkyoFXWg1ghdG6fnuzuvAdMWsm/I+mX3Dbz3I/KyqLdWt7XG3OWVSnhosAD2W2SXnlGXqxye0hPtEgkQIdel7FnFosWWrsEOratgXlnM4NWpYDKMWEVYro7hzHgCZ126ZPQULls52NcvpRM8S3dZk+XK1kf3VeS0J2hUSFEAZHLyXCXkhTnUI7qo1ur1TmDWYsNQwxDGOu7CQyZYdKIwKqI9eGsRLgM6PQlg3vZCropOodM7loTuirCl3UKw4HrGk2cOiAf4Id//eaVCafwkjKsJTQuAahuRz4qMsHYA3kDQz+0+hgnR74r+iLr+8lr044glnaWIWvrEGciRR+PectfrLOQQIW7ha13dzWozkT0agnT1Lk/CGrgNXVqhosGC0ruAQPI6DcPNy2INM9JgtCmBsSjMM185FIBX4Cy17m73h9rKjXZMxb6TxX7CIZyesgAS0bBRb6xIpKsZrlrjEazsjC2VHRRWOMJWYqcXLD5ZNzGMZUr6Tt2yCUAtamecDATKN6/Gbsxe0tABN0pk0rx5ic+4TXdBroN9OAZchH4tJCsOCKonCzApPxVThDNMxsooyFq9DmgXhyEUOOoeS+Fr4FgH+jSANm/l178Jh9epfXQ9gE/6aqPxYjNSBgS60S1EVqCpxw2rT1mUYeGfwibVm53ixGptR8kte70nAgMBAAGjfTB7MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU2LubNS1bP+/ha8vMDM+iLrppeowwGAYDVR0gBBEwDzAFBgNVHSAwBgYEVR0gADAdBgNVHQ4EFgQU4ubX0p6DVjN9DKtOWWMYAs+HxdQwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQB8jqYUw7Tv+W4ZH06PraF6zfdCxT03DhRChw4Z/Qm0XVS2gRyRwcMptQFERhPNOA221u9LqozZ1aK3B35wkcGD/dFJgJCJB96SMttQl2Hp/EiQz9PFF02dBSruXhIaraPbM+NIGdmyN2ZywGGXI1aU7JD3XG29Sh2AAdOkv8dI6gEgzt/DHSIIbakbaLdEIc7WB95GUHcHnNj58TzTSyVfBmtb3vBK9JG0Io6NAPWQYx2VP8+fIylja2d128hgh0dsDrXFAM+9AX8hae5vvxVi8TWs/z2ing+k+immtSNfzzKMiO7r5wJAkyjwtUBlBStKIA6Zer22pmSTZZeucHdEThabcWQidVZmMP3If6ix5UeyX8V6OAw0gsI3IUb91Q76d4sLWbzoGNONAYFC1Iyz0xWj47Zd6P7Z2Gfh1ViIbMxViFDlNmbEZflpES87K/yhBUQ/tnCNGQoSdtsuyuWg3NfWbyJoNZzlU96JWxcqSaXkzse9j8wahayKNM6SWKSY1Z05h8JScOCmFB5F8V3bd5nP/uKja7H8O4GOAAPM3OtG+eq37xW/xN0oAsjbvt4ojnUbJs2kiAxEdwXx0K7mcPeS7zWmVt8h4RdcDm/PGTDa9m8OqhQuck80QnuxIUWVr7GWadh1Ly/tl0+bvmkcnO2ybRJ+gbqREHDTe0sxsw==", "MIIFczCCA1ugAwIBAgIUCvfSvQerjFDmM2LvmjoTDOInLAwwDQYJKoZIhvcNAQELBQAwQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMB4XDTIzMDgyNTA5MDAwNloXDTQ4MDgyNTA5MDAwNVowQTEdMBsGA1UEAwwUZUlEQVNlU0VBTE9JRF9Sb290RzIxEzARBgNVBAoTCmlTSEFSRVRlc3QxCzAJBgNVBAYTAlhYMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxVMKI9RMhnOSA2LorgEC3YDNd2itn72LOdfRRUu45fG70Iev+E4kRrzJ1k23WXH5sHTbcslpETeAZnj0/xKBYdELuwe6HX8kIwd1s6WGlZc0l7ki1fmj4HqSstGJ/BKGj1a7236WwPJEWEHqfx9QMEeuJKlUSVFFyE4jMsfYp87ifIpuwE8oLOw4ykDDOP52Td06vHCIYrqDBrvxFdAuEnFxNxlPXRE4gLsygg62HOxOuGmhWfsy6TccIp5XIOdj2CzeoXJ82m5/imBPJvkefnrjEQXziSE2mi2IBDtGP/AwFWI7WpsEyDXWImMSR0T3CuDmkeQ14pNmcqMp/bqX3i1aetadFTWsuhl0nH2iRqKZDJxZlScu99toq5GrdcFUcxGRQyl+sFhUh3XcBWJV7Y2wnFL2tY7thtQ8ZPmzTO8kPKCbEl5U6gCSIkpRPNZBPG4dT0qu+8Bd71Pu7nAy1iB4U6ys34cFlOlJpGM0FGr35LefbPR8bgz6M9XNjRbgMDQcXDMnfiDJ7E81oVBpCXN9ydHi1blhakuEBaoa9M/kazipGPmAuxrWBMmp2q0wzQp9GS2e8keJIDwJuyzELaRZC4yjVsVZQMK//D+4J3boU5drCmmm6C1rwNRfSZuFGNcIYDZeHteGoCF4EA5jcgdFaIYrDej6VAab42vN5LUCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTYu5s1LVs/7+Fry8wMz6Iuuml6jDAdBgNVHQ4EFgQU2LubNS1bP+/ha8vMDM+iLrppeowwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQBbcHyV2b5mGwHWxCSbDwr5V7PgSZIJa1scrCnIHD3Z/yxG7Xp5cIlBj4My4lRHjZtJVvUfTjFpsEDEv/PAq74OIolN/kPdMfTczFBGpvsZr0x2yUPEJzQsTSLx0gwZ+wvoKHWE0C7GqgkABNrFW8FLqRzNqXsmM5oI4c3V5syxwBYFDUY5MPWdqJEDfRvjjJPCXmKOP1lO+i+E07vsFpDzHS2FKB5c6sTIZkvt+H/CG4hVu6ZvcFXXzv2JK/EoVZ6wUdClt4pLgTQZ/W0qQCJ3GjFe/PZ74mckW1x/zk9z0VQjUpTqz3AjPLIjj60nMLTLp50oFcMLjuXss0vv4tUjCTps2Qg9n0GwLlDR42Nyw2TKcMMB6ycEoNiUEu0lga1JM0SVSsFP7GSU/W9VqatK7xp/XW9/GDvgp3Z/pPM0E3i1tqp/nOU43Yof8Wi4JJ6zOgXBzqQxO6MILZJ4qEfenAtI7o95Ty5yk9vRboUstywsfC6CVsu08NL/ttw4OSXOvbkQ+7zMxCYT9YyQD5l/ltC3bgdj/lBZznsBuGYNOB16wDNcGpuuaeksfQfBDPHT+vR6gPVFZpyVwy/tzH6NTpUGDjoHVsCxUjY870OM4D2Jcj9OIqqdlkCoWO6i4Vec7sTzxiX39oNSr1G7Cobc3sYdhnxg/vlg1BeCJ87p0A==" ]", "x5t#s256": "893aad639bf8b0958edbcf7d719023077d15828701a0a6fcc6d54a0684ce940d" } ], "roles": [ { "role": "ServiceConsumer", "start_date": "2023-01-31T00:00:00.000Z", "end_date": "2024-01-31T00:00:00.000Z", "loa": "High", "compliancy_verified": "yes", "legal_adherence": "yes" }, { "role": "ServiceProvider", "start_date": "2023-01-31T00:00:00.000Z", "end_date": "2024-01-31T00:00:00.000Z", "loa": "High", "compliancy_verified": "yes", "legal_adherence": "yes" }, { "role": "EntitledParty", "start_date": "2023-01-31T00:00:00.000Z", "end_date": "2024-01-31T00:00:00.000Z", "loa": "High", "compliancy_verified": "yes", "legal_adherence": "yes" } ], "authregistery": [] } } ``` ## Human to Machine (H2M) Authentication Besides Machine2Machine interaction, it can occur that it is relevant if a specific person requests data or a service. In order to provide a Service Provider with identity information about a human subject, iSHARE refers to the OpenID Connect 1.0 protocol. The iSHARE use of OpenID Connect 1.0 is based on the requirements of the [official standard](https://openid.net/specs/openid-connect-core-1_0.html). In addition to the OpenID Connect 1.0 specification, the following requirements apply: * Clients (a.k.a. service providers) MUST NOT be pre-registered. A look-up in the iSHARE adherence registry is sufficient. It is up to the server to create a new entry for Clients that perform requests for the first time. * The client\_id MUST contain the valid [Party Identifier](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification) of the client. * Servers SHALL NOT issue refresh tokens. ### H2M Generic Authentication Flow Based on the described standards and specifications in this scheme, the generic iSHARE Human2Machine Authentication flow is described in the following sequence diagram.

iSHARE Generic H2M Authentication FLow

The sequence diagram shows how the Service Provider interacts with an Identity Provider in order to receive identity information on the human user (who uses a browser to interact with the Service Provider). The specific details of the steps in this authentication flow are described in the generic API documentation of iSHARE: 1. [/identity\_provider/authorize](/identity-provider/authorize) 2. [/service\_provider/openid\_connect1.0/return](/service-provider-role/return) 3. [/identity\_provider/token](/identity-provider/access-token) 4. [/identity\_provider/userinfo](/identity-provider/user-info) A few remarks regarding this flow: * A human user might interact with the Service Provider in a different way than using a web browser. * After the Service Provider initiates a POST /token request, the Identity Provider can verify their iSHARE Adherence with the Participant Registry. Adherence checks or certificate validation are not displayed in this flow, as this flow only describes the generic OpenID Connect 1.0 flow * This flow only describes Identification & Authentication of a human user, while in iSHARE, it is always relevant that their Authorisation (acting on behalf of an organisation) is also verified. This process is described in the [Human Authorisation section](/reference/authorization#human-to-machine-h2m-authorization). # Get trusted CA List Every iSHARE request must be signed with a certificate issued by a Certificate Authority (CA) on the iSHARE trusted list. Participants can retrieve this list via the **`/trusted_list`** endpoint. The trusted list consists of CAs of qualified Trust Service Providers (currently eIDAS issuers). The receiver of a signed request is responsible for verifying that the signer’s certificate chains to a CA from this list. ### Steps to Follow **1.1 Create client assertion**\ The Service Provider creates a signed JWT client assertion to authenticate with the Participant Registry’s token endpoint. **1.2 Request access token (`GET/POST /connect/token`)**\ The Service Provider sends the client assertion to the Participant Registry’s OAuth token endpoint to obtain an access token. **1.3 Receive access token (`200 OK`)**\ The Participant Registry returns an access token (JWT). **1.4 Request trusted list (`GET /trusted_list`)**\ The Service Provider calls the Participant Registry’s `/trusted_list` endpoint with the bearer token. **1.5 Receive trusted CAs (`200 OK`)**\ The Participant Registry returns the trusted CA list (typically in an iSHARE-signed JWT).

Get a list of trusted CA's from the /trusted_list capabilities endpoint

# Authorisation {% hint style="info" %} ***This page must be considered part of the iSHARE Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} #### **Authorisation Registry discovery logic** The Service Provider or Service Consumer can discover the Authorisation Registry in the following order when its not already known. 1. The Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint; 2. The Entitled Party has registered the Authorisation Registry for the specific service provider in the Participant Registry; 3. The Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry; 4. The Entitled Party's has set a default Authorisation Registry in the Participant Registry. #### Machine to Machine (M2M) Authorisation A core feature of iSHARE is enabling participants to manage authorisations, either on an organisational level or on a personal level. Read more on the background of iSHARE Authorisations in the [iSHARE Scheme](https://framework.ishare.eu/is/facilitate-flexible-authorizations-applicable-in-a). As defined by the iSHARE Framework, participants can request *delegation evidence* from either an Entitled Party or one of the Authorisation Registries. To receive this evidence, various rules need to be followed: * An organisation can only request evidence for an Authorisation policy that concerns this organisation. The organisation is either the creator (issuer) of the policy, or is the subject to whom the policy applies. * The only exception to the previous rule occurs when a Service Provider needs to gather delegation evidence for a client. The Service Provider needs to pass a valid *client\_assertion* of this client to the Entitled Party / Authorisation Registry. This proves that this client is indeed *at the gate of the Service Provider,* and it is necessary to ask about his authorisations. * Such a *client\_assertion* should be passed through the *previous\_steps* array in the *delegation\_mask*. The *delegation\_mask* is the body of the request to the [/delegation endpoint](/authorisation-registry-role/delegation-endpoint) of an Authorisation Registry. The recommendation is that the *client\_assertion* is always necessary if a Service Provider is not listed as issuer or subject of the delegation. However, if there are valid reasons a dataspace may relax this requirement while keeping in mind the impact this can have on the privacy of the authorisations at the Authorisation Registry. Allowing anyone to fetch a delegation evidence without valid reasons may potentially allow a mischievous party to crawl through all authorisations. Appropriate measures must be taken to avoid such situations. * iSHARE only specifies what the request and response data structure of delegation evidence looks like. iSHARE does not prescribe what the input and database storage for authorisation looks like. There is a standardised [Delegation Policy creation endpoint](/authorisation-registry-role/delegation-policy), and Authorisation Registries may implement that. {% hint style="info" %} The [/policy endpoint](https://ar.isharetest.net/swagger/index.html#/Policy/post_policy) of the [Test Authorisation Registry](/introduction/getting-started/test-participants#test-authorisation-registry) is not standardised in iSHARE and is only an example of how authorisations can be stored at an AR. {% endhint %} #### Human to Machine (H2M) Authorisation Besides authorisation on an organisational level, within iSHARE, it is also possible to authorise humans to act on behalf of another organisation. The generic OpenID Connect 1.0 flow does not take into account Authorisations of a human. However, in iSHARE, it is essential that authorisations of a user are combined with their identity details before a service can be offered. As defined by the iSHARE Framework, authorisations of a human are registered at an Authorisation Registry, and can be retrieved via various means using the [userinfo endpoint](/identity-provider/user-info). For this purpose, there are some modifications to the OpenID Connect Flow. User identities are protected by sharing pseudonyms in order to comply with privacy requirements. Authorisation of a human is done by replacing the ‘accessSubject’ value on the root level in delegationEvidence with an [iSHARE pseudonym of the human user](/identity-provider/access-token#human-pseudonym). In some cases, it is necessary to encrypt JWTs in order to prevent unsuspecting users or Identity Brokers from being able to read and infer data not meant for them. Broadly, users’ interaction with the service provider can happen in 2 ways: [The service-specific approach](#service-specific-approach) The user has the specific link to a specific service and is only interested in using that service. The service provider only needs to check if the human user is authorised to access this service. [The portal approach](#portal-approach) The user uses a portal to access a service. The Service Provider needs to know the authorisations of the user in order to only show services available to the user. #### Service Specific Approach In the service-specific approach, the Service Provider will ask for a specific authorisation of the human user in the request parameter of the [userinfo endpoint](/identity-provider/user-info). This request closely follows the [delegation mask specification](/authorisation-registry-role/delegation-endpoint#request-model). However, the value for the `accessSubject` On the root level of the delegationEvidence is replaced with the [iSHARE pseudonym of the human user](/identity-provider/access-token#human-pseudonym) {% hint style="info" %} Since the Identity Provider and Human Authorisation Registry are the same entity, the discovery is not needed. Else, follow the discovery logic as explained above. {% endhint %}
#### Portal approach In the portal approach, the Service Provider is allowed to do a wildcard request in the request parameter of the [user info endpoint.](/identity-provider/user-info) This request closely follows the [delegation mask specification](/authorisation-registry-role/delegation-endpoint#request-model). However, the value `accessSubject` on the root level of the delegation Evidence is replaced with the [iSHARE pseudonym of the human user](/identity-provider/access-token#human-pseudonym). The wildcard is allowed because the Service Provider needs to know all the authorisations of the human user to show them in the portal, before the human user can select the correct service. Since a human user would be representing only one company at a time, it is asked by the IDP to select the company they want to represent. When the user identity is common for different companies, it can represent. {% hint style="info" %} Since the Identity Provider and Human Authorisation Registry are the same entity, the discovery is not needed. Else, follow the discovery logic as explained above. {% endhint %}
# Authorisation rules iSHARE certified Authorisation Registries should support the creation of authorisation rules if they choose to implement the policy request endpoint. Authorisation Rules are created by an Entitled Party and contain rules based upon which incoming delegation requests (using the [policy creation endpoint /delegationPolicy](/authorisation-registry-role/delegation-policy)) are evaluated and automatically created or refused. There are no technical specifications on how the Entitled Party should be provided with the possibility of managing authorisation rules. However, the following principles should be followed: * The authorisation rules must use a data license (9998 and additional licenses as applicable) to limit liability on automatically created policies. * The authorisation rules may use ISHARE.DELEGATION as a resource type. * The authorisation rules may implement the iSHARE concept of actions that can be performed on the delegations. Action names here are not prescribed, but as a best practice, we suggest using HTTP methods such as "POST", "GET", "PUT" and "DELETE" to improve interoperability between Authorisation Registries. * The authorisation rules must be limited to rules that work the same as described on [this page of the framework](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence). An extra requirement for these authorisation rules is that at least one rule limiting the scope of the kind of delegation to be created via this mechanism should be present, preventing “\*” authorisation rules. The Authorisation Registry should provide clear information on how the authorisation rules are processed if they overlap. Refer to the guidance section below for further information. {% hint style="info" %} **Implementation guidance** The following is not part of the specifications, but provided as guidance for implementation. **Logic when requesting the creation of delegation policies** The Authorisation Registry should contain logic for handling delegation policy requests when there are overlapping authorisation rules in place. An example of a principle that could be followed is: * If multiple authorisation rules are present, the most recently added authorisation rules take precedence over older. **Logic when requesting delegation evidence** An Authorisation Registry should contain logic for handling delegation evidence requests when there are overlapping delegation policies in place. Since the creation of delegation policies can be automated, it becomes more likely that overlapping policies will occur. Examples of delegation policies can be considered: * Directly provided by the Entitled Party (direct delegation policies) * Provided based on authorisation rules (indirect delegation policies) Examples of principles that could be followed are: * Directly provided policies take precedence over policies created based on authorisation rules. * If multiple delegation policies are present, the most recently added delegation policy takes precedence over older. * Within a policy, rules should be evaluated in a deny-override manner, allowing a Permit only if all of the rule elements evaluate to Permit. {% endhint %} --- [Next Page](/llms-full.txt/1)