Assurance model for HDF#

Here we describe the different assurance levels available for HDF.

As a base for expressing assurance we will rely on the REFEDS Assurance Framework (RAF). Based on RAF, additional assurance profiles were also defined in AARC-G021.

In short, we promote the use of two or three assurance profiles:

  • AARC Assam: Users that logged in with a “social” identity, such as ORCID, Github, or Google.
  • IGTF Dogwood: Users that do have a home organisation that fulfils minimal security standards, such as permanently recording which user used which identifier.
  • RAF Cappuccino: Users had to be verified by checking the passport at the home institution. Note: This includes all students at DFN AAI Advanced, and will typically also include all employ>ees of DFN AAI Advanced IdPs.
  • RAF Espresso is very difficult to achieve, but may be developed for high-risk services in the future. For the user it means that his photo ID was successfully verified against a government database, and he uses multi-factor authentication for authentication.

The assurance will be conveyed to OIDC services using the eduperson_assurance claim.

Services should maintain a list of assurance-profiles that they want to support.

Assurance Profiles

Additional Information#

Additional information on the REFEDS Assurance Framework is collected here

Mapping attributes between SAML and OIDC is discussed in the => REFEDS OIDCre white paper especially Table 1.

The Proxy and the Assurance#

There are still IdPs that do not support the REFES Assurance Framework. For the time being we will use the HDF Proxy (i.e. unity) to assess the originating IdP and then assert a given assurance profile (using the eduperson_assurance claim).

  • Honoring the IdP: essentially, we “honor” the info coming from the IdP, i.e. if the IdP is releasing any of the assurance info, we present it as such to downstream services.

  • IdP “whitelisting”: For IdPs known to follow required procedures for expressing assurance components (e.g. have proper identity vetting), but do not express them via SAML assertions, we can (automatically) assert those claims downstream to SPs that consume this info. This may involve “translating” or “interpreting” certain attributes (e.g. value “staff” may translate to “medium”, while “student” do not, etc.)

  • PI (Principal Investigator) action: PI is responsible of the VO he manages. The PI can accept members that do not meet the assurance requirement, but they cannot access services with assurance requirements that exceed those the users has.

    • In HDF we are therefore working on a method that allows authorised personnel to raise individual components of a users’ assurance.
    • Please understand that this is quite complex and hence still under investigation. In case you have a demand for this, please contact the HDF AAI mailinglist.