Page History

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.

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:
"If the authentication assurance component meets the REFEDS-MFA criteria and the CSP can determine that at least one of the factors also meets the good practice requirements for REFEDS-SFA..."