Additional Authentication Method Reference Values

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 May 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The JWT [RFC7519] "amr" (Authentication Methods References) claim [OpenID.Core] contains values conveying authentication methods used in the authentication. They are registered in the IANA "Authentication Method Reference Values" registry [IANA.AMR].¶

Since the Authentication Method Reference Values [RFC8176] specification was published, several new authentication methods have been developed and/or come into widespread use. This specification defines additional Authentication Method Reference values to represent these additional authentication methods in use today.¶

While these Authentication Method Reference values are general purpose and can be used in any JSON Web Token (JWT) [RFC7519], one use case for them is use in KYAPay tokens [I-D.skyfire-oauth-kyapay-token].¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Authentication Method Reference Values

The following Authentication Method Reference values are defined by this specification:¶

4. Updated Authentication Method Reference Value

The following Authentication Method Reference value is updated by this specification:¶

5. Composing Authentication Method Reference Values

The "amr" claim value is an array, and as described in [RFC8176], all the applicable values may be returned. A single authentication event is frequently described by more than one value, because the registered values describe different aspects of it.¶

The "email" and "push" values registered by this specification describe the channel by which an authentication interaction reached the person. [RFC8176] registers "sms" and "tel" in the same sense, and uses the term "channel" in this sense in its definition of "mca".¶

The "code" and "url" values describe challenges delivered over such a channel, which the person must return to the verifier to complete authentication. The person may return it directly, as when a code is read and typed in, or indirectly, as when following a link causes the value to be sent. The "otp" value [RFC8176] is related but narrower: it identifies a one-time password produced by an algorithm such as HOTP [RFC4226] or TOTP [RFC6238], typically generated by an authenticator rather than delivered over a channel. A code not produced by such an algorithm is described by "code".¶

A channel value alone does not say what the person did. A challenge value alone does not say how it reached them. An issuer that knows both will typically return both. Appendix A gives examples, and Appendix B maps terms in common industry use onto the corresponding sets of values.¶

The "sms" value registered by [RFC8176] predates this distinction. Its definition describes both a channel and the interaction carried over it, and is unchanged by this specification. An issuer wishing to be explicit about what was delivered over the SMS channel may return a challenge value alongside it.¶

6. Security Considerations

The security considerations defined in Authentication Method Reference Values [RFC8176] apply to this specification.¶

E-mail is not an acceptable channel for out-of-band authentication under Section 3.1.3.1 of [NIST.SP.800-63B-4], because an e-mail account may be accessible with only a password and messages may be intercepted or rerouted. A relying party evaluating an "amr" claim that includes "email" may wish to take this into account.¶

[NIST.SP.800-63B-4] also no longer accepts out-of-band authentication in which the user approves a request on the secondary channel without transferring a secret between the channels, because of authentication fatigue attacks. The "push" value alone does not indicate whether a secret was transferred. An issuer that knows a code was transferred returns "code" alongside it.¶

7. Privacy Considerations

The privacy considerations defined in Authentication Method Reference Values [RFC8176] apply to this specification.¶

8. IANA Considerations

9. References

Appendix A. Examples

The following "amr" claim value indicates that a code was sent to the user over the e-mail channel and entered by the user:¶

"amr": ["email", "code"]

The following "amr" claim value indicates that a link was sent to the user over the e-mail channel and followed by the user:¶

"amr": ["email", "url"]

The following "amr" claim value indicates that a one-time password was generated by an authenticator application and entered by the user:¶

"amr": ["app", "otp"]

The following "amr" claim value indicates that a password was used together with a code sent over the e-mail channel, and that the issuer considers the combination to be multiple-factor authentication:¶

"amr": ["pwd", "email", "code", "mfa"]

Appendix B. Common Compositions

The terms below are names in common industry use for authentication arrangements that this specification describes using more than one value. This mapping is non-normative. It is provided so that implementers of the same arrangement emit the same set of values.¶

Email one-time code, also called email OTP:

["email", "code"]¶

Magic link, also called e-mail link sign-in:

["email", "url"]¶

SMS one-time code:

["sms", "code"]. As noted in Section 5, "sms" predates the channel and challenge distinction, and ["sms"] remains correct.¶

Voice one-time code, where a call conveys a code that the user then enters:

["tel", "code"]¶

Call-back confirmation, where the user confirms during the call itself:

["tel"]¶

Authenticator application one-time password:

["app", "otp"]¶

Push approval:

["push"]¶

Push approval with number matching:

["push", "code"]¶

Silent network authentication:

["sna"]¶

Facial recognition with a liveness check:

["face", "facliv"]¶

Device-bound passkey held in hardware, such as on a security key:

["passkey", "hwk"]¶

Synced passkey:

["passkey", "mdc"]. "hwk" or "swk" is added where the issuer knows how the key is protected.¶

Acknowledgments

We would like to thank Jean Diaconu, Max Gerber, and Rob Zagarella for their contributions to the specification.¶

Document History

[[ to be removed by the RFC Editor before publication as an RFC ]]¶

-03¶

• Added "sna" for silent network authentication, a specific case of the background authentication described by "bg".¶

• Added "mdc" for multi-device credentials, commonly called synced passkeys, which composes with "hwk" and "swk" [RFC8176].¶

• Added "uv" for user verification, distinct from the user presence test described by "user" [RFC8176].¶

• Redefined "app" by the property it describes rather than by product examples, and stated when an issuer can assert it.¶

• Narrowed "email" to the channel, with what was delivered over it described by an accompanying value.¶

• Stated that "facliv" and "face" [RFC8176] describe different determinations and are included together where both were performed, and added a reference to [ISO30107-1].¶

• Added a reference for "passkey" to [WebAuthn].¶

• Added references to [NIST.SP.800-63B-4] for "app", "code", "push", and "email", and to [CAMARA.NumberVerification] for "sna".¶

• Added Security Considerations on e-mail as an authentication channel and on push approval without a transferred secret.¶

• Added a section on composing values, and appendices giving examples and common compositions.¶

• Removed "sqa". Current NIST guidance treats knowledge-based authentication and security questions as the same family, and "kba" [RFC8176] already covers it.¶

• Removed the Security Considerations note on security questions, which applied to "sqa".¶

• Added Max Gerber to the acknowledgments.¶

-02¶

• Updated the definition of "tel" to incorporate calls to provide information such as codes and removed "call".¶

• Renamed "psk" to "passkey" because of the potential confusion with pre-shared key.¶

• Added warning in Security Considerations that security questions are not acceptable authentication secrets under current NIST guidance.¶

• Added {:vspace} syntax to definition list entries.¶

-01¶

• Moved "inp" and "vid" methods to the ID Verification spec.¶

• Added "call", "code", "url", "facliv", "sqa", and "psk" methods.¶

• Added Nash Ali and Srinivasa Thumma as authors.¶

-00¶

• Initial draft.¶

Authors' Addresses