Guideline on the exchange of specific assurance information between Infrastructures

Summary

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.

Links

Working docs

New strawman document is out now, adding specific scoping, rationale, and tightening the association with the RAF:

• latest consolidated snapshot (PDF)

public-commentable (and editable) versions:

• https://docs.google.com/document/d/1Fi07J9lpUbqYTlPMINkbHl7xvA5tJ98L4jai6XNKbDM

Specific Open Questions

• the 'attribute freshness' (ePA-1m) as coming out of an Infrastructure Proxy is now normatively defined in this document as
  "The ATP assurance component (attribute freshness) SHALL reflect the affiliation of the identity with the CSP, i.e. the Infrastructure Proxy."
  It's the interpretation that makes most sense in case the resulting assertions from the proxy would (acidentally or on purpose) be re-inserted in eduGAIN, and also it better reflects the fact that for linked and composite identities the change of affiliation in an upstream IdP does not necessarily reflect any change in the Infrastructure. The Community is always authoritative ...
  IF this has already been stated in another JRA*.* document, please put the ref here
• the "Darjeeling" profile is very, very close to Espresso, the only thing it adds is that it adds to MFA support also a quality requirement on the first factor. Is that profile really useful? Could we drop it (please)?
• On output, if the combination of assurance component values meets a REFEDS RAF profile, you must now also assert the REFEDS RAF profile values - so that if the assertion 'escapes', it still makes sense to generic service providers
• The flagging of 'social identity providers' was considered quite important, so Assam does that for you. However, if the identity provider is a homeless IdP with known qualities, you SHOULD also assert those properties if you know about them (like IAP/low and maybe even SFA).

Final PDF

To be published

Meetings schedule and Minutes