Versions Compared

Old Version 21

changes.mady.by.user Mikael Linden

Saved on

compared with

New Version Current

changes.mady.by.user David Groep

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In a federated AAI, the user’s Home Organisation issuing and managing user’s credentials determines the assurance level available for the user identity. For the risk management of the research services relying on the federated AAI, it is important to determine the assurance profile available for the authenticated users. What the relevant assurance profile is obviously very much depends on the risk associated with offering the service, the availability of resource to provide identity and attribute assurance, and a mechanism to convey defined assurance information. Whilst most of these elements are beyond the direct control of AARC, the baseline and differentiates assurance profiles developed through AARC - in close collaboration with the user communites, research and e-infrastructures, and with consultation from federation and IdP operators via the GEANT4 project - help establish common ground by which to exchange policy information

Exchange of assurance information between Infrastructures

In support of the inter-infrastructure use cases and the BPA, Guideline G021 on the exchange of specific assurance information has been adopted by AEGIS. These guidelines SHOULD be used when exchanging assurance information between SP-IdP-Proxy components of Infrastructures (“Infrastructure Proxies”), and MAY be used when conveying assurance information between an SP-IdP-Proxy and service providers that are part of a coordinated set or consortium and bound to one or more Infrastructure Proxies.

If the exchange involves authentications involving user-held credentials based on social media accounts (like Google, LinkedIn, Facebook, &c), also take Guideline G041 into account, which describes bow REFEDS RAF assurance components should be expressed by the BPA Proxies and how these may be combined on 'outbound' assertions.

Differentiated LoA recommendations

The consolidated and formatted version of our work DNA3.1 is now available:

  • Deliverable DNA3.1 (Differentiated Assurance), revision 1.1: in PDF and MS Word formats

The baseline assurance profile, comprising the six key elements needed for almost all research and collaborative use cases, have been available since 2016:

  • Baseline assurance for low-risk research use cases (MNA3.1): in PDF format

In public comment

The REFEDS Assurance Framework discusses the components of assurance (for IdPs) and how to group these together in ways that make sense to (groups of) SPs:

Public Consulations (Completed)

  • Baseline LoA (MNA3.1) (pdf), submitted to EC and exposed to the community consultation
  • public comments period 1 December 2015-17th Jan 2016. Comments received (pdf).

Working papers

  • Survey for SPs on LoA needs
  • Communities
    • (RomainW) scheduled 28 OctPeterG postponed until Nov
  • Libraries (Melanie?)
  • find some more RIs from FIM4R community
  • Initial findings
    • baseline: personal accounts, persistent IDs and password-based authentication?
    • Self-assertion of LoA is good enough if supported by specific enough requirements (and perhaps a tool that helps to do the self-audit)
    • What role IGTF could play in audits and a step-up authentication service, they have been in the LoA business for some time? 
    • LIGO - Scott Koranda and Warren Anderson (Google doc)
  • Summary of interviews (Google doc)

Meetings