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
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
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 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
/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
/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.
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:
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.
Make the changes in your code and test them in the test network with other parties or using dummy parties.
Publish your changes and request conformance testing. Details.
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.
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.
Last updated