Hi Max, Thank you for the review. Four of the eight items change the draft. Taking them in your order.
Combinations of values Taking it, and the example you asked for doesn't work under the current text, which is the underlying defect. email is defined as "Use of code or link sent to e-mail", so the link is already inside it and ["email", "url"] is redundant. The fix starts there: 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. That's the move -02 already made for tel, which reads "The call may be used to provide information to the user, such as a code, that is then used in another channel." A new Section 5 then names the two ideas: Two of the values registered by this specification describe the channel by which an authentication interaction reached the person: email and push. [RFC8176] registers sms and tel in the same sense, and uses the term "channel" in this sense in its definition of mca. Two describe the challenge delivered over such a channel, which the person must return to the verifier to complete the authentication: code and url. 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. [RFC8176] registers otp in the same sense. 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. And two appendices. Appendix A is examples, which RFC 8176 has and this document did not. Appendix B maps terms in common industry use onto the values, so implementers of the same arrangement emit the same set: 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"] Voice one-time code: ["tel", "code"] Call-back confirmation: ["tel"] Authenticator application OTP, i.e. TOTP: ["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: ["passkey", "hwk"] TOTP is ["app", "otp"] rather than ["app", "code"], because RFC 8176's otp names [RFC4226] and [RFC6238] specifically. sms keeps its RFC 8176 definition, which predates this distinction and describes both a channel and the interaction over it. Section 5 says so. app Redefined by property: app: Use of an authenticator application on a device held by the user. And on your point that an IdP can't tell for shared-secret TOTP, it can't, so: An issuer includes this value where it knows an authenticator application was used; where a code is produced from a shared secret and the issuer cannot determine what produced it, the value is omitted. On browser plugins and CLI tools, we'd rather not register them. Form factor isn't an assurance property, and what a relying party acts on is whether the key was hardware-protected, which hwk and swk already answer. bg, and sna as a standalone Taking it: 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. We're keeping bg and stating the relationship: sna is a subset of it, geo-location is already geo, and device recognition is within the scope of rba. Which leaves bg thinner than its definition reads, the generic case where an issuer can say a background method ran but not which. That's still the one thing bg says that nothing else does. email Yes: email pairs with code or url. Email OTP is ["email", "code"], a magic link is ["email", "url"]. push Section 5 classifies it as a channel, and Appendix B distinguishes a plain approval, ["push"], from number matching, ["push", "code"], which is a different ceremony and now standard practice against MFA fatigue. facliv Keeping it, with the reference you asked for. ISO/IEC 30107 is the presentation attack detection standard: facliv: Determination that a facial image or video presented for authentication is of a live person rather than an artefact such as a photograph, mask or synthetic rendering. This is a presentation attack detection measure [ISO30107]. And the relationship to face, which Rob Zagarella asked for in his implementer review: facliv and face [RFC8176] 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. So it isn't a stronger face in the way a stronger password is still pwd. A liveness check without a match says a live person was present but not who; a match without liveness says the image matched but it may have been a photograph. We're not splitting passive from active liveness. Rob raised that and then withdrew it, and we agree the finer distinction belongs in a profile. sqa We propose dropping it, as a proposal rather than a decision: it removes a value, so we'd rather hear a counter now. RFC 8176 defines kba as "Knowledge-based authentication [NIST.800-63-2] [ISO29115]", and current NIST treats the two as one family: SP 800-63B-4: "Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., 'What was the name of your first pet?') or security questions when choosing passwords." SP 800-63A-4: "Knowledge-based verification (KBV) or knowledge-based authentication SHALL NOT be used for identity verification." NIST's worked example of KBA is a static security question. The distinction we're aware of is dynamic questions generated from records against static questions answered at enrolment, which makes them two flavours of one method. RFC 8176 groups at that level already: otp covers both HOTP and TOTP. If anyone has a definition that separates them rather than a convention, we'd rather see it now. If it goes, the Security Considerations note about security questions goes with it, since it exists for this value. The point attaches to kba, which is RFC 8176's. passkey W3C WebAuthn Level 3 defines "Passkey" formally, as a synonym for client-side discoverable credential: passkey: A passkey, that is, a client-side discoverable credential as defined by [WebAuthn]. One value doesn't carry everything a relying party may want here. Jean raised the device-bound against synced distinction, and it's a real one: a synced passkey's security depends on the account that replicates it, a device-bound one's does not. hwk and swk describe what protects a key, which is a different axis from whether it's replicated, and a synced passkey is held in the secure element on each device it lands on. So we'd rather register one value on the replication axis and compose it, giving four states from three values. WebAuthn has the terminology: it defines multi-device credential and single-device credential formally and treats "synced passkey" as the informal name for the first. Wording to follow; views welcome, especially from anyone closer to WebAuthn. One more value, which came out of your app comment RFC 8176's user is a "User presence test", evidence that someone is there. There's no value for user verification, and WebAuthn is explicit that they aren't the same thing: "a user presence test, by definition, is not capable of biometric recognition, nor does it involve the presentation of a shared secret such as a password or PIN" So we propose registering one: 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 [WebAuthn]. This is distinct from user [RFC8176], which is a test of user presence. This value does not identify which modality the authenticator used. Two limits worth stating, both of which come from your app point that a value shouldn't claim what the issuer cannot observe. It doesn't carry the modality. WebAuthn Level 3 removed the uvm extension that reported it, so a relying party learns that user verification happened and not whether it was a face, a finger or a PIN. Which also means an issuer shouldn't emit fpt or facliv for a biometric unlock performed inside an authenticator it didn't operate. And it isn't an identification. WebAuthn: "user verification does not give the Relying Party a concrete identification of the user, but when 2 or more ceremonies with user verification have been done with that credential it expresses that it was the same user that performed all of them." We will create a PR containing these issue resolutions, and will post here when it is up. Thanks again. Best, Ankit On Tue, Oct 06, 2026 04:20 PM, Max Gerber <mgerber= [email protected]> wrote: > Hello Mike, Ankit, Nash, Srinivasa, > > This is a review of draft-skyfire-oauth-amr-values-02 > <https://datatracker.ietf.org/doc/html/draft-skyfire-oauth-amr-values-02>. > > I am supportive of the intent of this work. The AMR registry hasn't grown > significantly since RFC 8176 landed in 2017, and many new methods are now > in use that should be defined. > > *TLDR:* I am in favor of adding email, push, and passkey. I would like to > see sna broken out into its own distinct method instead of bundled > together in bg. I would also like to see a non-normative example of how > combinations of applicable values may be used together. > Combinations of Values > > Mike - in response to a previous review from Jean, you wrote: > > 2. email, code, and url overlap each other with no composition rules; > email is literally defined as the union of the other two. > > Mike> As with other uses of “amr”, all the applicable values may be > returned. > > 2. Values mix channels and products (email, app) with actual > authentication methods. > > Mike> This matches requests from deployers. > > I suspect this will be a common point of contention/confusion - I > certainly had the same reaction as Jean and his agents. I would really > appreciate an additional AMR example showing composition, such as "amr": > ["email", "url"] > to represent a magic link sent over the email channel. > Inline Notes > > app: Authenticator App (e.g., Okta Verify, Google Authenticator, Microsoft > Authenticator) > > What *is* an app? What if someone used a browser plugin? A CLI tool? For > TOTP mechanisms based on a shared secret, how can an IDP even tell that an > app was used? Other "channels" such as email and tel have generally > acceptable definitions. I worry `app` does not. > > *bg: *Background Authentication (Silent network authentication of phone > number, device recognition, geo-location, etc.) > > This is a grab bag for several distinct technologies that solve (and > prove!) several distinct things. Geo-location is already covered by geo. > Device recognition and SNA conflate two different things. SNA is an > assurance from a network carrier of possession of a SIM card, while device > recognition could be anything at all. I believe device recognition would > already be covered by the rba method as well. > > I would be in favor of *sna as a standalone AMR method*, independent from > device recognition. > > *email: *Use of code or link sent to e-mail > > I am in favor of including email methods in some way. Email OTPs and email > magic links have both become quite popular. Should email always be paired > with code or url? email code = email OTP // email url = email magic link? > > *push: *Push notification to mobile phone > > I am supportive of push. > > *facliv: *Facial Recognition with Liveness Check > > As an outsider, this feels duplicative of face, perhaps subject to a > higher assurance level. Kind of like using a different amr method for a > stronger password than a weaker one. Admittedly I am not familiar with that > method of verification - if there is a document or reference that defines > liveness checks as a distinct technology or improvement over facial > recognition I would appreciate it. > > *sqa: *Security Question Answers > > This is duplicative of kba. If there is a document, or reference, that > explains the difference between a security question and a knowledge > question we can reference here, that would be appreciated. > > *passkey:* Passkey > > I am in support of adding passkey. Can we add a reference to a FIDO > specification describing passkeys? > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
