mfa – REFEDS

REFEDS MFA Profile

A shared trust signal,
Service asks for stronger proof,
Login is secure.

1. Introduction

This section is informative.

The REFEDS Multi-Factor Authentication (MFA) Profile (referred to subsequently as “Profile”) defines standard signals that allow service providers (SPs) to request multi-factor authentication (MFA) from identity providers (IdPs), and for IdPs to indicate that MFA has successfully occurred in a federated authentication transaction.

In this document, the term “Identity Provider/IdP” is used to refer to both SAML Identity Providers (IdPs), OpenID Providers (OPs), and equivalent components interchangeably. The term “Service Provider/SP” is used to refer to both SAML Service Providers (SPs), OpenID Relying Parties (RPs), and equivalent components interchangeably.

1.1 Intended Audience

The Profile is intended for operators and integrators of federated identity services, particularly in the Research and Education community. It will be most useful to administrators of Identity Providers (IdPs), Service Providers (SPs), and federation operators who need a common way to signal MFA.

The document assumes a general working knowledge of how SAML 2.0 and/or OpenID Connect (OIDC) are used in federated single sign-on. Some familiarity with authentication events, assurance levels, and attribute release will be helpful, as will awareness of related REFEDS profiles and entity categories. Because this Profile is motivated by the need to mitigate real-world attacks, readers will also benefit from a basic understanding of cybersecurity threat models and how MFA addresses (and does not address) specific risks.

1.2 Why this Profile is Needed

In federated single sign-on, a Service Provider (SP) depends on a remote Identity Provider (IdP) to authenticate users. Without a standard way to signal MFA requirements, interoperability suffers: SPs cannot reliably request MFA, and IdPs cannot clearly assert that MFA was performed. This Profile addresses that problem by specifying common identifiers and normative requirements for MFA signalling across protocols.

1.3 What this Profile Provides

This Profile:

Defines the requirements an authentication event must satisfy to be considered MFA.
Defines an additional, higher authentication strength, Phishing-Resistant MFA, that protects against adversary-in-the-middle and related phishing attacks.
Provides protocol bindings for SAML 2.0 and OpenID Connect to request and assert MFA.
Describes how to communicate the time of authentication and interpret forced re-authentication in the context of MFA.

While this Profile defines explicit characteristics of authentication methods, it does not mandate particular technologies. Instead, it establishes interoperable signalling semantics and minimum expectations that enable consistent adoption across the international research and education (R&E) identity community.

1.4 Threat Mitigation Scope

General MFA, as defined in this Profile (referred to simply as MFA in previous versions), mitigates many common credential threats, including:

Use of stolen or guessed passwords.
Large-scale credential stuffing or password spraying.
Basic phishing that captures only a password.

However, stronger protection is required against:

Adversary-in-the-middle (AiTM) attacks that proxy authentication flows.
Social engineering attacks such as “push fatigue”.
Interception of SMS codes or one-time passcodes.

This Profile introduces Phishing-Resistant MFA to address these threats.

Phishing-resistant authentication makes it essentially infeasible for a remote attacker to gain sufficient information to successfully authenticate as the user (for example, by deceiving the user into taking an action that causes authentication secrets to be revealed).

Phishing-resistant authentication does not necessarily mitigate all attacks. It does not address, for example, malware-based credential theft, device compromise, insider misuse of stolen authenticators or advanced adversary-in-the-middle attacks such as SSO session hijacking.

1.5 Scope and Limitations

This Profile defines event-scoped signalling for General MFA and Phishing-Resistant MFA and how to request and assert those signals in commonly used Federation Protocols. It also offers guidance for interpreting the signals (time-of-authentication, forced re-authentication, and basic error handling).

This Profile does not address other assurance topics, such as identity proofing, registration, or endpoint/device management, which may be addressed in other REFEDS profiles [REFEDS]. It does, however, specify requirements for the enrolment, recovery, and replacement of authentication factors to ensure factor independence.

1.5.1 Avoid this Profile for Internal Signalling

When using this Profile, one must strictly adhere to the semantics described in Sections 3 and 4. This Profile is specifically designed for a service provider and an identity provider to signal multi-factor authentication behaviour in an inter-organisational single sign-on transaction.

Using any of the values defined in this Profile to signal compliance with an organisation’s internal policies is not appropriate. Even if the organisation’s internal MFA policy aligns with the requirements of this Profile today, organisational policy could evolve over time and become incompatible with the requirements of this Profile. Conflating MFA signalling governed by local policies with federated MFA signalling will likely impede an organisation’s ability to conform to this Profile over time.

It is suggested to use an organisational-specific value for local purposes.

1.6 Relationship to Earlier Versions of This Profile

Version 2.0 of the REFEDS MFA Profile:

Is backward compatible with the definition of MFA from REFEDS MFA Profile Version 1.2, now referred to as General MFA.
Adds a normative definition of Phishing-Resistant MFA.
Consolidates the normative SAML and OpenID material from Version 1.2 to reduce duplication, while retaining the explicit rules for their use. The guidance itself includes clarifications, but no normative changes apart from the introduction of a second identifier for Phishing-Resistant MFA.
Clarifies profile conformance requirements.
Adds examples of using Phishing-Resistant MFA in SAML and OIDC and moves all the examples to an Appendix for better readability.

This Profile supersedes all earlier versions of the REFEDS MFA Profile. All earlier versions of this Profile are considered obsolete. Note that this version does not deprecate General MFA (referred to simply as MFA in previous versions) in any way.

2. Terms and Definitions

This section is informative.

Term	Definition
Browser Cookie	An HTTP cookie whose presentation by a user agent is considered valid without additional cryptographic proof.
Federated Login	An authentication exchange in which the identity provider and service provider belong to different organisations or administrative domains.
Identity Provider (IdP/OP)	A party in a federated login exchange that authenticates the user and asserts information about the user and the authentication event. In OIDC, this component is synonymous with OpenID Provider (OP).
Service Provider (SP/RP)	A party in a federated login exchange that requests authentication of a user by an identity provider and receives an assertion or token vouching for the authentication. In OIDC, this component is synonymous with Relying Party (RP) or Client.
Trusted Verifier	During an authentication event, a trusted verifier is the identity provider that the user intends to authenticate with and is responsible for verifying their identity.

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

2.1 Revision History

Version 2.0 of the REFEDS MFA Profile supersedes all prior versions. Earlier versions are considered obsolete; implementers are expected to adopt this version for REFEDS MFA signalling, which includes signalling of both General MFA and Phishing-Resistant MFA.

Version	Release date	Description
V1.0	07 June, 2017	Initial version
V1.2	15 November, 2023	More in-depth requirements and technical bindings in SAML and OIDC
V2.0	10 June, 2026	Definition and additional signalling for Phishing-Resistant MFA

3. Multi-Factor Authentication (MFA) Definitions

This section is normative unless noted otherwise.

Multi-factor authentication refers to the use of multiple, discrete factors included as part of login, typically but not always including “something you know” (e.g., a password) as one of the factors. This general description isn’t enough to clearly communicate secure, interoperable requirements; therefore we define the following.

3.1 Multiple Factors

The authentication of the user’s current session MUST use a combination of at least two of the four distinct types of factors:

Something the user has (e.g., hardware device containing a credential).
Something the user knows (e.g., password).
Something the user is (e.g., biometric).
Something the user does (e.g., behavioural).

3.2 Factor Independence

Initial enrolment of one or more additional factors MAY take place subject to authentication by only a single factor. Subsequently, the factors used MUST be independent; this includes processes to recover, replace, or add authentication factors.

The combination of the factors MUST mitigate risks related to compromise of any (single) factor.

Guidance: Independence means that access to one factor does not by itself grant access to or allow the replacement of the other factor. For example, possession of a Single-Factor device by itself cannot be used to reset a “first factor” password if independence is to be maintained. Another precluded example is where the user’s “first factor” password grants access to a virtual telecom device that receives SMS OTPs acting as the “second factor”, allowing registration of additional devices without MFA.

3.3 Freshness of Authentication

Because MFA consists of two or more independently confirmed factors, it is important to accurately communicate a well-defined notion of “freshness of authentication” to relying parties. See Section 4.2.4 for normative requirements for this purpose.

3.4 General MFA

If the requirements of Sections 3.1, 3.2, and 3.3 are met, the authentication event qualifies as General MFA.

3.5 Phishing-Resistant MFA

A phishing-resistant authentication factor:

MUST ensure that only the legitimate user, interacting directly with their intended Trusted Verifier, can complete authentication, even if an attacker attempts to redirect the user to a spoofed verifier.
MUST NOT rely on shared secrets or valid authenticator outputs (e.g., passwords, one-time codes, or challenges) sent during the authentication process that a remote attacker could capture, replay, or instruct the user to reveal.

If the requirements of Sections 3.1, 3.2, and 3.3 are met and at least one factor from Section 3.1 is a phishing-resistant authentication factor, the authentication event qualifies as Phishing-Resistant MFA.

4. Authentication Signalling Requirements

This section is normative.

This Section defines the runtime signalling semantics for General MFA (MFA) and Phishing-Resistant MFA (PHR). These requirements apply to all conformant Identity Providers (IdPs/OPs) and Service Providers (SPs/RPs).

4.1 Profile Identifiers

When using the REFEDS MFA Profile to signal authentication strength requirements or results, the following identifiers are used.

To signal General MFA:

Identifier: https://refeds.org/profile/mfa

This identifier represents authentication performed in accordance with Section 3.4.

To signal Phishing-Resistant MFA:

Identifier: https://refeds.org/profile/mfa/phr

This identifier represents authentication performed in accordance with Section 3.5.

4.2 Protocol-Agnostic Runtime Requirements

4.2.1 SP/RP Request Requirements

An SP/RP conforming to this Profile SHOULD explicitly request exactly one of General MFA or Phishing-Resistant MFA and no other authentication context values.

If the SP/RP is satisfied with either General MFA or Phishing-Resistant MFA, it SHOULD ask for General MFA. If Phishing-Resistant MFA is needed later, then it SHOULD explicitly request Phishing-Resistant MFA via a subsequent authentication request.

4.2.2 IdP/OP Response Requirements

The following normative rules govern the authentication strength identifier asserted by an IdP/OP.

4.2.2.1 If the SP/RP requests General MFA, then:

If the IdP/OP performs General MFA, it MUST assert https://refeds.org/profile/mfa
If the IdP/OP performs Phishing-Resistant MFA, it MUST only assert
https://refeds.org/profile/mfa
Otherwise, if it is reasonably possible to return a signal to the SP/RP, the IdP/OP instead MUST return a protocol-appropriate error indicating the request could not be fulfilled

4.2.2.2 If the SP/RP requests Phishing-Resistant MFA, then:

If the IdP/OP performs Phishing-Resistant MFA, it MUST assert
https://refeds.org/profile/mfa/phr
Otherwise, if it is reasonably possible to return a signal to the SP/RP, the IdP/OP instead MUST return a protocol-appropriate error indicating the request could not be fulfilled

4.2.2.3 An IdP MUST NOT assert any of these identifiers when a bypass or omission of one or more factors occurs (e.g., “fail open” for local service reliability).

4.2.3 Step-Up and Session Reuse Requirements

4.2.3.1 If the SP/RP requests Phishing-Resistant MFA and the IdP/OP has an existing session that does not satisfy Phishing-Resistant MFA, the IdP/OP MUST perform additional authentication sufficient to satisfy Phishing-Resistant MFA requirements according to Section 4.2.2.2.

4.2.3.2 If the SP/RP requests General MFA and the IdP/OP has an existing session that satisfies either General MFA or Phishing-Resistant MFA, and the SP/RP does not request a protocol-specific forced authentication, the IdP/OP MAY reuse the session as is, returning the General MFA signal in its response, subject to the authentication time signalling requirements in Section 4.2.4.

4.2.4 Authentication Time Requirements

This Profile does not impose elapsed-time constraints (i.e., authentication age) between the time of an SP’s authentication request and the actual authentication time of any of the authentication factors used in the assertion.

To support SPs making policy decisions based on authentication freshness, an IdP SHOULD set a protocol-specific field indicating the time of authentication to the earliest time within an SSO session that a user first successfully completed an authentication step that required user interaction.

Note that this disqualifies setting the time of authentication based only on the presence of a browser cookie as a challenge bypass mechanism (e.g., “Remember me”). When configuring software to support this Profile, a deployer SHOULD prevent such features from influencing the authentication time value.

The following protocol-agnostic rules apply when asserting General MFA or Phishing-Resistant MFA:

4.2.4.1 If an IdP/OP asserts General MFA or Phishing-Resistant MFA, it MUST also set the protocol-specific “time of authentication” value (e.g., AuthnInstant in SAML, auth_time in OIDC).

4.2.4.2 The authentication time SHOULD represent the earliest time during the current session at which the user satisfied any required factor involving user interaction.

4.2.4.3 Any factor contributing to that timestamp SHOULD require interaction by the user (e.g., entering a password, approving a push, touching a security key).

4.2.4.4 The IdP/OP SHOULD NOT reset or advance the “time of authentication” solely based on passive session reuse (e.g., presence of a cookie, “Remember me” features).

4.2.5 Forced Authentication

Upon receiving a protocol-specific authentication request asking for forced authentication of a user, an IdP SHOULD immediately authenticate the user using all required authentication factors, each requiring user interaction.

4.2.6 Error Handling

If an IdP/OP cannot satisfy the requested authentication strength, it SHOULD return an error response rather than leaving the user stranded.

Any error MUST follow the conventions of the underlying protocol (e.g., SAML <StatusCode>, OIDC error response), and SHOULD clearly indicate that the requested authentication strength could not be satisfied.

4.3 SAML 2.0 Protocol Binding

This section is normative and applies to SAML 2.0 implementations.

In SAML 2.0, authentication requirements and results are expressed using Authentication Context as defined in [SAMLAuthnContext] and [SAMLCore]. One of the values defined in Section 4.1 MUST be used as Authentication Context Class Reference (<saml:AuthnContextClassRef>) in SAML requests and in SAML assertions to signal the required or achieved authentication strength.

The Comparison XML attribute in the <RequestedAuthnContext> element SHOULD be set to exact when using this Profile.

Guidance: Using other Comparison values will often result in unpredictable behaviour or failures.

Authentication time, as discussed in Section 4.2.4, is signalled by means of the AuthnInstant attribute in an <AuthnStatement> element.

Forced authentication, as discussed in Section 4.2.5, is signalled by means of the ForceAuthn attribute in an <AuthnRequest> element.

IdPs and SPs are encouraged to use the SAML V2.0 Metadata Deployment Profile for errorURL [ErrorURL] to facilitate a better user experience.

When signalling a failure to understand or satisfy a request for context classes defined in this Profile, the error response MUST contain the second-level <StatusCode> value of urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext per [SAMLCore].

4.4 OpenID Connect 1.0 Binding

This section is normative and applies to OpenID Connect implementations.

In OpenID Connect, authentication requirements and results are expressed using the acr and amr claims. The acr claim is used to communicate this more abstractly and is used by this Profile. Use of the amr claim is outside the scope of this Profile.

One of the values defined in Section 4.1 MUST be used as the acr claim value in requests and responses to signal the required or achieved authentication strength.

The OpenID specification defines two mechanisms for issuing requests for a specific acr claim:

The acr_values parameter (Section 3.1.2.1 of [OIDC])
The claims parameter, a JSON structure (Section 5.5 of [OIDC])

The former has explicitly “optional” semantics such that an OP is allowed to ignore it, and the latter is optional for an OP to implement. Using both together results in unspecified behaviour.

To achieve interoperability, an OP supporting this Profile MUST support the claims parameter request feature in conjunction with an RP requesting the acr claim with the essential flag set to true. Examples of this can be found in Appendix A.

Authentication time, as discussed in Section 4.2.4, is signalled by means of the auth_time claim.

Forced authentication, as discussed in Section 4.2.5, is signalled by means of the prompt and/or max_age request parameters (Section 3.1.2.1 of [OIDC]). Note that the latter in particular provides more fine-grained control than the equivalent SAML feature.

When signalling a failure to understand or satisfy a request for any acr claim value defined in this Profile, the error response MUST contain the unmet_authentication_requirements status value with an error_description as applicable to the situation.

5. References

[REFEDS] Listing of REFEDS Specifications and Profiles; https://refeds.org/specifications.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, https://datatracker.ietf.org/doc/rfc2119/

[SAMLAuthnContext] Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0, https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

[SAMLCore] Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

[OIDC] OpenID Connect Core 1.0. November 2014. https://openid.net/specs/openid-connect-core-1_0.html

[ErrorURL] REFEDS SAML V2.0 Metadata Deployment Profile for errorURL Version 1.0, https://refeds.org/specifications/errorurl-v1

Appendix A. Protocol Examples

This section is informative.

This appendix provides realistic (though partial) examples of how Service Providers (SPs/RPs) and Identity Providers (IdPs/OPs) can realise the signalling patterns defined in Section 4 using SAML 2.0 and OpenID Connect. The examples assume both parties are operating as directed by this Profile.

The examples are meant to illustrate typical message structures and expected outcomes, not to prescribe vendor-specific syntax, and are heavily elided (e.g. XML namespaces removed) for clarity, and so are not complete, compliant examples.

For all examples:

https://refeds.org/profile/mfa = General MFA
https://refeds.org/profile/mfa/phr = Phishing-Resistant MFA

Other values, such as urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, are used illustratively to represent single-factor baseline authentication.

A.1 SAML 2.0 Examples

A.1.1 SP Has No Authentication Policy Requirement

Request example (note the absence of a <RequestedAuthnContext> element):

Response examples (heavily elided):

If the IdP performed General MFA

<samlp:Response> <saml:Assertion> <saml:AuthnStatement> <saml:AuthnContext> <saml:AuthnContextClassRef> https://refeds.org/profile/mfa </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

If the IdP performed Phishing-Resistant MFA:

<samlp:Response> <saml:Assertion> <saml:AuthnStatement> <saml:AuthnContext> <saml:AuthnContextClassRef> https://refeds.org/profile/mfa/phr </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

Otherwise, a different AuthnContext Class identifier would appear at the discretion of the IdP.

A.1.2 SP Requires General MFA

This example encompasses at least two cases:

An SP without a session asks that General MFA be performed.
An SP with a more weakly-authenticated session requests a “step-up” to General MFA by issuing a subsequent request.

Request example:

<samlp:AuthnRequest
ID=”_example1″
Version=”2.0″
IssueInstant=”2025-10-22T17:00:00Z”
AssertionConsumerServiceURL=”https://sp.example.org/acs”
Destination=”https://idp.example.org/sso”>
<samlp:RequestedAuthnContext Comparison=”exact”>
<saml:AuthnContextClassRef>
https://refeds.org/profile/mfa
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Response examples (heavily elided):

If the IdP performed General MFA or Phishing-Resistant MFA (the context returned must match the one requested if the actions of the IdP were compatible):

<samlp:Response>
<saml:Assertion>
<saml:AuthnStatement>
<saml:AuthnContext>
<saml:AuthnContextClassRef>
https://refeds.org/profile/mfa
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>

If the IdP could not perform either form of MFA, an error is signalled:

<samlp:Response>
<samlp:Status>
<samlp:StatusCode
Value=”urn:oasis:names:tc:SAML:2.0:status:Responder”>
<samlp:StatusCode
Value=”urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext”/>
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>

A.1.3 SP Requires Phishing-Resistant MFA

This example encompasses at least two cases:

An SP without a session asks that Phishing-Resistant MFA be performed.
An SP with a more weakly-authenticated session (including one via General MFA) requests a “step-up” to Phishing-Resistant MFA by issuing a subsequent request.

Request example:

<samlp:AuthnRequest
ID=”_example1″
Version=”2.0″
IssueInstant=”2025-10-22T17:00:00Z”
AssertionConsumerServiceURL=”https://sp.example.org/acs”
Destination=”https://idp.example.org/sso”>
<samlp:RequestedAuthnContext Comparison=”exact”>
<saml:AuthnContextClassRef>
https://refeds.org/profile/mfa/phr
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Response examples (heavily elided):

If the IdP performed Phishing-Resistant MFA (the context returned must match the one requested if the actions of the IdP were compatible):

<samlp:Response>
<saml:Assertion>
<saml:AuthnStatement>
<saml:AuthnContext>
<saml:AuthnContextClassRef>
https://refeds.org/profile/mfa/phr
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>

If the IdP could not perform Phishing-Resistant MFA, an error is signalled (even if the user was authenticated using General MFA):

A.2 OpenID Connect 1.0 Examples

A.2.1 RP Has No Authentication Policy Requirement

Request example (note the absence of a claims request parameter, either alone or in a request object):

Host: op.example.org
GET /authorize?
client_id=rp.example.org&
response_type=code&
scope=openid&
redirect_uri=https://rp.example.org/cb&
state=xyz

The ID token returned may or may not contain an acr claim of:

https://refeds.org/profile/mfa If the OP performed General MFA
https://refeds.org/profile/mfa/phr If the OP performed Phishing-Resistant MFA
Any other value as chosen by the OP in any other case

A.2.2 RP Requires General MFA

This example encompasses at least two cases:

An RP without a session asks that General MFA be performed.
An RP with a more weakly-authenticated session requests a “step-up” to General MFA by issuing a subsequent request.

Request example using a claims parameter:

Host: op.example.org
GET /authorize?
client_id=rp.example.org&
response_type=code&
scope=openid&
redirect_uri=https://rp.example.org/cb&
state=xyz&
claims=<form-urlencoded JSON>

(the URL-decoded claims parameter):

{
“claims”:
{
“id_token”:
{
“acr”:
{
“essential”: true,
“values”: [“https://refeds.org/profile/mfa”] }
}
}
}

Alternatively, the RP may issue a JWT request object:

{
“iss”: “s6BhdRkqt3”,
“aud”: “https://op.example.org”,
“response_type”: “code”,
“client_id”: “s6BhdRkqt3”,
“redirect_uri”: “https://rp.example.org/cb”,
“scope”: “openid”,
“state”: “xyz”,
“nonce”: “n-0S6_WzA2Mj”,
“claims”:
{
“id_token”:
{
“acr”:
{
“essential”: true,
“values”: [“https://refeds.org/profile/mfa”]}
}
}
}

If the OP performed General or Phishing-Resistant MFA (the acr claim returned must match the one requested if the actions of the OP were compatible), an ID token returned might be as follows:

{

“iss”: “https://op.example.org”,

“sub”: “24400320”,

“aud”: “s6BhdRkqt3”,

“nonce”: “n-0S6_WzA2Mj”,

“exp”: 1311281970,

“iat”: 1311280970,

“auth_time”: 1311280969,

“acr”: “https://refeds.org/profile/mfa”

}

If the OP could not perform either form of MFA, an error is signalled:

HTTP/1.1 302 Found

Location: https://rp.example.org/cb?

error=unmet_authentication_requirements

&error_description=User%20not%20enrolled

&state=xyz

A.2.3 RP Requires Phishing-Resistant MFA

This example encompasses at least two cases:

An RP without a session asks that Phishing-Resistant MFA be performed.
An RP with a more weakly-authenticated session requests a “step-up” to Phishing-Resistant MFA by issuing a subsequent request.

Request example using a claims parameter:

Host: op.example.org

GET /authorize?

client_id=rp.example.org&

response_type=code&

scope=openid&

redirect_uri=https://rp.example.org/cb&

state=xyz&

claims=<form-urlencoded JSON>

(the URL-decoded claims parameter):

{

“claims”:

{

“id_token”:

{

“acr”: {

“essential”: true,

“values”: [“https://refeds.org/profile/mfa/phr”]

}

Alternatively, the RP may issue a JWT request object:

{ "iss": "s6BhdRkqt3", "aud": "https://op.example.org", "response_type": "code", "client_id": "s6BhdRkqt3", "redirect_uri": "https://rp.example.org/cb", "scope": "openid", "state": "xyz", "nonce": "n-0S6_WzA2Mj", "claims": { "id_token": { "acr": { "essential": true, "values": ["https://refeds.org/profile/mfa/phr"] } } } }

If the OP performed Phishing-Resistant MFA (the acr claim returned must match the one requested if the actions of the OP were compatible), an ID token returned might be as follows:

{ "iss": "https://op.example.org", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "auth_time": 1311280969, "acr": "https://refeds.org/profile/mfa/phr" }

If the OP could not perform Phishing-Resistant MFA, an error is signalled (even if user was authenticated using General MFA):

HTTP/1.1 302 Found Location: https://rp.example.org/cb error=unmet_authentication_requirement &error_description=User%20not%20enrolled &state=xyz

Appendix B. Acknowledgements and List of Contributors

We thank the members of previous REFEDS MFA Profile Working Groups for their contributions to this Profile document. The participants of the REFEDS MFA Profile V2.0 Working Group continued with the development, writing, and review of this document. Their expertise and collaboration helped shape and improve this work. They are (in no particular order):

Alan Buxey, MyUNiDAYS Ltd.; https://orcid.org/0000-0001-8217-8379
Albert Wu, Internet2/InCommon Federation; https://orcid.org/0000-0001-7570-0923
Darren Fallis, North Carolina State University
David Walker, University of California (retired); https://orcid.org/0000-0003-2540-0644
Fredrik Domeij (co-chair), Sunet/Swamid; https://orcid.org/0000-0002-7579-5771
Gabor Eszes (co-chair), UNC Greensboro; https://orcid.org/0000-0001-7727-2854
Mark Rank, Cirrus Identity Inc.; https://orcid.org/0000-0001-8930-9247
Phil Smart, Jisc; https://orcid.org/0009-0000-3358-213X
Scott Cantor, Resting Parrot Software, LLC, formerly of The Ohio State University
Shannon Roddy, LBNL; https://orcid.org/0000-0002-5151-7400

Version History	V.2 Published 10 June 2026 (current)
Reference pdf
DOI
License	This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Supporting Material	https://wiki.refeds.org/display/PRO/MFA