RFC050: Allow service provider to retrieve delegation evidence on which it is mentioned without service consumer's client assertion
NOTE: Do not assign and RFC number yourself. If you would like to raise an issue that could lead to an RFC, raise the issue without an RFC number. The Change Manager will discuss the proposed RFC in the Change Advisory Board and assign an RFC number if the change is accepted.
Background and rationale
Currently, the developer portal describes on https://dev.ishare.eu/reference/authorization.html:
- An organisation can only request evidence for an Authorization policy that concerns this organisation. The organisation is either the creater or issuer of the policy, or is the subject to which the policy applies.
- The only exception to the previous rule occurs when a Service Provider needs to gather delegation evidence for a client. The Service Provider needs to pass a valid client_assertion of this client to the Entitled Party / Authorization Registry. This proves that this client is indeed at the gate of the Service Provider and it is necessary to ask about his authorizations.
This is not in line with common practice. For many use cases the service provider should be able to execute the service on behalf of the service consumer without having the client assertion available. Also, the framework description is less strict about who is allowed to obtain delegation evidence, as it describes on https://ishareworks.atlassian.net/wiki/spaces/IS/pages/70221915/Functional+requirements+per+role:
The Authorization Registry-role is fulfilled by a legal entity who provides solutions for Adhering Parties for the storage of delegation information. An Authorization Registry:
Can hold information on delegations to Service Consumers;
i.e. information indicating what parts of the rights of an Entitled Party are delegated to a Service Consumer;
Has a process in place allowing for the registration, update and revocation of delegations;
Can check, on the basis of this information, whether a legal entity is authorised to take delivery of a service;
Can confirm whether this is the case to the Service Provider.
As a result, Adhering Parties can outsource tasks concerning the management of delegation information to an Authorization Registry instead of implementing their own tooling.
Proposed change: purpose
The purpose of the RFC is to bring the developer portal and functional description in line and allow use cases in which service providers require to check delegation_evidence without having a client_assertion of the service consumer available. Therefore,
Proposed change: considerations and requirements
- The developer portal description needs to be adapted
- Entitled parties that have provided authorisations before should be informed about the RFC.