...
| 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 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!
| Scroll ImageMap | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...