Practical steps to getting started with Policies for a Research Collaboration


Note: we are missing DP CoCo from these steps


  1. Define a unique name for your collaboration (recommend DNS) 
  2. Identify a governance body to make policy decisions
  3. Define the purpose of your collaboration (this will be used for your AUP) 
  4. We strongly suggest (although this is out of scope here) 
    1. Identifying your primary assets
    2. Completing a risk assessment
    3. Defining your rules of participation and the escalation procedure in case of non-compliance
    4. Any additional legal and regulatory compliance necessary
  5. Define, or agree to adopt as is, the following 6 documents and seek endorsement from the governance body
  6. Review the AEGIS endorsed policy guidelines required for AARC compliance and ensure their technical implementation
    1. Identify your assurance requirements following https://aarc-community.org/guidelines/aarc-g031/ 
    2. Identify suitable token lifetimes
  7. Ensure that the policies are presented to and accepted by the relevant audiences
  8. 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.

All templates and guidelines

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 all templates and guidance documents is given here below.

DocumentAARC template for interoperabilityExamples where no template is recommended for interoperability purposes
Membership managementMembership Management
AUPWISE AUP
Privacy Policy
REFEDS privacy notice
AAOPSAttribute Authority Operational Security
Security Operational BaselineSecurity Operational Baseline
Incident response procedure EOSC, UK-IRIS, AARC federated incident response procedure

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.

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 provider of your choice, and work with them to ensure your bases are covered with a secure, resilient, and interoperable AAI.

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 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)





Research GovernanceUsersIdentityCollaboration ManagementInfrastructure Integration and Service Providers
Rules of Participation

Membership ManagementService Levels 'AIC' Security
Identification of Primary AssetsWISE AUP
WISE AUPWISE AUP
Research Risk Assessment
Attribute Authority Operational SecurityAttribute Authority Operational Security
Escalation Procedure
SirtifiSecurity Operational BaselineSecurity Operational Baseline
Legal and Regulatory Complience(EEA) Privacy NoticeREFEDS DP CoCoREFEDS DP CoCoREFEDS DP CoCo


WISE AUP and Privacy NoticeSensitive Data Access (Policies)Sensitive Data Access (Enforcement)


REFEDS Assurance FrameworkAssurance RequirementsAssurance Requirements



Incident Response ProcedureIncident Response Procedure



SirtifiSirtifi



Notice management (presentation)Notice management (provision)



Privacy NoticePrivacy Notice





No Work NeededReference ExternallyWork NeedOut of ScopeNot a Policy