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]
