Welcome to the Policy Development Kit!
The AARC Research Collaboration model is both the set of technical guidelines and interfaces in the AARC the AARC Blueprint Architecture (BPA) as well as the trust framework that helps research collaboration bridge across domains, sectors, and borders: the guidelines for end-to-end trust across the components for collaboration management, user privacy, identity assurance, and operational security. The Policy This Policy Development Kit (PDK) helps new and existing collaborations to build those trust relationships into their AAI and benefit from the combined experience of the infrastructures, collaborations, researchers and research managers, and trust and security engineers to quickly build that trust in our AARC connected world.
Practical steps to getting started with Policies for a Research Collaboration
Policy may appear a daunting or overly complex task if you start on your research collaboration journey, but with eight simple steps you can quickly navigate the policy space and avoid the most common pitfalls. Expand each step to learn the why and how of starting with your trusted collaboration quickly and smoothly:
| Expand | ||
|---|---|---|
| ||
Why? When your users connect to infrastructures and services, the services will need to identify the users as belonging to your group. And as you work together across sectors, you will want users with the same name but from different communities to work together. Similarly, if you use a shared AAI provider, for example based on the Snctfi guidelines, also there your collaboration should not be mixed up with others. Recommendation: use a name that is almost certain to be unique globally, and pick a name that is not prone to changes, avoiding project naming for instance. The domain name system (DNS) is a good starting point, for example "he3epp.nikhef.nl" for a national collaboration for studying the the 3He(e,e'pp) reaction at Nikhef, or "atlas.cern" for the global ATLAS collaboration located at CERN. Note that while the domains should be permanently assigned, you don't necessarily need a web site or email addresses with this domain. Uniqueness is enough. By using a DNS name, it fits easily in the 'scope' component of many AAI protocols like OpenID Connect and SAML. Applicable guidance: AARC-G069, PDK Membership Management guidance |
...
| Expand | ||
|---|---|---|
| ||
Why? "Bad things can happen to good science" (1), and while you may not think of it at first, the data, ways of working, and collections created in your collaboration are valuable and deserve protection. External cybersecurity attacks of course come to mind, but in many cases inadvertent accidents happen and are at least as big a risk. Identifying your 'primary assets' (or the 'crown jewels' of the collaboration) helps you to identify where you need extra protections, and how to prevent deletion, changes, or loss of data ... and people. There may also be legal and regulatory reasons to apply controls through your AAI. They can be in the research data itself, like medical and patient data, dual-use goods and knowledge, commercially confidential data, or ethical reasons on human research or in the Nagoya Protocol. Recommendation:
Applicable guidance: REFEDS Data Protection Code of Conduct, (1) Open Science Cyber Risk Profile (Sean Peisert et al, TrustedCI), ITSRM2 (risk management), Privacy Notices |
| Expand | ||
|---|---|---|
| ||
Why? This basic set of 6 documents helps get a sufficient set of collaboration guidelines quickly - you can always adapt them later Recommendation: these are the documents you surely need - or you need to ask from your AAI provider:
Applicable guidance: REFEDS privacy notice, UK-IRIS example privacy notice, EOSC, UK-IRIS security policies, AARC-I051 "federated incident response procedure" |
| Expand | ||
|---|---|---|
| ||
Why? Assurance means both knowing if the person on the other side is indeed the same user that you know, but also includes identity assurance, verifying that the person is indeed the one they claim to be: name and affiliation being the most visible elements. How strong that assurance needs to be depends on the type of research and the collaboration risk assessment. Recommendation: review the technical and policy guidelines endorsed by the AAI providers and infrastructures in AEGIS, the AARC Engagement Group for Infrastructures:
Applicable guidance: Assurance Requirements, AARC-G031 evaluation and combination of the assurance of external identities, AARC-G081 "Recommendations for Token Lifetimes" |
| Expand | ||
|---|---|---|
| ||
Why? You realise you need to enforce a policy only once things do not 'go as planned' - and having the discussion on acceptance at that point is rather late. And how can users, for instance, know what they are allowed to do with the research data, or when to ask for additional roles and group membership from membership management? Recommendation: the Policy Development Kit identifies five different 'audiences': governance, your users, the user home organisations and identity providers, the AAI management of the collaboration, and the infrastructures and service providers that control and host data, computing capacity, and the data transfer networks. Make sure all of then can access and understand your policies and processes, can work with you when you execute procedures for incident response, and engage with Sirtfi and security readiness exercises. Applicable guidance: AARC-G083 on notice management, WISE Baseline AUP and AARC-I044, Privacy Notices, REFEDS DP CoCo v2, membership managementMembership Management |
| Expand | ||
|---|---|---|
| ||
Why? Presenting policies and practices is one thing, but the AARC Blueprint Architecture also introduced a (chain of) AAI platforms or 'proxies' that augment, translate, or otherwise munge information about users and 'sources of authority'. Both for authentication sources and for service providers, it places intermediates in the chain of trust, and the longer the chain is, the more this trust will be diluted. Transparency through documentation can help retain that trust. And at the same time make it easier for the collaboration to engage with the users regarding the AAI. If identity is not bound to the user but to the user's home organisation (employer, university), the home organisation may be reluctant to make any claims for the authentication, even for trivial ones like name and email address (the 'personalised access' attributes that are foundational for research and scholarship). Or refuse to partake in authentication at all. Recommendation: publish your policies, but especially your contact information, in a place where users, relying parties, and home organisations can find it. If you chose a DNS-based community name, and you can resolve the domain name to point to a web site, that is a good place to present this information. And if confidentiality is needed, you may have your own AAI to help you! Applicable guidance: AARC-G071 (AAOPS), AARC-G083 on notice management, REFEDS Research and Scholarship, REFEDS Personalised Access, |
...
Maturing your trusted collaboration policy and good practice
The Policy Development Kit (PDK) version 2 identifies five main target audiences, functionally following the AARC BPA 2025 hierarchy and identifying (1) ‘Research governance’ as a foundational area. (2) ‘Users’ are (human) end-users who participate in a collaboration, are identified via (3) ‘identity’, i.e. external identity providers and the identity layer of the BPA, to be granted access by (4) ‘collaboration management’, to (5) ‘infrastructure integration and service providers’; in the BPA the infrastructure integration components, site-local integration components, and the actual following diagram summarises the full ecosystem of policies relevant for a research infrastructure. It is intended to be used in two scenarios:
- The practical steps listed above are insufficient to address the policy needs of your research infrastructures due to size or complexity
- The practical steps above are not relevant as you have a more specific role such as the operator of an Authentication Source
The Policy Development Kit (PDK) version 2 identifies five main target audiences, functionally following the AARC BPA 2025 hierarchy and identifying
- 'Research governance’ as a foundational area.
- ‘Users’ are (human) end-users who participate in a collaboration, are identified via
- ‘Authentication Sources’, i.e. external identity providers and the identity layer of the BPA, to be granted access by
- ‘Collaboration Management’, to
- ‘Service and Infrastructure Providers’; in the BPA the infrastructure integration components, site-local integration components, and the actual service providers.
Policiesin PDK version 2 are standards to which adherence can be asserted and that can be assessed and validated – for example as trust marks – and that are endorsed by AEGIS and considered ‘standards track’. Policies also are endorsed by the organisation at the appropriate level of management, and express a commitment of adherence by the organisation’s management. These are indicated in a roman font in the graphic below. The
Indicated in italics in the diagram processes and procedures, being templates, are reference implementations where we assume these to be specialised for specific deployments.
In the diagram these are indicated in italics. The semi-opaque elements are relevant, but fall outside of the scope of the PDK, which targets the authentication and authorisation infrastructure. But even if, for example. identifying the 'why and what' of your research collaboration (your 'primary assets') may not be AAI per-se (and hence greyed-out), it is very useful to know that before embarking on your AAI journey!
...
| Scroll ImageMap | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
All templates and guidelines as a handy list
The AARC PDK consists of templates - documents where the core content is either highly determined or should be treated as 'immutable' for better interoperability - and guidelines - helping research collaboration, infrastructures, and service providers with their own procedures and practices, where adopting good practices rather than the exact wording of a policy or procedure is the key value for interoperability. Can they help your trusted collaboration?
...
|
...
Snctfi, operational policies, and AAI service providers
Smaller and mid-sized communities may opt to offload some of the more complex aspects of authentication and authorisation to dedicated AAI service providers. And if you operate your own AAI core components, both your users and resource providers may want to have some assurance about the trust and security posture of your AAI platform. The Snctfi suite is the set of assessable and verifiable policies and procedures in the PDK that AAI platform providers can use to make the trustworthiness of their systems transparent to users and relying parties alike.
...
- Learn more about Snctfi in AARC-I082 "Trust framework for proxies and Snctfi research services"
Background to the Policy Development Kit
The first AARC Policy Development Kit, released in 2017, comprised a set of nine reference documents (mostly templates) addressing the construction and operation of community AAIs in the original AARC "2019" Blueprint Architecture, based on the Community First Approach. A mix of policies and procedures, its primary audience was primarily larger-scale research collaborations, expected to review, augment, and specialise the templates for their own use. With the policy development kit being created prior to or in parallel to other work in the community at large, it duplicated some aspects (privacy in REFEDS DPCoCo, or incident response work parallel to the eduGAIN Security Handbook), while being overly complex for smaller collaborations. Work by the Australian Access Federation, the AARC Community, and in REFEDS, WISE, IGTF, and the e-Infrastructures helped restructure the PDK into the v2 model presented above.
An analysis of the improvements required on PDK v1 is included in the informational document AARC-I082 "Trust framework for proxies and Snctfi research services" (doi:10.5281/zenodo.15506826)
...
This work and its supporting materials are licensed under a Creative Commons Attribution License (CC-BY) v4.0 unless otherwise specified.