Skip to content

RFC071: DSGO proposals to improve roles and authorisations

Background and rationale

During the onboarding of DSGO onto the iSHARE framework we identified a couple of improvements for the authorization part of iSHARE. These observations are worked out in the DSGO RFC's.

This RFC aims to transfer our findings as improvement of the iSHARE Trust Framework.

Proposed change: purpose

Suggestions from RFC021: Datadienstbroker and updated roles:

  • Clarify the role of legal data service customer. This is a legal role an organisation can fulfil in consuming a data service. The legal data service customer hires another (software) company to fulfil the technical data transaction on its behalf. This software company is the authorised data service consumer.
  • Rename the role of entitled party to Data service rights holder. This is more in line with the iSHARE definition and also makes very clear that this rights holder is associated to the data service offered by an authorised data service provider.
  • Add additional operational and legal requirements to authorised service consumers and service providers that act on behalf of data service rights holders and/or legal data service consumers. This includes: ISO27001, certification, contract administration, incident management towards their customers and on behalf of their customers in the network, etc.
  • An authorised data service provider offering data services on behalf of a data service rights holder must offer a /data_services endpoint in which it shows which data services it offers and on which data service rights holders behalf. The endpoint may be protected.

Suggestions from RFC018: policyEvidence:

  • in iSHARE the term delegation is used for different kind of authorisations. We see three kind of authorisations: accessRight from data service rights holder to (legal) data service consumer, delegation from data service consumer to data service consumer, and supplierDelegation from legal data service consumer to authorised data service consumer. We propose to update the framework functional descriptions and use the terms more consistent to ensure we all talk about the same functional authorisation.
  • The roles itself does not really have to change. A legal service consumer can simply be a service consumer with only legal_adherence. The authorised service consumer and service provider can be their role with a higher level of assurance: substantial if they offer their own AR and high if they also support an external AR.
  • In iSHARE it is possible as a data service consumer to provide a delegationEvidence to the service provider. In our opinion this can only be a delegation or a supplierDelegation. The original accessRight should always be managed between authorised data service provider and data service rights holder.
  • We propose to use the OAuth2.0 Token Exchange solution to provide a SupplierDelegation to the data service provider. This solves the issue with limited header size (4-8kb) that prevent using the header for exchanging delegation_evidences.
  • A delegationEvidence describing that an authorised service consumer acts on behalf of a legal data service consumer as software supplier needs a signature. This can be done by the legal data service consumer but also by the authorised service consumer (the software company) or an AR (third party). The service provider and/or data service rights holder authorization rules determine which type of signature is required to access a service. The latter two are preferred and fully conform iSHARE. The self declaration is only allowed if the authorised data service consumer is certified, registered in the participant registry with a loa of middle.
  • The RFC includes a sequence diagram where all roles in a data transaction where multiple software companies are involved clarifies the way delegationEvidences and authorization decisions should be handled.
  • In the sequence diagram we also distinguished the AR's endpoints into a PRP endpoint to retrieve a delegationEvidence and a PDP to evaluate an AccessRight for a service consumer.
  • We suggest to add a couple of licenses for software suppliers. In these licenses a legal service consumer can define that a software company in the role of authorised data service consumer is allowed to transport, transform, and process data or in the role of authorised data service provider to provide a data service and/or process data.

Suggestions from RFC026: Open ID AuthZEN in plaats van XACML:

  • This RFC includes a simplified version of the delegationEvidence information object and also the interaction between the PDP from a data service provider towards an authorization registry (or data rights holder offering its own PDP).
  • The RFC is based on the AuthZEN standard and extends this framework with data space properties (i.e. the Methods GET, POST, PUT, the subject properties of service-consumer, delegations, partial approval, etc.)

Proposed change: considerations and requirements

The above improvements are fundamental and make the iSHARE framework more straightforward to implement. It suits better to practical implementations in which software companies implement data services on behalf of their clients. Moreover, the terminology and object structures are more self explaining which makes implementation less complicated.

Edited by digigo-koen