What is RAF

To manage risk in federated access, Relying Parties (RPs) sometimes need more confidence in the identity- and attribute-related assertions made by an Identity Provider (IdP) and its underlying Credential Service Provider (CSP). The REFEDS Assurance Framework (RAF) defines a pragmatic way to express this confidence in commonly-used federation protocols, so that RPs (or proxies) can make more informed access-control decisions and CSPs/IdPs can communicate what they actually do.

RAF focuses on identity and attribute assurance (e.g., uniqueness, identity proofing, attribute quality/freshness).  
It does not define authentication strength; for that, use the REFEDS authentication profiles (SFA/MFA) alongside RAF.

RAF 2.0 components and profiles

RAF 2.0 splits assurance into independent components:

  • Identifier Uniqueness
  • Identity Assurance
  • Attribute Assurance

To simplify consumption by RPs, RAF 2.0 also defines two assurance profiles (bundles of component requirements):

  • RAF Cappuccino (moderate use cases)
  • RAF Espresso (higher-risk use cases)

In RAF cappuccino: a unique identifier, medium-level identity assurance, and the 'affiliation' attribute reflects the status no longer than one month in arrears. This level can be combined with single-factor authenticator strength (http://refeds.org/sfa)
In RAF Espresso: there is a unique identifier, high-level identity assurance, and the 'affiliation' attribute reflects the status no longer than one month in arrears. This level is best combined with multi-factor authenticators (http://refeds.org/mfa).

Who should adopt RAF and why?

Identity Providers / Credential Service Providers (CSPs)

  • To clearly communicate how user identities are established and managed (enrolment, proofing, lifecycle).
  • To enable downstream RPs to apply risk-based access control using consistent, community-defined signals.

Federations and federation operators

  • To provide a common “assurance vocabulary” that scales across many IdPs and RPs.
  • To support consistent interpretation and smoother inter-federation interoperability.

Service Providers / Relying Parties (RPs)

  • To request and interpret assurance information in a structured way, aligned to real risk and policy requirements.
  • To avoid bilateral “questionnaires” and bespoke assurance mappings wherever possible.

Related work in AARC / trust-policy building blocks

If you are building an end-to-end trust posture for a collaboration/infrastructure, RAF is part on resolving the the Assurance Requirements

Resources

  • No labels