...
The AARC Research Collaboration model is both the set of technical guidelines and interfaces in 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. 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? 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 following diagram summarises the full ecosystem of policies relevant for a research infrastructure. It is intended to be used in two scenarios:
...
| Scroll ImageMap | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...