RFC041: Optimise delegation path discovery
Background and rationale
The current iSHARE Framework, as defined on the developer portal, includes the following attributes in the delegation mask model that is used for requesting delegation evidence.
-
delegation_path: Container for one or more iSHARE identifiers values for a situation where multiple delegation policies need to be linked together. -
previous_steps: Container for one or more pieces of evidence such that the client has legitimate reason to request delegation evidence. A single step contains either a previous delegationEvidence statement or a client_assertion. The minimum is a client_assertion value of the accessSubject, for example if the Service Provider requests delegationEvidence for an authorization in which he is neither the policyIssuer or the accessSubject.
Specifically in implementations in the logistics domain, in practice delegations are passed on to other parties. Consider for example a use case where a Shipper hires Transporter A, who subcontracts Transporter B, who subcontracts Transporter C, who eventually shows up at a warehouse to pick up goods on behalf of the Shipper. This is called a delegation chain.
Different solution scenarios have been tested in different implementations.
Proposed change
The proposed change is to extend the authorization registry such that it verifies full delegation chains. In part by extending the delegation evidence utilized.
Purpose
This RFC aims to list possible implementation scenarios with their respective pros and cons and include these in iSHARE's documentation. Research and define possible changes to the delegation chain model to allow for a better discovery of the underlying delegation.
Description and principles
Various delegation models can be employed to manage delegation chains, each with distinct characteristics. The aspects that are discussed for these models are:
- Zero-knowledge: are the parties that are involved in the delegation chain are unaware of their position within the chain. In the example: the Shipper should be unaware of what subcontracted transporters have been hired.
- Efficiency: traversing the delegation chain might require a lot of calls to different parties within the dataspace.
- Long running delegations: some parties might have long running delegations in place, where for instance a Transporter is delegated to access a warehouse for all shipments of a certain Shipper. If there are multiple long running delegations, these will possibly overlap and probably have different start and end dates.
The following principles are relevant:
- Authorisation Registries operate as "zero-knowledge evidence providers". To request evidence, a Service Consumer or Service Provider has to provide all details (issuer, subject (receiver), target/resources/etc.) to the Authorisation Registry, which in return provides the evidence or not. The Authorisation Registry cannot be queried with only part of the request, so as an evidence requester, it is required to know the issuer, subject an target/resources/etc.
Below, several delegation models are described, followed by a comparative table:
-
Recursively build path - Previous Party ID This model involves each piece of delegation evidence storing the identifier of the delegating party (the "previous party"). When validation is required, the Authorization Registry (AR) recursively checks if a valid delegation path can be reconstructed from the access seeker back to the ultimate data owner. This is achieved by looking up the delegation evidence issued to the prev_party to the current party, and then repeating the process for that prev_party. This approach offers flexibility, particularly in scenarios with parallel delegation paths, where multiple delegations can converge. For instance, a party might receive rights from two different sources and then delegate a combination of these rights. Revocation of one upstream delegation does not necessarily invalidate downstream delegations if an alternative valid path still exists for the delegating party. Privacy implications are generally minimal, as the delegatee is usually aware of their direct delegator. For cross-AR validation, as displayed in the iamge, there are two solutions. the evidence can be updated to include the AR identifier where the delegation was issued, or one can contact the party that issued the evidence to determine which AR they use. Revocation can be handled by maintaining a list of revoked delegation identifiers, which must be checked during path validation.
-
Recursively build path - Previous Delegation ID This model extends delegation evidence with a reference to the identifier of the preceding delegation evidence in the chain. This allows reconstruction and validation of the full path by recursively tracing back to the data owner. Each delegation's validity and revocation status (e.g., by checking against a revocation register) are verified. This model can support cross-AR validation if the delegation ID include registry prefixes. However, if a specific delegation in the chain is revoked, any subsequent delegations relying on that specific link become invalid.
-
Concatenation model - This model aims to reduce lookup overhead by embedding more chain information within the delegation evidence. *Full Concatenation: Each new delegation contains the complete sequence of all previous delegation evidence objects. This makes validation very efficient as the entire path is self-contained. However, it significantly increases evidence size with chain length and poses privacy concerns, as every participant sees all upstream delegation details. * ID-only Concatenation: To mitigate the issues of full concatenation, this variant includes only the identifiers of previous delegations (possibly prefixed with the issuing AR's ID). This still allows chain reconstruction without recursive querying but limits information exposure. Privacy is improved as only the position in the chain and identifiers are revealed, not full upstream details unless resolved. Both variants are compatible with multi-registry environments. The delegation_path attribute in the current iSHARE framework aligns with these concatenation models.
4.Macaroon model - This model aims to improve the chain validation time, as a macaroon can be validated with all contained information. With the first delegation the authorization registry generates a random secret key, and uses it to calculate the HMAC of the contents. From this point any further delegation simply uses this HMAC to calculate the new HMAC. Each delegation can caveats, these can constrain the access rights, but also point to external sources (e.g. check at an authorization registry that you still allow this delegation [revocation]). When the final party then presents this macaroon, the original authorization registry can validate the chain using the generated secret key, without necessarily contacting other party, unless required by external caveats. Further details can be found in the google whitepaper
The following table summarizes these scenarios:
| Model | Description | Zero-knowledge (Shipper unaware of subcontractors?) | Efficiency | Long running delegations |
|---|---|---|---|---|
| 1. Recursively build path - Previous Party ID | Each delegation stores previous party's ID. AR recursively validates path. Supports parallel paths. | Medium, shipper unaware except its direct successor, intermediates know direct delegator. AR validates full path. | Medium, Recursive calls to AR(s); DB lookups. Optimized if within a single AR. | High, very flexible, and revocation of one path doesn't break alternatives. Requires checking revocation list for individual delegations. |
| 2. Recursively build path - Previous Delegation ID | Each delegation references ID of previous delegation evidence. AR recursively traces and validates chain. | High, similar to Previous Party ID; direct predecessor ID known. | Medium, recursive calls. Each step validated, including revocation status. | High, supports revocation lists, and revocation of a link propagates to further links |
| 3. Concatenation model (Full Evidence) | Each delegation contains the complete sequence of previous delegation evidence. (previous_steps attribute mentioned before) | High, entire chain information exposed to participants holding the evidence. | Very High, local validation once evidence obtained. | Medium, revocation complex; if one link revoked, entire concatenated evidence potentially invalid unless re-issued or segments checkable. |
| 4. Concatenation model (ID-only) | Each delegation includes identifiers of previous delegations. (delegation_path attribute in iSHARE) | Medium, position in chain and IDs known; details not exposed without resolution. | Medium, chain structure present. Validation efficient but may need to check revocation status of all IDs. | Medium, similar to Full Concatenation. Revocation of one ID invalidates chain. Requires checking revocation list for all IDs. |
| 5. Macaroon model | A macaroon is constructed at the start, and extended with caveats for further delegations | Low, the only required information is on access constraints, unless a third party caveat reveals extra. | High, as the macaroon is mostly self-contained | Good, external caveats can be used to support revocation propagation. |
Example use cases
An example use case of this RFC is in logistics, such as the one shown in the image at the start of this RFC.
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 | No | No |
| Service Provider | No | No |
| Entitled party | No | No |
| Authorization Registry | Yes | Yes |
| Identity Provider | No | No |
| Identity Broker | No | No |
| Data Space Administrator | No | No |
| Satellite | Maybe | Maybe |
The table above describes the impact on different roles, it is possible however based on the details that an impact can be created on other roles as well. E.g. to support multiple authorization registries in a delegation chain, the id of the authorization registry can be added the evidence, or it can be queried from a satellite [creating an impact on the satellite].
It should be noted that the impact of the macaroon model is bigger than that of the other models, and that implementation details might find an impact on other roles than marked here.
Impact iSHARE Foundation (Scheme Owner)
The proposed changes in RFC041 will impact the iSHARE Foundation and its assets as follows:
- iSHARE Trust Framework: The framework will need updates to describe the new delegation path models, evidence structures, and validation requirements.
- Developer Documentation: Technical documentation and examples must be extended to cover the new delegation models and validation logic.
- Reference Implementations (Satellite, Authorization Registry): Updates are required to support the new evidence structures and validation flows.
- Test Tools and Conformance: Test cases and conformance tools should be updated to verify correct implementation of the new models.
These updates will ensure the iSHARE ecosystem remains consistent, interoperable, and aligned with the improved delegation path handling proposed in this RFC.
Implementation
Release schedule
This RFC will be released as part of version 3.0