Skip to content

RFC055: Allow conditions in delegations

Background and rationale

Core element of the iSHARE Trust Framework is the standardisation of Authorisations through the concept of Delegation Evidence. Delegation Evidence provides a structure to allow a Service Consumer to access a very specific service or data at a Service Provider on behalf of an Entitled Party.

Proposed change

Purpose

In some situations such a delegation could be depending on circumstances that are not yet known at the time the delegation policy (in whatever form that is stored) is created. Such conditions could for instance be:

  • A truck that arrives to pick up goods should have license plate X
  • The driver that arrives to pick up goods should be in possession of certificate Y
  • A service requesting data should be located in Europe
  • The status of a transport order is "booked"

All conditions that need trust and legal assurances following iSHARE principles can be achieved using this specification. Additional business rules may be applied by Service Providers and Authorisation Registries that are out of scope of this sepcification.

Description and principles

This RFC makes use of the current policy structure to allow parties to define conditions. From an iSHARE framework perspective the exact way of defining a condition is not defined, but presented as guidance. Conditions can be based on all sorts of attributes, for instance:

  • Attributes of the Service Provider (for instance the possession of a certificate)
  • Attributes of the data at the Service Provider (for instance the current status of a transport order)
  • Any other attributes (for instance the current weather situation)

To formally allow this, the attribute "delegation --> policySets --> policies --> target --> environment" will be opened up to extra optional properties, used to provide values on which conditions are evaluated on. Currently, the iSHARE framework only allows an array of serviceProviders as properties of this object.

The format in which conditions can be defined will be presented as guidance only, to support dataspaces with making interoperable choices on how to allow conditional delegations. The format is based on XACML and ODRL standards.

Considerations and requirements

The definition of the target object in the policy object contains the "Environment" property (not to be confused with the environment property of the target object in the policy set object). Currently the documentation only allows for the use of serviceProviders as property of the object. By making this free text and and the same time providing guidance on how to define environments and this way define conditions, iSHARE could support dataspaces with making interoperable choices on how to allow conditional delegations.

ODRL could provide a syntax for specifying logic.

Solution principles

To enable entitled parties to provide with business rules as additional conditions to authorisations, following scenarios are recognised:

Scenario A: evaluate conditions by Authorisation Registry

In this scenario:

  • The Entitled Party has provided conditions to the Authorisation Registry
  • The Service Provider or the Service Consumer (depending on which party requests delegation evidence) provides the required values while requesting delegation evidence
  • The Authorisation Registry evaluates the provided values with the provided conditions, as part of the decision process to (not) provide delegation evidence
  • The Service Provider decides (not) to deliver the requested service based on the delegation evidence provided by the Authorisation Registry

This scenario is relevant for instance in the case when the Service Provider drives authorisations. This means that an Entitled Party decides that a Service Provider should enforce a certain condition. In the scenario where a service engineer (Service Consumer) wants to consume data from a device (owned by The Entitled Party), the device owner could define that the Service Consumer should be able to present the right certifications, something that has to be enforced by the Service Provider (the supplier of the device).

Location of values in the delegation mask: delegationRequest --> policySets --> policies --> target --> environment

{
...
  "environment": {
    "serviceProviders": [
      "EU.EORI.NL567891234"
    ],
    "license_plate": "XYZ",
    "order_status": "to_be_picked_up"
  }
}

Scenario B: evaluate conditions by Service Provider

This scenario only applies when the Service Provider requests delegation evidence. In this scenario:

  • The Entitled Party has provided conditions to the Authorisation Registry
  • The Authorisation Registry does not evaluate the conditions itself, but instead returns the conditions as rules (part of the returned delegation evidence after a delegation evidence request)
  • The Service Provider evaluates the conditions that are presented in the rules and decides based on the evaluation to (not)provide the requested service

delegationEvidence --> policySets --> policies --> rules --> conditions

The structure of conditions is proposed as follows

{
  ...
  "rules": [
    {
      "effect": "Permit",
      "conditions": {
        "anyof": [
          {
            "allof": [
              {
                "leftOperand": "a",
                "operator": "equal",
                "rightOperand": "b"
              },
              {
                "leftOperand": "c",
                "operator": "equal",
                "rightOperand": "d"
              }
            ]
          },
          {
            "leftOperand": "e",
            "operator": "equal",
            "rightOperand": "f"
          }
        ]
      }
    }
  ]
}

Scenario C: allow both options

Option C is combination of both options A and B above.

  • The Entitled Party has provided conditions to the Authorisation Registry. The Entitled Party must be allowed to mark conditions as 'to be evaluated by the Authorisation Registry'.
  • If the Service Provider or the Service Consumer (depending on which party requests delegation evidence) provides the required values while requesting delegation evidence, then the conditions for which the values are provided are evaluated by the Authorisation Registry
  • All conditions that could not be evaluated by the Authorisation Registry (because no values were provided or something went wrong while evaluating) are returned as rules to the Service Provider or Service Consumer, except for the conditions that are marked as 'to be evaluated by the Authorisation Registry'
  • If conditions 'to be evaluated by the Authorisation Registry' could not be evaluated, this must lead to a deny
  • The remaining conditions are evaluated by the Service Provider / Service Consumer

This scenario provides flexibility for the involved parties to determine which party evaluates which conditions and respects the end responsibility of the Entitled Party in this.

This is the scenario that has been translated in this impact analysis (see below).

Example:

Let's take an example of a human service consumer whose authorisations are provided by a human authorisation registry. There are multiple scenarios possible in the given context when the human service consumer is trying to access an service from a service provider. Say for the above scenarios we show relevant use case as below:

  • Case for scenario A: evaluate conditions by Authorisation Registry

    • The service is such that it requires determination of a skillset certification (vaakpasspoort) to properly determine the authorisations for the human service consumer. However, for various reasons like lack of required mechanisms in place at the service provider or incase of online service, its not possible for it to ask the skillset certification of the human service consumer. In this case, the service provider could supply the what value (which skillset certification) must also be met apart from delegation of the rights by its employer. In this case since the Human Authorisation Registry is connected to the Identity Provider of the employer (service consumer) it can validate this information as part of the evaluation conditions of the delegation endpoint request. In summary this scenario allows conditions to be processed at the authorisations registry based on the data provided by service provider.

  • Case for scenario B: evaluate conditions by Service Provider

    • Now just lets continue the example above, however, now the human service consumer is say physically present at the service provider and provides the certification (vaakpasspoort) via app or paper to the employee of the service provider for validation. But since, the service provider has many clients and each client has specific requirements, the service provider must know which validation rule must be applied when for which service consumer. The entitled party could send these rules (conditions) as part of the authorisation (delegation evidence) to service provider as shown in scenario B above. In summary this scenario allows conditions to be processed at the service provider based on the conditions determined by the entitled party and provided via the delegation evidence.

Since both are valid scenarios and different use cases may need to use either of the options or even both the options in some cases, our recommendation is scenario C, where both definations are added in the specs of Authorisation Registry role.

How does this affect interoperability

The proposed sections of the change in the technical specifications are optional as it may not be necessary to have conditions. The implementation of the spec will be mandatory from version xx in order to pass compliance tests from that version. However, this spec change is not retroactively applied to older versions. Since this is an optional change this change is fully backwards compatible.

Example use cases

Impact on the ecosystem

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

Formal role Technical impact Business / legal / functional / operational impact
Service Consumer Yes Yes
Service Provider Yes Yes
Entitled party Yes Yes
Authorization Registry Yes Yes
Identity Provider No No
Identity Broker No No
Data Space Administrator No No
Satellite No No

Impact iSHARE Foundation (Scheme Owner)

The following assets will be changed:

  • The iSHARE Trust Framework
    • The description of the Environment property of Target on https://framework.ishare.eu/is/structure-of-delegation-evidence will be changed to: "Contains information on the environment of the delegation, with which conditions may be evaluated."
    • The description of the serviceProviders property of Environment on the same page will be changed to: "Reserved name for an Array which lists the iSHARE client ID's of serviceProviders which are allowed to provide services to the accessSubject as described within this policy.".
    • On the same page an optional parameter of rules->rule->target will be added. Name: conditions, contained in: target, type: {}, required: no, description: "Optional conditions which must be evaluated before the rule applies. For guidance on how to interoperably define conditions, refer to the developer portal"
  • The developer documentation (as an extension of the iSHARE Trust Framework)
    • The description of the Environment property of Target on https://dev.ishare.eu/delegation/policy-sets.html#refpolicies will be changed to: "Optional field which contains information on the environment of the delegation, with which conditions may be evaluated."
    • The description of the serviceProviders property of Environment on the same page will be changed to: "Reserved name for an Array which lists the iSHARE client ID's of serviceProviders which are allowed to provide services to the accessSubject as described within this policy."
    • In the rules section under target a new parameter conditions will be added. Object. Contained in target. "Optional conditions which must be evaluated before the rule applies. For guidance on how to interoperably define conditions, refer to <link>."
    • A page about conditions shall be added to the developer portal, providing guidance on how to interoperably define conditions, based on the text in the RFC.
  • The OpenAPI definitions on Swaggerhub
    • The schema for the delegation request (delegationRequest --> policySets --> policies --> target --> environment) must be redefined
    • The schema for the delegation evidence (delegationEvidence --> policySets --> policies --> rules) must be redefined

The following assets will not be changed:

Implementation

Release schedule

Communication

[ ] TODO Describe required communication topics and means.

Edited by athishare