> For the complete documentation index, see [llms.txt](https://dev.ishare.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev.ishare.eu/introduction/release-info.md). # Release info {% hint style="info" %} ***This page must be considered part of the iSHARE Trust Framework*** *This page is considered normative and is therefore compliant with RFC 2119.* {% endhint %} ## Version 3.0.1 Version 3.0.1 is a patch release of the iSHARE v3.0 specifications. It updates the Developer Portal for the v3 role and claim models, the Participant Registry API material and the delegation and credential guidance, and it corrects the examples, descriptions and links listed below. The topics under *Not changed in 3.0.1* stay open. The normative API definitions are published in the [iSHARE OpenAPI specifications](https://openapi.ishare.eu/) and the credential definitions at [schemas.ishare.eu](https://schemas.ishare.eu/). The Developer Portal provides the accompanying implementation guidance and examples. Where the portal and those specifications differ, the specifications take precedence. ### Corrections that can affect an implementation Some of these bring the OpenAPI specification in line with this portal, and others bring this portal in line with the OpenAPI specification. A few are new or stricter in 3.0.1: `x5c` as a certificate chain, the encodings of `x5t#s256`, `tags` as an array, `countriesOfOperation` as country codes, the IdP assertion `verificationHash`, the error responses, `organisationIdentifier` as a MUST instead of a SHOULD, the opaque access token and the level of assurance per role. Check your implementation against all of them. * **X.509 certificate claim:** `x5c` is an array that holds the certificate chain, as defined in RFC 7515 section 4.1.6. It is no longer a single certificate value. * **X.509 certificate thumbprint:** `x5t#s256` is the SHA-256 thumbprint of the first certificate in `x5c`. 3.0 did not say how it is encoded: the examples show hex, while `x5t#S256` in RFC 7515 section 4.1.8 is base64url. Both are valid: 64 hexadecimal characters, or 43 base64url characters without padding. When you check a thumbprint, decode it and compare it with the thumbprint you compute from the certificate, rather than comparing the strings. * **`additionalInfo`:** `tags` changes from a single string to an array of strings in the API (change ticket CM-108). From 3.0.1 the credential schemas accept both, so credentials issued with a string stay valid; send an array from now on. `countriesOfOperation` holds ISO 3166-1 alpha-2 codes, two upper-case letters such as `NL`, instead of country names. * **IdP assertion claim:** the claim has an optional `verificationHash`. * **`organisationIdentifier`:** the id\_token and the userinfo token MUST contain `organisationIdentifier` in the ETSI EN 319 412-1 format, such as `NTRNL-10000002`, not a `did:ishare` identifier. * **User info:** `GET /connect/userinfo` responds with `application/json`: a JSON object whose `userinfoToken` holds the signed JWT. 3.0 described an `application/jwt` response. The payload MAY contain standard OpenID Connect claims, such as `name` or `email`, for the scopes granted in the access token. The `first_name`, `last_name`, `gender`, `company_id` and `company_name` parameters are removed, and the page no longer says that the payload contains delegation evidence. See [User info](/identity-provider/user-info.md). * **Access token (M2M):** the server MAY issue an opaque token or a signed iSHARE JWT as `access_token`. The Service Consumer MUST treat the value as opaque and MUST NOT parse it. The OpenAPI specification says the same. See [Access token (M2M)](/all-roles-common-endpoints/access-token-m2m.md). * **Claim models:** the `type` of the Framework Compliance claim is `frameworkCompliance`; the 3.0 page said `frameworkComplianceship`. The Framework Role and Dataspace Role claims require `startDate` and `endDate`, as the OpenAPI specification does. A table on the [claim models](/reference/claim-models.md) page sets the level of assurance per role. In the Authorisation Registry claim, `id` is the UUID of the claim and `authRegistryId` the iSHARE DID of the Authorisation Registry. The claim `status` values are defined: `active` claims are valid and the only ones to trust, `inactive` claims are not yet valid or have expired, `revoked` is permanent and `suspended` temporary. The X.509 certificate claim uses only `active` and `revoked`, as in the OpenAPI specification. * **Names on the portal pages:** the pages use the names of the OpenAPI specification: `capabilitiesToken`, `capabilitiesInfo` and `publicServices` on [Capabilities](/all-roles-common-endpoints/capabilities.md), `delegationPath` and `previousSteps` on [Delegation](/authorisation-registry-role/delegation-endpoint.md), `partyToken` on [Single party](/participant-registry-role/single-party.md), `trustedListToken` on [Trusted list](/participant-registry-role/trusted-list.md), `dataSpaceDescriptionUrl` instead of `defUrl` on [Dataspaces](/participant-registry-role/dataspaces.md), and the query parameter `pageSize` instead of `size` on [Pagination](/reference/pagination.md). `accessSubject` in delegation evidence is a string: any of the party's identifiers in `id` or `alsoKnownAs`. * **Capabilities:** a service entry has an optional `authRegistry` object with `partyId` and `url`. It names the Authorisation Registry for that capability, the first step of the Authorisation Registry discovery logic. * **Trusted list:** `validity` and `status` of a certificate authority are enums with the values `valid` and `invalid`, and `granted`, `withdrawn`, `supervisionceased` and `undersupervision`. They are no longer nullable. * **Dataspaces and capabilities:** `status` of a dataspace is an enum with the values `new`, `in progress`, `active` and `not active`. `status` and `serviceType` of a capabilities service entry are enums with the values `deprecated` and `active`, and `framework-defined`, `dataspace-defined` and `self-defined`. * **Delegation request:** `delegationPath` and `previousSteps` sit at the root of the request body, next to `delegationRequest`. * **Participant Registry writes:** the request body of `POST /parties`, `PATCH /parties/{partyId}`, `POST /parties/{partyId}/claims` and `PATCH /parties/{partyId}/claims/{claimId}` is an iSHARE signed JWT. The pages for these endpoints already said so for 3.0, but their examples showed plain JSON. The body is a JSON object with one attribute, `partyCreationToken`, `partyUpdateToken`, `claimCreationToken` or `claimUpdateToken`, whose payload holds the iSHARE JWT claims and the party, update or claim. The `aud` claim is the Participant Registry. A request with a plain JSON body is rejected with `400`. * **Error responses:** `POST /connect/token` returns OAuth errors (`error`, `error_description`) for `400` and `401`, and RFC 9457 problem details for `500`. `GET /trustedList`, `GET /parties`, `POST /delegation` and `POST /delegationPolicy` return RFC 9457 problem details as `application/problem+json`, as do `POST /parties` and `POST /parties/{partyId}/claims` for `400`. Some of these responses are new, such as `403` and `500` on `POST /delegation` and `409` on `POST /delegationPolicy`. The other endpoints do not define an error body yet. * **DCP issuer metadata:** the Party ID Credential has `credentialType` `PartyIdCredential` instead of `PartyCredential`, and its schema is at `https://schemas.ishare.eu/v3/party-id/schema.json`. The Data Rights Credential schema is at `https://schemas.ishare.eu/v3/datarights/schema.json`. The previous URLs did not resolve. Each credential object carries `offerReason`, which the DCP issuer metadata requires. * **YAML parsing:** the values `"yes"` and `"no"` are quoted in the specification, so YAML 1.1 parsers and code generators read them as strings. ### Corrections to examples and descriptions These corrections do not change any endpoint, field or rule. **OpenAPI specifications** * Party identifiers in examples use `NTRNL`, pagination examples use `pageSize`, and the `serviceType`, `loa` and claim `status` examples use values from their own enums. * Claim update examples use `startDate` and `endDate`. * Capabilities examples use the operationId as the service identifier, and the service schema states the granularity of a service entry. * The userinfo token payload is described, with an `organisationIdentifier` in ETSI format in the example. Its schema is renamed from `jwt_payload_userinfo_token` to `jwtPayloadUserinfoToken`, so code generators produce a different class name. * The `certificateType` example of the X.509 certificate claim is `eSeal`. * The party, parties and claims example tokens use the `x5c` certificate chain. The capabilities, dataspaces, frameworks and delegation evidence tokens follow the 3.0 models: `capabilitiesInfo` with the operationId as identifier, `yes`/`no` and `technicalComplianceRequired` for role requirements, and service providers as rule conditions with a licence URL. The Service Consumer role in the example tokens has a level of assurance (`high`) instead of `not-applicable`. The claim token uses `claimInfo`, and the dataspaces and frameworks tokens have the `iss`, `sub`, `aud`, `jti`, `iat` and `exp` of every iSHARE JWT. In the frameworks token the Service Provider role has `loaRequired` `no`, as the level of assurance table says, and the dataspaces token uses `dataSpaceDescriptionUrl`. * Encoded example tokens match the values shown in the specification, and no `registrarId` starts with a space any more. The signatures of the edited tokens do not validate, as their descriptions say. * The `alsoKnownAs` examples use a valid EBSI identifier, `did:ebsi:zjdf2ajujWNEbMJBBTE2J7M`. They used `did:ebsi:LEIXG-724500AZSGBRY55MNS59`, an ETSI organisation identifier, which is not a valid `did:ebsi` identifier. * Example URLs are current: `authUrl` uses HTTPS, and `endpointDescription` points at the iSHARE OpenAPI specification instead of SwaggerHub. `compliesWithFrameworkVersions` shows `3.0`, the `loa` description lists `not-applicable`, as its enum does, and the `endpointURL` description refers to `endpointDescription`. * The `GET /parties` success response is described, and the `claimFilter` key `.` is shown as code. * The definitions of the claim `status` values show as a list, and say that a revoked claim does not become active again and a suspended one can. The `capabilityUrl` descriptions and a typo in the Dataspace Role claim are corrected. * The `access_token` of `/connect/token` is described: an opaque token or a signed iSHARE JWT, which the Service Consumer MUST NOT parse. The claim update description and example use the property paths of the flat claim models, such as `roleId` and `loa`, instead of `role.roleId`. The Framework Role claim has its own description, references to a `jwtHeader` model, which does not exist, point to the iSHARE JWT page, and the name iSHARE Trust Framework is used throughout. * The unused duplicate header parameter `delegation-evidence` is removed. `/service` uses `delegationEvidenceHeader`, which is unchanged. * The DCP specification validates as OpenAPI: the empty `components.schemas` key is removed and the Resolution API link is repaired. Its issuer metadata example shows a Participant Registry that serves the semi-modular packaging model, and the description says which credentials each packaging model uses. * Contact links use HTTPS, and the licence link points at the GitLab project instead of GitHub. * The v2 models `SchemeRole`, `Adherence` and `jwt_header`, which no endpoint or schema uses, are marked as deprecated. They will be removed in 3.1. * [openapi.ishare.eu](https://openapi.ishare.eu/) opens on 3.0.1. 3.0 and earlier versions stay selectable. **Credential schemas** * `additionalInfo.tags` accepts an array of strings in the Framework Compliance and Dataspace Membership claims and the Framework Compliance Credential, as in the API. The single string of 3.0 still validates but is deprecated; 3.1 accepts only the array. * Examples use `eSeal` as `certificateType`, as the OpenAPI specification and this portal do. * The vocabulary describes `x5c` as a chain of base64-encoded DER certificates, as the schemas do. * `x5t#s256` is described in the X509 Certificate Claim and Framework Compliance Credential schemas and in the vocabulary as in the OpenAPI specification: hex or base64url. * The field mapping between the API and the credentials lists `publiclyPublishable` as required. It and the API comparison examples link to the GitLab OpenAPI project. * The Framework Compliance Credential description no longer says that it carries the participant's base identity. * Each release line has its own address, and the site is published from release tags: `/v3/` serves the 3.0 line, now 3.0.1. **Developer Portal** * [Authentication](/reference/authentication.md) uses the v3 claims model to verify a party's iSHARE status, and names the `/connect/token` endpoint. * The navigation is reorganised. In every role, the OpenID4VCI and OpenID4VP pages are grouped under *H2M Verifiable Credential Endpoints*. [Claim models](/reference/claim-models.md), [Pagination](/reference/pagination.md), [Delegation conditions](/reference/delegation-conditions.md) and the [Verifiable Credentials specifications](/reference/verifiable-credentials-as-part-of-the-ishare-framework.md) move to *Reference*, and a new [Verifiable Credentials](/introduction/getting-started/verifiable-credentials.md) page under *Getting started* points to the Verifiable Credentials specifications and the credential schemas. * [Claim models](/reference/claim-models.md) is normative and has an example for each claim. `publiclyPublishable` is a boolean, `tags`, `countriesOfOperation` and `x5c` are arrays, and `x5t#s256` is described as the OpenAPI specification does. The examples on this page and on the Participant Registry pages follow the level of assurance table, and use the `status` values of the enum: 3.0 showed `Active` and `Accepted`. A note defines each claim `status` value and separates them from trusted list values. `capabilityUrl` is the URL of the capabilities endpoint itself, as in the OpenAPI specification, and is required by role. The agreement examples use 64-character SHA-256 hashes, and the Framework Role claim has its own introduction. * On [Capabilities](/all-roles-common-endpoints/capabilities.md), `capabilityVersion` is a string and the framework versions come from `/frameworks`. The page states the granularity of a service entry, and that other roles may publish a capabilities endpoint for services offered on their behalf. * The DCP pages use the `vc20-bssl/jwt` profile, contain valid JSON and use the `/requests/{requestId}` path. [Metadata (DCP)](/all-roles-common-endpoints/m2m-verifiable-credential-endpoints/metadata-dcp.md) describes `offerReason`, and `credentialType` values are named as the credential schemas define them, such as `FrameworkRoleCredential`. * The OpenAPI operations shown on the endpoint pages come from the 3.0.1 specifications and refer to the operations by the paths the specifications use, such as `/[v3.0]/capabilities`. Links to the OpenAPI models open version 3.0.1. [OpenAPI descriptions](/introduction/getting-started/openapi-descriptions.md) gives the download address of each version and of the separate DCP file. * The [credential schemas](/reference/credential-schemas.md) page, the OpenID4VCI issuer metadata page and the Participant Registry getting started page link to the current schema addresses under `https://schemas.ishare.eu/v3/`. * The [licences model](/licenses-model.md) page links to the [licences catalogue](https://licenses.ishare.eu/), and its examples use catalogue identifiers such as `https://licenses.ishare.eu/country-nl/1.0`. * [Roles](/roles/roles.md) explains the difference between a participant and a party, with the same wording as the Trust Framework. * [Authorisation](/reference/authorization.md) lists the Authorisation Registry discovery logic in five steps, including the bilateral fallback, and uses `previousSteps`, as does the [Delegation](/authorisation-registry-role/delegation-endpoint.md) page. * The Participant Registry create and update pages show the signed request token with its decoded payload, and the claim pages use the right request path and the `startDate` and `endDate` property names. * Party identifiers in the examples and example tokens use `NTRNL`, and no `registrarId` starts with a space any more. The `alsoKnownAs` examples use the same `did:ebsi` identifier as the OpenAPI specification, instead of `did:elsi` or `did:ebsi` with an ETSI organisation identifier. Example tokens were re-encoded to match their decoded payloads, including the authorize request object, which carried EORI identifiers, and the `id_token` on the Identity Provider [access token](/identity-provider/access-token.md) page, which now has `organisationIdentifier`; their signatures do not validate. The example token on the [Conformance Test Tool](/introduction/conformance-test-tool.md) page still carries EORI identifiers, as it shows what the tool sends. * The TLS requirement is the same on every page: TLS versions up to their end of life, currently TLS 1.2 or 1.3. Some 3.0 pages required TLS 1.2. * The dataspaces and frameworks examples use `yes`/`no` and `technicalComplianceRequired` for role requirements. Their tokens have the `iss`, `sub`, `aud`, `jti`, `iat` and `exp` of every iSHARE JWT, `countryRegistration` is a country name, and the frameworks example gives the Service Provider role `loaRequired` `no`, as the level of assurance table says. In the delegation request, `context` is an object and `serviceProvider` a string, `accessSubject` in the delegation policy request is a string, and the capabilities example lists only `GET` for `/capabilities`. * The authorize path is `/connect/authorize` on the endpoint pages, and the party update request uses `PATCH`. The [Get trusted CA list](/reference/authentication/get-trusted-ca-list.md) page and its diagram use `GET /trustedList` and `POST /connect/token`, instead of `/trusted_list` and `GET/POST`. Descriptive mentions of `/authorise` remain on the [access token](/identity-provider/access-token.md) and [Conformance Test Tool](/introduction/conformance-test-tool.md) pages. * Outdated links and cross-page anchors are repaired. Old Satellite and 2.x addresses, and the OpenID4VCI and OpenID4VP pages that moved under *H2M Verifiable Credential Endpoints*, redirect to the current pages. * Required fields are marked the same way on every page, and typos, spelling and stray characters are corrected, including the missing `&` separators in the token and authorize requests. The TLS page links RFC 8446 for TLS 1.3. **Other iSHARE sites** * [Trust Framework](https://framework.ishare.eu/): the glossary is revised (RFC032) and went live on the 3.0 site in stages between January and April 2026, and Identity Providers MUST validate the organisation identifier during onboarding, published in May 2026. The framework and roles page counts seven roles and explains the difference between a participant and a party, and the five-step Authorisation Registry discovery logic is on every page, with registration per service provider in step 2. Examples, including a valid `did:ebsi` identifier, redirects, glossary anchors and links are corrected, and the version history lists 3.0.1. The Data Rights Credential example uses the type `DataRightsCredential` with `relatedResource`, as the credential schema requires, licence identifiers follow the licences catalogue, and the name iSHARE Trust Framework is used throughout. The archived PDFs of earlier versions and the GDPR factsheet can be downloaded again. The [Trust Framework release notes](https://framework.ishare.eu/releases/release-notes) list all changes. * [iSHARE DID method](https://did.ishare.eu/): the DID document example uses `did:ishare:EU.NL.NTRNL-12345678`, and characters of the `organizationIdentifier` outside the DID syntax MUST be percent-encoded, for example `+` as `%2B`. DID v1.1 and Controlled Identifiers v1.0 are added to the normative references, the v0.9 working draft page, which duplicated the specification, is removed, and the text uses the name iSHARE Trust Framework. The LEI examples have valid check digits, and typos are corrected. The specification now follows the Trust Framework version numbers; the version published with 3.0 (then v1.0) stays available at [did.ishare.eu/v3.0](https://did.ishare.eu/v3.0/). * [Licenses](https://licenses.ishare.eu/): every version page states its status, the industry examples use valid ISIC Rev.4 codes, and three general licences no longer start with an outdated summary line. On *Enrich with own data*, that line contradicted the licence terms. * [Trust Body of Knowledge](https://trustbok.ishare.eu/): the DID document example uses `did:ishare:EU.NL.NTRNL-12345678`, the TLS requirement is the same as on this portal, the test certificate page asks for the party identifier instead of the EORI number, the `did:ishare` template and identifier examples are complete, the technical FAQs carry a notice that some answers predate 3.0, and broken links are repaired. ### Not changed in 3.0.1 These topics are open and are not part of this patch release: * The alignment of the OpenID4VCI and OpenID4VP pages with the final 1.0 specifications. * The final form of licence identifiers. The examples on the [licences model](/licenses-model.md) page follow the licences catalogue. * A single encoding for `x5t#s256`. * Structured `alsoKnownAs` identifiers (RFC078). * The Participant Registry without a distributed ledger (RFC044), planned for release 4.0. * The Data Rights Credential changes, which come in 3.1. That release will be published under `/v3.1/` on [schemas.ishare.eu](https://schemas.ishare.eu/), next to `/v3/`, which serves the 3.0 line. ## Historical releases ### Version 2.0.1 Version 2.0.1 introduced a new publication engine, role getting-started pages, formal-framework notices, a revised introduction, and the [single-party endpoint](/participant-registry-role/single-party.md). ### Version 2.0 Version 2.0 introduced the Satellite role (now Participant Registry) for participant administration and the Data Spaces concept. The changes included the `roles` attribute replacing `certifications` in `/parties`, the `/dataspaces` endpoint, and the `/ep_creation` endpoint for creating an Entitled Party. For migration, implementations should use the current API specifications, support the current `/parties` representation, and follow the current [M2M authentication guidance](/reference/authentication.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://dev.ishare.eu/introduction/release-info.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.