In order to protect its assets, services providers, infrastructures, and collaboration alike needs to be able to authenticate, identify, and trace users granted access to their services. The authentication and identification must be sufficient to meet their requirements and match their risk appetite, legal and contractual obligations, and those of their suppliers. Collaborations in particular play a central role in the AARC Blueprint, since they bridge the user and infrastructure domains, and their components are often 'opaque' by translating both security mechanisms and policy domains.
Not having sufficient assurance about users may appear 'simpler' at first, but may be a long-term liability, as service providers and infrastructures need to protect themselves from harm in case of security incidents and then will suspend or terminate service to the collaboration. Infrastructures and service providers will more readily define acceptable assurance levels in order to meet their information security management system and risk assessment. Similarly, data providers, especially those providing access to sensitive data, will have specific policies in place to know exactly to whom they are providing access - patient records and the binding of permits for data access from the HDABs come to mind. Collaborations that access services must have assurance requirements in place as well, and these must meet or exceed those of their connected relying parties!
If, as a collaboration, you are using a shared AAI services platform, your AAI provider may have already put in place minimum assurance requirements and may offer 'standard' templates for step-up assurance, both for the authenticator (multi-factor) as well as for identity vetting (photo-ID, validation of data in authoritative databases, etc.). Ask your service provider about both minimum and optional assurance features: they could either be too high or too low for your collaboration use cases.
Express the collaboration and infrastructure requirements for identity vetting, freshness of affiliation, and 'uniqueness' of the identifiers you need, in terms of the REFEDS Assurance Framework (RAF) components. By doing so, as a collaboration you can leverage the collective effort to express assurance across many identity sources and peer collaborations - saving a lot of bi-lateral negotiations.
There are two 'collapsed' assurance levels, defined to be the most useful combinations for federated and collaborative use cases:
but you can also inspect the assurance components: ID, IAL, and ATP. If attribute freshness of one-day-or-better is required, inspection of ATP is necessary since none of the collapsed assurance level specifically requires this quality.