iSHARE is a trust framework that allows API’s to seamlessly integrate with each other and communicate in a trusted way and only share data when authorized. 

For developers its key to understand the basic principles of iSHARE prior to starting the development of connectors.. So let’s get to it:

iSHARE is federated, which means that there is NO central power, NO pre-exchanged authentication keys and NO pre-exchanged participant details. Through the use of the data in the iSHARE Distributed Ledger or Blockchain the details of how to communicate with others is made available. Only through trusted onboarding parties become available in the network and with every interaction a validation is done against the trust network and the authorizations. 

But for full interaction there are more components required to have agreed, so thats where the OpenDEI.eu model is very supportive:

In the technology building blocks of a data space iSHARE ensures trusted exchange, Access policies, standards on Identity management and basic discovery. Next to that iSHARE does active governance for operational, trust and business aspects of the data spaces. 

To have a full understanding of the flow of iSHARE transactions against the roles we start with an example of core data sovereignty: 

Where a Government body (data consumer) requires data from organisation T (data owner), and usually prior to getting that going parties exchange API endpoint addresses, Authentication Keys and give full access to API’s in that structure. In iSHARE that is not required and the authentication flow happens on the fly.

So the first step is to validate in the iSHARE network if an organisation is active in the Trust network, and to check if required capabilities are available. The iSHARE network (DLT) provides feedback through Party Endpoint based on the unique identification number of the organisation (EORI by default).

With this pointed and configuration of the pointer to the capabilities, the service consumer can check where the data is and start to communicate with the platform or endpoint that is the Data Provider:

In the next step the data provider checks against the authorization registry from the data owner if there is an authorization on the data set. In this case there is no authorization and there is a NOK returned by the Authorization Registry.

But this request triggers the AR to check against the data owner if a policy can be created for this data consumer and data provider combination.

With that confirmation the AR is updated and upon the next request the data provider will receive an OK from the AR. That communication triggers the exchange of the authentication keys generated on the basis of the public EIDAS keys available in the network and hence provided back to the data provider and data consumer. Though this the highest level of connection security is reached. 

In this flow the data sovereignty is totally assured by the trust network and can parties share their data with an ensurance of trust. 

This is the base flow and there are much more examples, so for that we would like to invite you to some of our portals: 

• Full specifications of the iSHARE Standard and framework are available on our Wiki
• Source code examples and example implementations are available on Github
• And full support to the development community on Slack and on the iSHARE support forum

Further more we have a fully automated testing sequence available for your a developer, please get in touch with us.