RFC045
Last updated
Last updated
Issue reference
#12+
Document status [draft/final]
Final
One of iSHARE's main principles is that organisations can become participant of a data space based on the iSHARE framework. Once an organisation is a participant, organisations are trusted by other data spaces that are also based on the iSHARE framework. Data spaces can optionally require additional trust requirements for their participants.
Members of a data space can communicate with participants of all data spaces within the iSHARE network, based on the trust that is provided by the iSHARE Trust Framework. To support interoperability, the iSHARE Satellites are currently connected using a distributed ledger. This leads to better discoverability of participants and easier onboarding for participants in multiple data spaces. This technology however, is not part of the iSHARE Trust Framework itself.
Closely related to this RFC are the following RFCs:
RFC044: #2+
RFC040: #5+
RFC031: #11+
This RFC started with the requirement to accommodate an approach where the trust perimeter is less strict: a perimeterless approach, i.e. a zero-trust network. Organisations can interact with other organisations based on a more specific level of trust. Level of trust requirements could for instance be membership of an iSHARE based data space, membership of a specific data space, or other credentials (such as a certain certification, or a recommendation by a data space member).
In principle, iSHARE already accommodates this approach. With this RFC however, we want to further clarify how to implement this scenario with iSHARE and identify possible improvements in the iSHARE Trust Framework. This RFC supports the goals of iSHARE and complies with all , strengthening international orientation (principle 6).
To accommodate the idea of a zero-trust network, Verifiable Credentials may be used. This change is covered in RFC040: #5+. In general, the following logic will take place when a Service Consumer requests a service from a Service Provider, based on a Verifiable Credentials approach.
The Service Consumer provides it's identity (either via the existing way, or via a Verifiable Credential (see RFC040: #5+))
The Service Consumer provides the additional credentials (using Verifiable Credentials)
The Service Provider decides if the service can be provided
The Service Provider fetches the required delegation evidence from the Authorisation Registry, or the Service Consumer provides the delegation evidence
If all required delegation evidence is present, the service is provided
The current iSHARE specification is also able to solve this. Irrespective of which method is chosen, the iSHARE Trust Framework provides legal coverage.
Existing iSHARE data spaces are not affected by this change, which makes this change backwards compatible.
Example implementation: nested data spaces
This RFC supports the idea of data space branches. Let's take the following example.
Consider the data space
Inland Shipping NL, where
Inland Shipping NLis a branch ofShipping NL, and
Shipping NLis a branch ofLogistics NLA Service Provider (member of
Inland Shipping NL) receives a request to consume a service by a Service Consumer. The Service Provider could decide on behalf of the Entitled Party to deliver it's service with a following logic:
If the Service Consumer is also member of
Inland Shipping NL(Service Consumer A) AND the correct Authorizations from the Entitled Party are present, the service can be deliveredIf the Service Consumer is not member of
Inland Shipping NL, but is member ofShipping NL(Service Consumer B), the Service Provider requires extra credentials AND requires the correct Authorizations, after which the service can be deliveredIf the Service Consumer is not member of
Inland Shipping NL, but is member ofLogistics NL(Service Consumer C), the Service Provider requires even more credentials AND required the correct Authorizations, after which the service can be deliveredThis concept helps in achieving trust interoperability. Of course other types of interoperability (specifically technical and semantical) are required to become fully interoperable.
Extra credentials can be anything, for instance:
Membership of an industry organization
An ISO certification
Proof of past behaviour (successfull deliveries)
Etc.
Of course this is just an example. The 'nesting' of data spaces is not required. A participant can be member of any number of iSHARE based data spaces and present credentials as and when necessary. These data spaces don't require any relationship other then that they are both based on the iSHARE framework.
The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role).
Service Consumer
no
no
Service Provider
no
no
Entitled party
no
no
Authorization Registry
no
no
Identity Provider
no
no
Identity Broker
no
no
Data Space Administrator
no
no
Satellite
no
no
This change will only impact the framework and documentation maintained by the Scheme Owner.
A preliminary impact analysis is that the following assets are impacted:
During implementation it might become clear that other assets are impacted as well.
Work on implementation is not dependant on other RFCs; implementation can be done in a few weeks.
Changes will be included in regular iSHARE communication. No special communication is required.
The Service Provider decides if there is a need for additional credentials and if so, requests this from the Service Consumer (using a )
The iSHARE Trust Framework: : prepares it for the approach that is described in this RFC. Other assets are impacted with the implementation of other RFCs (RFC040 and RFC044).
The public website , for providing extra guidance on this approach.
The developer documentation (as an extension of the iSHARE Trust Framework): . We don't expect any changes in for example API endpoints, but clarifying texts might be changed.
The external support documentation on needs to be updated.
