RFC056: AR per application / data service

Background and rationale

BDI: In the BDI we expect a highly decentralized environment where all roles will exist multiple times... including AR. We understand that although a EP can select their own AR, the AR itself is (hard) linked to a specific data space. DIL expects we will have distinct BDI-based data ecosystems organized around a supply-chain, a modality, a geographic boundary or even a single buyer-seller transaction resulting in the logistics and transport coordination that the BDI supports. We forsee one organization will participate in multiple of these data spaces. Access to data will be derived from the logistics context and de state / lifecycle of the business transaction. We forsee an AR would be more focussed on supporting a type of transaction multiple in wich multiple participants have their access policies defined within than that de participant sees itself as the EP and feels need for it's own AR.

iSHARE: The Authorisation Registry (AR) role in the iSHARE Framework is defined as:

  • The Authorization Registry-role is fulfilled by a legal entity who provides delegation evidences as proof of delegations on behalf of entitled parties to other parties.

Within a data space there may be multiple services exposed by multiple Service Providers. Not every AR will be able to generate delegation evidence for each service / Service Provider, due to specific business context. The Entitled Party could use multiple ARs to accommodate all services. An AR could also be part of the service offering of a party that also fulfils to role of Service Provider. The current satellite specifications and the reference implementation already support registering multiple ARs per data space, but lack the ability to distinguish between different Service Providers / services.

Proposed change

Purpose

The purpose of this change is to accommodate that an Entitled Party can use multiple ARs within one data space and still maintaining proper discoverability.

Proposed change: considerations and requirements

An individual can be part of multiple organizations (Legal Entities) and can have various places where delegation access needs to be registered. An organization can be part of multiple data spaces and needs to point to one AR or multiple as desired, but not hard-coded to one specific DS per AR. An data product can have such specific requirements the AR is close knitted to the business rules and therefor policies need to be kept in that AR only (Schiphol example). The assumption is that the EP has data in that system and needs to accept that systems specific AR. So an EP might need to accept to have a 'forced AR' for a specific set of his data.

Considered solutions

The following solution scenarios have been considered.

No Approach Description Pros Cons
1 Use data space names with nesting Split AR by creating multiple data spaces, named per use case/service (e.g. bdi-ll79, bdi-dataservice1) No spec changes needed. Complex logic to map names to data spaces. Poor discoverability, admin overhead.
2 Add two properties per EP/AR combo Add Party ID (Service Provider) + service (capability) properties to EP/AR combination. Limited spec changes, discoverability via Participant Registry. No single capability identifier, complicated discovery, or admin overhead.
3 Publish AR in /capabilities An Entitled Party exposes a capabilities endpoint (probably supported by a Service Provider) in which the AR is declared for each capability. Flexible and confidential. Takes more steps to discover.

Chosen solution

After considerations, the CAB has decided to go with a combined approach.

  • Implement option 2 to allow Entitled Parties to select which AR to use for which Service Provider / capability.
  • Implement option 3 option as an optional property of a capability to allow Entitled Parties to declare which ARs are able to provide delegation evidence for this specific capability.

The following rules apply for conflict resolution:

  1. If the Entitled Party has registered a capabilities endpoint in which an AR is registered that must be used for a specific capability, then that AR must be used.
  2. Else if an Authorisation Registry (AR) is registered in the Participant Registry by an Entitled Party for a specific capability, that AR must be used.
  3. Else if the Entitled Party has registered an AR to be used in a specific data spase, the Service Consumer / Service Provider shall use this AR.
  4. Else the parties shall fall back to the default AR setting configured for the Entitled Party.

This logic makes this change backwards compatible, since options 3 and 4 is how it is configured today.

Impact on the ecosystem

The following specifications will be changed:

  • In the parties endpoint (GET and POST) and the single party endpoint (GET and PUT) the auth_registries object will be given an extra optional attribute called capabilityId.
  • In the capabilities endpoint the objects publicServices will be given an extra optional attribute called authRegistryURL.

The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role), based on the combined implementation scenario.

Formal role Technical impact Business / legal / functional / operational impact
Service Consumer Yes (for discovery of AR) No
Service Provider Yes (in capabilities endpoint) No
Entitled party Yes (capabilities endpoint) Yes
Authorization Registry Yes (in capabilities endpoint) Potentially (on functional onboarding and participation management flows)
Identity Provider No No
Identity Broker No No
Data Space Administrator No No
Participant Registry Yes No
Data Space Governance Body No Yes

Impact iSHARE Foundation (Scheme Owner)

Implementation

Release schedule

This RFC will be released as part of iSHARE 3.0.

Communication

No specific requirements.

Edited by athishare