Increasingly Research Infrastructures and generic e-Infrastructures compose an 'effective' assurance profile derived from several sources. The assurance elements may come from an institutional identity provider (IdP), from community-provided information sources, from step-up authentication services, and from controls placed upon the user, the community, or the Infrastructure Proxy through either policy or technical enforcement. Knowledge about the upstream source of either identity or authenticator can also influence the risk perception of the Infrastructure and result in a modification of the assurance level, e.g. because it has involved a social identity provider or perhaps a government e-ID. The granularity of this composite assurance profile is attuned to the risk assessment specific to the Infrastructure or Infrastructures, and is often both more fine-grained and more specific than what can reasonably be expressed by generic IdPs or consumed by generic service providers.
Yet it is desirable to exchange as complete as possible the assurance assertion obtained between Infrastructures, so that assurance elements need not be re-asserted or re-computed by a recipient Infrastructure or Infrastructure service provider.
This document describes the assurance profiles that are recommended to be used by the e-Infrastructures and research infrastructures AAI platforms to exchange user authentication information between infrastructures.
This document is now in final public comment
Assigned DOI: https://doi.org/10.5281/zenodo.1173558 (this one was a bit challenging as we do not have a formal author list - too many undefined contribuants from AARC and AppInt)
Adopted license: CC-BY-4.0
Recasted document with specific scoping, rationale - and tightening the association with the REFEDS RAF framework - is now available:
public-commentable versions:
And a snapshot of the REFEDS RAF document (2018-02-15) for reference.
| Q | Addressed by |
|---|---|
| References to other (potentially future) guidelines | add to each of the guideline documents: "This Guidelines should be used and interpreted in the context of the AARC Blueprint Architecture (https://aarc-project.eu/architecture/) and the AARC Policy recommendations (https://aarc-project.eu/policies/)." so that we don't have to re-iterate the references every time? |
On the subject of Darjeeling, if we are asserting both Espresso and MFA, then you would assert Darjeeling, Espresso (as per the "superset" rule), *and* MFA *and* components (as per the components rule), so this kind of suggests Darjeeling is mostly redundant even if some infrastructure had a use case for it. | Dropped as by rough consensus |
if you have, say, BIRCH plus MFA, then you can't assert BIRCH? ... because the BIRCH profile says SFA, so your values are no longer a superset. This actually links to a long-standing discussion in the REFEDS RAF WG, which concluded that - however strange it may seem - SFA is not a subset of MFA. | In the MFA profile it puts nowhere any quality requirements on any of the factors. It is unlikely that thsi will change, since MFA has been recently adopted by REFEDS and they do not want to change it. As a result, we conclude here that we need some additional specs on the MFA to make this happen. Under implementation notes in the document there is now a specific paragraph addressing this: |
| Auditability and tracability of decisions in the proxy, or the business logic inside the proxy should be considered | Although very true, this is out of scope of this specific guideline document. |
Mailing list discussion only