Practical steps to getting started with Policies for a Research Collaboration
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 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.
Why? While management of the user directory, or responding to compromised credentials and questions from your service providers may appear a technical task, these often involve decisions that deal with your 'primary assets': the research data you work with, the processes that keep your community together and wholesome. A handful of people working together can solve issues that arise in an ad-hoc fashion, but as soon as you grow a bit further, structured communication becomes essential. "Why was I suspended?" "Why can't I join your group ... you have a service I need (and by the way, I just want to use it, not contribute)?". You need a body to take up that authority. Unfortunately, the AAI is often the first time you hit these hard questions!
Recommendation: A principal investigator, research group chair, or faculty dean makes a good starting point for a local governance body. If your community becomes larger, write down rules of participation, draft a memorandum of understanding, or have a written collaboration agreement in place. Often there is already something there: many public research projects require having a collaboration or grant agreement. There is usually a governance structure in there, which can be re-used here. No need to re-invent the wheel within your community.
Applicable guidance: governance as such is out of scope of the PDK, but look at your project agreements, department model, or grant office to find a suitable and effective solution.
Why? As you connect services and infrastructures to your collaboration via the AAI, these will have their 'acceptable' (and unacceptable) use defined. They provide services based on what what you, as a collaboration, are planning to do, pay for, or because of shared goals and ambitions. Your users should be acting as part of your community, so also they need clarify as to what the collaboration is for. To prevent each and every infrastructure and service provider asking the users to comply with their acceptable use - and having to remember on your behalf what the collaboration's goal in life in - the common WISE Baseline AUP can do that in one go. But for that the purpose of use needs to be clear. Only you (as in: the collaboration) can provide that clarity
Recommendation: be clear and concise in how to word your purpose. A one-line sentence is needed to be inserted verbatim into the WISE Baseline AUP that you should show to users enrolling in your collaboration (or that your AAI service provider will show on your behalf when new users join). This is not the place to write a grant proposal ...
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. And protect your own peers in the collaboration: they should know how their name, email address, or roles that are used in the AAI are protected. And for some sensitive or high-profile research, also names and contact info needs to be protected!
Recommendation:
identify your crown jewels or primary assets. These are not computer things, nor your AAI, but research data, research processes, and knowledge.
define your rules of participation and the escalation procedure in case of non-compliance. If you are dealing with sensitive subjects, or sensitive research, consider the risks and what measures in your AAI can help. If you use a hosted AAI, discuss the conditions and guarantees with your (Snctfi-ed) provider.
Adopting the REFEDS Data Protection Code of Conduct - if it can apply to your research collaboration - to clarify privacy for access personal data (the personally identifiable information that results from your collaborators usin services, infrastructure, and the AAI itself)
Do a (brief) risk assessment to check the impact of inadvertent or malicious events. Prioritise risks your crown jewels, and keep in mind that controls should not make your primary mission impossible!
Does your collaboration work with human, societal data, or collects questionnaires? Is your research likely to be classed as dual-use or export restructured? Does the research, or your collaboration users, touch on knowledge safety? Is approval by medical/ethical commissions needed? Are you dealing with biodiversity or genetic resources subject to the Nagoya Protocol? Do a specific risk assessment or ask your institution for guidance.
Ensure that the policies are presented to and accepted by the relevant audiences
Publish your documents and responsible parties at a suitable location
Your entry point into 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 service providers.
Policies in 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 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!
WISE Baseline AUP guidanceWISE Baseline AUP guidancweAttribute authorities and membership services guidanceManage your community membersOperational Security for your servicesSecurity for your servicesIncident Response collaborationService Levels and data classification
Templates and guidelines to get started
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. A quick overview of the 'getting started' templates and guidance documents is given here below.
Document
AARC template for interoperability
Examples where no template is recommended for interoperability purposes
Snctfi, operational policies, and AAI service providers
The Snctfi subset of assessable and verifiable policies and procedures in the PDK (from: AARC-i082)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.
Like Sirtfi for security incident response, Snctfi provides a self-assessment framework, but having this assessment peer reviewed brings several benefits. For one, it increases the trust others have in your platform and your assessment, making it easier for ‘as-a-service’ operators to engage with new collaborations and infrastructures. And it brings advantages to yourself as well, as you can compare notes with your peers and become better together through shared learning.
AARC does not endorse any specific AAI platform or platform provider. By asking Snctfi specific information you can inform yourself about the suitability of the provider of your choice, and work with them to ensure your bases are covered by a secure, resilient, and interoperable AAI.
Learn more about Snctfi in AARC-I082 "Trust framework for proxies and Snctfi research services"
Background to the Policy Development Kit
Analysis of the first (2017) version of the Policy Development Kit by the Australian Access Federation. The original set of templates, both policies and procedures, were primary targeting larger research collaborations.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 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)
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.
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 model presented above.