DI4R In Mesh Approach
DI4R in Mesh federation approach is a logical next step in the further decentralization of the federation, which is welcome for operational and organizational reasons.
Initially, the mesh federations relied on bilateral connections between IdP and SP. This allowed for communication of identity and personal attributes very well, but for multi-party research collaborations (involving several home organizations), it either required the harmonization of schema to contain collaboration-specific data or all of that data needed to be stored at the SP side in the application (which was suboptimal for both provisioning and deprovisioning).
This constraint made it desirable to implement Attribute Authorities that would act as third parties in the login flow.
However, the model did not scale well. If a single federation-level AA entity was created, it became a single point of failure. Therefore, some SPs would rely on multiple AAs, but since there is no AA discovery in existence, they always had to query all AAs, creating technical problems.
What is worse, by querying an AA the SP will release the login identifier, such as an eppn to all AAs therefore advertise the timestamp and the user of the authentication for all AAs even if there is no relation between the AA and the user.
This proliferation very quickly got to its limits.
In the DI4R scenario the user brings some of their own attributes in a wallet or similar technological solution. These attributes may be in the form of claims, in which case they should be verifiable. Since the claim issuers are known from the claim itself, there is no need for discovery of where to turn for verification.
Finally, this approach may completely replace the home organization and let the user present both their identity and attributes/claims to the service upon access.
In the case of the mesh federation, the DI4R approach is a logical next step towards decentralization: at the time of login the home organization is not even necessary, only when issuing the claims.
Also, while the connection between two institutions is a bureaucratic process involving both parties joining the multi-lateral framework of the federation, in the DI4R case no such step is necessary: one organization may unilaterally decide to release claims while another to accept those, with the user app/wallet being the transmission mechanism in between.
However, some infrastructure is still necessary for verification.
But this infrastructure can be more lightweight than a federation metadata and tools: for instance, it may be implemented on a blockchain, not requiring any central nodes or governance.
DI4R In Proxy Approach
DI4R in Proxy Approach is a logical extension of the available data sources for a service, for which the multi-protocol proxy was created in the first place.
This arrangement has the same limitations as the initial arrangement of the mesh federation: the sole source of all information is the IdP.
This is circumvented by the insertion of an attribute authority or a membership management system. In this arrangement the proxy is the glue and the point of integration / protocol translation, therefore the communication with the AA will happen at this point. The proxy implementation provides a place to execute some business logic, i.e selection of the AA based on where the user is coming from.
The repetition of the idea - insert a proxy to handle conditionals or complement the data sets - leads to a chain of proxies - is quite common. In hub-and-spoke federations, users to go through a chain of proxies. The reason for this is that there is no other way of two hub-and-spokes to interfederate (if they follow the model fully and IdPs only talk to a national proxy). Moreover organizations within a federation also tend to have their own proxies. This poses some challenges: the single-sign-out does not work very well and the interpretation of the GDPR roles - data processor, data controller is not straightforward in a chain of proxies.
DI4R vs proxy
With the insertion of DI4R, some of these problems can be circumvented, especially if the role of the IdP is also taken over, not only the role of the AA. Data protection is enhanced by the fact that the wallet may hold targeted, or polymorphic pseudonymous encrypted data.