]> Skyfire Systems Inc.

ankit_agarwal@yahoo.com https://skyfire.xyz

Self-Issued Consulting

michael_b_jones@hotmail.com https://self-issued.info/

Experian

nash.ali@experian.com

Akamai

sthumma@akamai.com

Security Web Authorization Protocol agent identity agentic payment commerce The JWT "amr" (Authentication Methods References) claim contains values conveying authentication methods used in the authentication. This specification defines additional Authentication Method Reference values beyond those already registered to represent additional authentication methods in use today. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The JWT "amr" (Authentication Methods References) claim contains values conveying authentication methods used in the authentication. They are registered in the IANA "Authentication Method Reference Values" registry . Since the Authentication Method Reference Values 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) , one use case for them is use in KYAPay tokens .

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 when, and only when, they appear in all capitals, as shown here.

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

"app" (Authenticator App) Method

app:

Use of an authenticator application on a device held by the user. An issuer includes this value where it knows that an authenticator application was used. Where a code is produced from a shared secret and the issuer cannot determine what produced it, this value is omitted. An authenticator application commonly acts as an OTP authenticator or as an out-of-band authenticator, as described in Sections 3.1.3 to 3.1.5 of .

"bg" (Background Authentication) Method

bg:

Background Authentication (Silent network authentication of phone number, device recognition, geo-location, etc.) The "sna" value () identifies one specific background method and is a subset of this value. Geo-location is separately registered as "geo" and device recognition is within the scope of "rba", both in .

"sna" (Silent Network Authentication) Method

sna:

Silent Network Authentication. Confirmation by the mobile network operator that the device making the request holds the subscriber identity associated with a given telephone number, performed without any interaction with the user. An example is the Number Verification API .

"email" (E-mail Channel) Method

email:

Use of e-mail as the channel by which an authentication interaction reached the user. What was delivered over the channel is described by an accompanying value such as "code" or "url". See . E-mail is not an acceptable channel for out-of-band authentication under Section 3.1.3.1 of . See .

"code" (Code provided to and entered by user) Method

code:

Code provided to and entered by user For example, a secret received on an out-of-band device and entered into the authentication session, as described in Section 3.1.3 of .

"url" (URL provided to and clicked on by user) Method

url:

URL provided to and clicked on by user

"push" (Push notification to mobile phone) Method

push:

Push notification to mobile phone An out-of-band authentication interaction in which the verifier reaches an application on the user's device over a secondary channel, as described in Section 3.1.3 of .

"facliv" (Facial Liveness Check) Method

facliv:

Determination that a facial image or video presented for authentication is of a live person rather than an artifact such as a photograph, mask, or synthetic rendering. This is a presentation attack detection measure . The "facliv" and "face" values describe different determinations and are not alternatives: "face" is a comparison of a presented face against a reference, and "facliv" is a determination that the presented face is live. Where both were performed, both values are included.

"passkey" (Passkey) Method

passkey:

A passkey, that is, a client-side discoverable credential as defined by .

"mdc" (Multi-Device Credential) Method

mdc:

Use of a multi-device credential as defined by , that is, a backup-eligible credential, which may be backed up and synchronized to other devices. Multi-device credentials are commonly referred to as synced passkeys. A WebAuthn Relying Party learns whether a credential is backup eligible from the flags in the authenticator data. This value describes whether a credential may be replicated. It is independent of how the key is protected on any one device, which "hwk" and "swk" describe. Where both are known, both are included. The absence of this value does not indicate that a credential is a single-device credential.

"uv" (User Verification) Method

uv:

User verification. Local authorization of the authenticator by an authorization gesture capable of distinguishing individual users, such as a PIN, a password, or biometric recognition . This is distinct from "user" , which is a test of user presence. As states, a user presence test "is not capable of biometric recognition, nor does it involve the presentation of a shared secret such as a password or PIN". This value does not identify which modality the authenticator used.

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

"tel" (Telephone Call) Method

tel:

Telephone call to the user at a registered number. The call may be used to provide information to the user, such as a code, that is then used in another channel. The call may be used for the user to provide information that the caller uses in the authentication.

This definition replaces the one in , which is "Confirmation by telephone call to the user at a registered number. This authentication technique is sometimes also referred to as 'call back' ."

Composing Authentication Method Reference Values The "amr" claim value is an array, and as described in , 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. 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 is related but narrower: it identifies a one-time password produced by an algorithm such as HOTP or TOTP , 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. gives examples, and maps terms in common industry use onto the corresponding sets of values. The "sms" value registered by 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.

Security Considerations The security considerations defined in Authentication Method Reference Values apply to this specification. E-mail is not an acceptable channel for out-of-band authentication under Section 3.1.3.1 of , 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. 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.

Privacy Considerations The privacy considerations defined in Authentication Method Reference Values apply to this specification.

IANA Considerations

Authentication Method References Registry This specification registers the following Authentication Method Reference values in the IANA "Authentication Method Reference Values" registry established by .

"app" Method

• Authentication Method Reference Name: app
• Authentication Method Reference Description: Authenticator App
• Change Controller: IETF
• Specification Document(s): of this specification

"bg" Method

• Authentication Method Reference Name: bg
• Authentication Method Reference Description: Background Authentication
• Change Controller: IETF
• Specification Document(s): of this specification

"sna" Method

• Authentication Method Reference Name: sna
• Authentication Method Reference Description: Silent Network Authentication
• Change Controller: IETF
• Specification Document(s): of this specification

"email" Method

• Authentication Method Reference Name: email
• Authentication Method Reference Description: Use of e-mail as the channel for an authentication interaction
• Change Controller: IETF
• Specification Document(s): of this specification

"code" Method

• Authentication Method Reference Name: code
• Authentication Method Reference Description: Code provided to and entered by user
• Change Controller: IETF
• Specification Document(s): of this specification

"url" Method

• Authentication Method Reference Name: url
• Authentication Method Reference Description: URL provided to and clicked on by user
• Change Controller: IETF
• Specification Document(s): of this specification

"push" Method

• Authentication Method Reference Name: push
• Authentication Method Reference Description: Push notification to mobile phone
• Change Controller: IETF
• Specification Document(s): of this specification

"facliv" Method

• Authentication Method Reference Name: facliv
• Authentication Method Reference Description: Facial Liveness Check
• Change Controller: IETF
• Specification Document(s): of this specification

"passkey" Method

• Authentication Method Reference Name: passkey
• Authentication Method Reference Description: Passkey
• Change Controller: IETF
• Specification Document(s): of this specification

"mdc" Method

• Authentication Method Reference Name: mdc
• Authentication Method Reference Description: Multi-Device Credential
• Change Controller: IETF
• Specification Document(s): of this specification

"uv" Method

• Authentication Method Reference Name: uv
• Authentication Method Reference Description: User Verification
• Change Controller: IETF
• Specification Document(s): of this specification

"tel" Method

• Authentication Method Reference Name: tel
• Authentication Method Reference Description: Telephone call to the user at a registered number
• Change Controller: IETF
• Specification Document(s): of this specification

References Normative References The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications. This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security. The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Skyfire Systems Inc. Self-Issued Consulting This document defines a token format for agent identity and payment tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this token format to consume identity and payment tokens in an interoperable manner. IANA International Organization for Standardization National Institute of Standards and Technology CAMARA Project

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: The following "amr" claim value indicates that a link was sent to the user over the e-mail channel and followed by the user: The following "amr" claim value indicates that a one-time password was generated by an authenticator application and entered by the user: 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:

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 , "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" .
• Added "uv" for user verification, distinct from the user presence test described by "user" .
• 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" describe different determinations and are included together where both were performed, and added a reference to .
• Added a reference for "passkey" to .
• Added references to for "app", "code", "push", and "email", and to 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" 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.