AARC TREE Successfully Completed – Rethinking Interoperability in Research

Interview with David Hübner, Solutions Engineer

David, today we want to talk about the EU initiative AARC—more specifically about its most recent follow-up project, AARC-TREE. Before we get into that, could you briefly explain what AARC actually stands for and what problem the project originally set out to solve?

Yes, with pleasure. AARC stands for Authentication and Authorization in Research and Collaboration, and TREE stands for Technical Revision to Enhance Effectiveness. It’s quite a nice acronym with a lot of complicated words (laughs).
AARC—the two A’s already give it away—Authentication and Authorization. In other words, it’s about building AAIs, infrastructures that handle authentication and authorization. Research Collaboration, or RC, refers to research infrastructures in general. Ultimately, it’s about how to enable access to resources in federated—i.e., decentralized—systems, how to authenticate, and how to prove that I have access rights to certain resources.
Over the years, a very chaotic situation has developed, because each research infrastructure built its own technical solutions, leading to incompatibilities. There were different levels of technical maturity and different approaches. When the first project phase began in 2015, AARC set out to bring all these different solutions together and harmonize them to ensure interoperability.
The term that emerged from this effort—and also the most widely adopted outcome of the AARC projects—is the BPA. BPA stands for Blueprint Architecture. It is essentially a blueprint consisting of various building blocks for how to technically implement an interoperable AAI in research infrastructures.
AARC-TREE is now the third project phase. There were two previous phases, and we [DAASI International] were involved in all three. The first two phases laid the groundwork—for example, by developing the Blueprint Architecture and creating sample documents and guidelines at the policy level. In AARC-TREE, the focus was less on creating entirely new things and more on building on what already exists and making it fit for the latest developments.

You’ve been involved from the very beginning. What exactly is your role in the AARC project?

In the first two project phases—AARC 1 (2015–2017) and AARC 2 (2017–2019)—we were active in almost all work packages. We contributed to the architecture work package, where the BPA and all the technical documents were developed—covering which protocols to use and what technical solutions should look like. We were also involved in the policy work package, meaning we helped develop guidelines and policies such as SIRTFI for handling security incidents in federated systems.
In addition, during the first two AARC projects, we participated in the pilots work package, where we implemented and tested technical and policy solutions in concrete pilot projects. As representatives of DARIAH, the research infrastructure for the humanities, we implemented AARC results within the DARIAH AAI.
In AARC-TREE, our involvement was somewhat reduced, and we focused strongly on architecture. We contributed to all technical areas, and I was involved in developing the new version of the Blueprint Architecture—the BPA 2025—as well as the specifications and documents that accompany it and describe individual aspects of the overall architecture in detail.

I recently read the blog post about the official conclusion of the two-year AARC-TREE project phase and its results. What would you personally highlight as the most important outcomes of AARC-TREE?

That’s always a difficult question, because everything is important in some way. But if you look at it broadly, I would say AARC-TREE produced four key outcomes.
The first is the revised Blueprint Architecture, the BPA 2025, which—and this is important—is backward compatible with existing implementations. No one needs to replace established systems, but it enables alternative scenarios that have emerged in recent years, particularly in the European context—for example around the European Open Science Cloud (EOSC) or digital wallets—and that shift the approach from “community first” to the alternative “identity first.” In practice, this means there is always a central point (in Germany, for example, the Edu-ID) where connections to research communities are managed.
The second is a new version of the Policy Development Kit. This comes from the policy work package and is essentially a collection of document templates that research institutions can use to meet policy requirements. Practically speaking, these are templates that already contain a lot of pre-filled content and guide users—for example, when entering contact persons, security contacts, or specifying the purposes for which data is processed. A new feature is also an interactive map that shows which policies are needed by whom, allowing users to filter those relevant to their own infrastructure.
The third is the AARC Handbook. This is a collection of introductory and explanatory articles designed to help people who are new to the topic—and not particularly technical—understand what AARC does and what the individual documents and specifications aim to solve.
And the fourth is a validation kit that allows you to check your own technical implementations for compatibility with AARC.

That’s exciting! These really sound like practical resources that can be used directly for implementation. Was that the goal?

Yes, that’s how I would see it. In technical projects, the working groups naturally consist of experts who deal with these topics every day and have lived within these specifications for years. When someone encounters them for the first time and reads these highly technical documents, the question is always how they interpret them. We’ve gone through a learning curve ourselves and realized that people sometimes understand very different things. That’s why the goal—especially with the Handbook and the validator framework—was to make the results as accessible as possible and explain them in simple terms without requiring much prior knowledge.

I read that developments like token-based access and digital wallets have also been more strongly considered in the revised architecture. Given that a Europe-wide wallet infrastructure is currently emerging with the EU Digital Identity Wallet, to what extent was that a driver for your architectural decisions?

Exactly. The challenge is that on the one hand, wallets must be taken into account because they are already gaining importance and will become even more significant in the coming years. At the same time, in the federations and infrastructures we work with, there are still many systems that are probably not even at the level of the 2019 Blueprint Architecture and in some cases still rely on older technologies such as certificates (instead of SSO technologies like SAML or OIDC) or grid infrastructures. So there is a very wide range of technical maturity.
That’s why, in the Blueprint Architecture, we made sure to keep the concrete technical implementation open. It works with older technologies but does not exclude new approaches like wallets. We didn’t want to predefine everything but rather create the conditions for meaningful integration of wallets. There was also a dedicated document analyzing how such a complex architectural landscape could be implemented with wallets, and these findings were incorporated into the new BPA under the “identity first” approach.

The AARC Blueprint Architecture is a reference model, but many infrastructures are historically grown solutions. As an experienced Solutions Engineer and Product Owner at DAASI International, how difficult is it in practice to align existing systems with a common architectural model?

On the one hand, it’s not rocket science, because the underlying technologies are already supported by common products. For example, Shibboleth IdP—still the software we use for most authentication projects at DAASI—as well as our own solution didmos.
The feature set of Shibboleth IdP includes everything you need to implement a project in line with the AARC BPA. So getting started with the software products we use at DAASI is relatively straightforward.
The main technology described in the AARC BPA is based on introducing proxies between service providers and identity providers. This proxy functionality can be fulfilled, for example, by Shibboleth IdP or didmos Auth.
The challenge is that you have a large number of service providers—the services users want to access—and a large number of identity providers—the systems where users authenticate, typically with a username and password, but increasingly also with multi-factor authentication or newer technologies like passkeys. These two worlds need to be connected. Before AARC, this was done via federations. In such a federation, you might have 5,000 services and 1,000 identity providers from various universities, and any issues were solved individually at each service.
The key achievement of the AARC BPA is therefore the introduction of proxies. Instead of solving problems separately for 5,000 services, you place one or more proxies between services and identity providers. The trend is toward multiple proxies, as different problems are solved at different points. For example, AARC includes an “identity management” proxy layer, which in Germany can be provided by the DFN Edu-ID. DAASI International is also involved there, and the Edu-ID ensures that students and researchers have a lifelong identity that remains consistent even when they change institutions. Another proxy handles “collaboration management,” where group memberships and permissions within a research infrastructure are managed. Splitting this into two proxies makes sense, since the Edu-ID is centralized, while permissions within specific communities should be managed in a decentralized way.
Building a simple BPA-compliant infrastructure is therefore manageable. For example, within the NFDI AAI (National Research Data Infrastructure), we offer such a service “as a Service.” However, if you want to achieve interoperability with other infrastructures, the requirements increase significantly. You then need to implement not only the mandatory requirements from the AARC documents but also many optional ones. That’s where things become more time-consuming and complex. With the newly created AARC Handbook, the project has tried to lower that barrier even further.

You mentioned the EOSC earlier, the European Open Science Cloud. A lot from previous AARC projects has already been incorporated there. Who would you say benefits most from the results of AARC-TREE, and where will we see the impact first?

Technically, EOSC is certainly the frontrunner. New developments from AARC are typically implemented there first, and it is also the largest environment, since many research infrastructures from across Europe are involved and the requirements are correspondingly high. In that sense, EOSC is a major driver behind many of these developments, and I expect that new results from AARC-TREE will be implemented there very quickly.
Looking at Germany, we at DAASI are also active in the NFDI. It is somewhat like a smaller EOSC and is officially one of the 13 so-called EOSC nodes. It is also designed and built according to AARC principles. Not every innovation from AARC-TREE will be implemented there immediately, but the key results—such as interoperability with EOSC or, in the future, the integration of wallets—will now feed back into the discussions we are having within the NFDI.

AARC-TREE was a large international project with many partners. How did you experience the collaboration? Were there typical EU project challenges?

The “core team” that has been working together since the first AARC project through to AARC-TREE has become a very well-coordinated group. Of course, new people with new perspectives keep joining, which is essential for the dissemination and acceptance of the solutions, but you often see the same experts. Over the years, collaboration has therefore become very smooth. You know the participants, understand their strengths, and are familiar with the processes. Everything works very well now.
As a result, despite the huge technical complexity and the diverse requirements of an international project, the way of working is very efficient. At the same time, it is enriching and productive. The discussions are truly at the cutting edge—and that makes the work both exciting and enjoyable.

That sounds very promising, and naturally it raises the question: What comes next? AARC-TREE has officially concluded—will there be a new project with this well-established team?

For now, we have agreed within this established group to continue working together without new funding—simply to keep up with ongoing developments. The project phase may be over, but the work never really stops. There are always topics to discuss, new questions, and new challenges to address.
This group—let’s call it the AARC architecture team—will therefore remain in place. We at DAASI will continue to be involved, both to stay informed and to actively contribute in areas that are relevant and interesting to us.
Of course, there are always efforts to secure new funding, and there are topics that could be further developed in a potential AARC4 project. One example is how to extend concepts that have so far been tailored to research and collaboration—i.e., large research infrastructures—to other domains. A frequently mentioned area is schools. In some ways, schools are structurally similar to research infrastructures—they can be federated and may require access to shared resources or learning management systems.
Another topic could be university alliances—smaller networks of universities that are becoming increasingly important in Europe and bring their own challenges. These are all areas that could be meaningfully addressed in an AARC4 project. If things move in that direction, we would of course be happy to be involved again.

That’s a very nice closing remark. Thank you very much for your time and for the interesting insights into the AARC project work.

Further information on AARC-TREE and the project results can be found on the official AARC website as well as in the published documentation.