Hi Rob, Thanks for your useful reviews of the specs. My replies are inline below prefixed by “Mike>”.
From: Rob Zagarella <[email protected]> Sent: Tuesday, September 15, 2026 6:19 PM To: [email protected] Subject: [OAUTH-WG] Implementer review of draft-skyfire-oauth-amr-values-01 and draft-skyfire-oauth-id-verification-01 All, I volunteered in Vienna to review draft-skyfire-oauth-amr-values and draft-skyfire-oauth-id-verification as an implementer. I sent comments to the authors off-list; they asked that the review go to the list, so here it is. Implementer context, one sentence: our authorization ceremony runs facial match plus an active liveness challenge (spoken digits and finger-count gestures) at the moment a person authorizes an agent action, and today we record that in a private claim set (an assurance level L1-L3, an attestation, and a per-modality record) because there is no registered vocabulary for it. These two drafts are the vocabulary we would adopt, so the review is really "would emitting these values tell a relying party what actually happened". draft-skyfire-oauth-amr-values-01 https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-skyfire-oauth-amr-values/&source=gmail&ust=1789324534372000&sa=E 1. Relationship to RFC 8176. Several new values sit close to registered ones: "sqa" and "kba"; "call" and "tel"; "code" and "otp"; "bg" and "geo"/"rba"; "facliv" and "face". Since the registry's own Expert Review criterion is whether a value duplicates existing functionality, a one-line note per value stating whether it specialises, extends, or is disjoint from the existing value would answer that question before it is asked, and would tell implementers like us which one to emit when both apply - we currently do not know whether to emit "face" and "facliv" together or "facliv" alone. Mike> Your review comments unsurprisingly cover some of the same ground as Jean Diaconu’s. See my replies to him at https://mailarchive.ietf.org/arch/msg/oauth/bm-_66XQuuXwnb6cazc3VxaMtZQ/. Mike> Overlap is almost intrinsic to “amr” values. As I wrote to Jean, In the “amr” values there are other values that are subsets. For instance “hwk” ⊂ “pop”. This isn’t necessarily a reason to remove the more specific value if it’s useful in some cases in practice. Mike> “call” is removed in https://github.com/skyfire-xyz/draft-skyfire-oauth-amr-values/pull/7. Security questions are somewhat distinct from knowledge-based questions. Not all codes are OTPs. Liveness detection is the new feature in “facliv”. Mike> As with other uses of “amr”, all the applicable values may be returned. I agree with you that it would be useful to add the clarifications you suggest and created https://github.com/skyfire-xyz/draft-skyfire-oauth-amr-values/issues/8 to track doing so. 2. "facliv". This is the value we would emit, so the definition matters most to us. "Liveness check" covers two things relying parties treat very differently: passive liveness (texture, depth, blink) and active challenge-response, where the user performs a prompted action. ISO/IEC 30107-3 draws the same line. Two options, either fine: reference PAD in the description, or state that "facliv" means any liveness and leave the passive/active distinction to a profile. What I would avoid is silence, because a relying party reading "facliv" will assume whichever one they have in mind. Mike> I see that https://www.iso.org/obp/ui/en/#iso:std:iso-iec:30107:-3:ed-2:v1:en is not publicly available. I was hoping to read what it says about this distinction. For starters, what are the ISO terms for the two modalities? And maybe what would you call them? (I can see the Table of Contents, but neither of the terms “passive” or “challenge” appear there.) 3. "bg". This aggregates several distinct implicit signals - network auth of a phone number, device recognition, geolocation. A relying party may read it as a possession factor when it may only have been a geo match. Consider either stating it is an aggregate of passive signals with no specific factor implied, or splitting it. Small point. Mike> As I wrote to Jean, It being silent makes it unique. If there are more specific silent values you want/need, please suggest them. 4. Action-scoped use. In the KYAPay case the JWT is authorizing an action, not opening a session, and our experience is that what a relying party wants to know is that the method ran for THIS action, not at some earlier login. A sentence noting that when the token is action-scoped the amr values describe the authentication that authorized that action, together with auth_time, would make the values load-bearing for the agent case. Without it the values are true but undated. Mike> The KYAPay token is declaring attributes of the involved parties at the time of issuance. This issuer is asserting them to be true at the “iss” time. Are there cases where also passing the “auth_time”, if different from “iss”, would make sense to you, and if so, can you describe them for us? draft-skyfire-oauth-id-verification-01 https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-skyfire-oauth-id-verification/&source=gmail&ust=1789324534372000&sa=E 1. Relationship to OpenID Connect for Identity Assurance. IDA's verified_claims already carries structured evidence - document, electronic_record, vouch, utility_bill - with trust_framework and assurance_level. "ivm" is clearly the compact array form, and I think that is the right thing to have, but the designated experts will ask about duplication. A short positioning sentence ("ivm is a compact summary of methods, suitable where the full verified_claims structure is not carried; where both are present, verified_claims governs") would pre-empt it. Mike> You’ll see that https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verification/pull/8 adds a description of the relationship to OpenID Connect for Identity Assurance. 2. The missing value is the most common remote flow. Document verification ("phy" or "dig") plus a live facial match of the person to the document is how most remote identity verification actually works, and it is exactly what our enrolment does. None of the eight values names the biometric binding of the live person to the document. Options: a value for it, for example "sbm" for selfie-to-document biometric match, or a sentence stating that biometric binding is signalled by co-occurrence with "facliv" in amr. Either works; without one of them "phy" alone reads as document inspection with no person attached. Mike> Clarifying questions: By “live facial match to the document”, are you describing a selfie with the person’s face and the document? Or maybe a video with the person’s face and the document? I agree we want to add this and I want the description to be good. Also, is there a document describing this procedure or procedures that we can reference in the spec? I’ve created https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verification/issues/9 to track this addition. 3. "dbv" / "dbv1" / "dbvm". Three values for one method distinguished by source count means "dbv" becomes "count unknown" once the other two exist. That may be intended; if so, saying so avoids the reader assuming "dbv" is the general case that subsumes the others. Mike> Nash Ali of Experian made the case to us that verification from only a single document source (such as when someone is just starting to establish credit) is substantially different than verification from multiple document sources, and so the distinction is meaningful. That said, there other existing cases of overlapping values, such as “hwk” (hardware key), “swk” (software key), and “pop” (proof of possession). “dbv” already says “using an unspecified number of consumer reporting data sources”. This seems like “count unknown” using different words to me. 4. Verification age. amr has auth_time; ivm has nothing equivalent, and identity verification is typically months or years old when the token is minted. For agentic payments the age of the verification is part of the trust decision. A companion claim - a verification time, or simply a note that deployments needing it should carry one - would close that. Mike> I’m thinking of an “idv_time” claim along the lines that you suggest. Of course, different verification steps may have occurred at different times. Should we be returning the time of the oldest one of them or the newest one of them or something I haven’t thought of? That is the lot. Our own work sits in this area, so please weigh the review accordingly; where you want text rather than comments I am happy to draft it, and I would be happier still to hear where any of it breaks. Mike> Great to have an expert reviewing this. By all means, if you have specific suggested text in any places, please bring it on! Roberto Antonio Zagarella Violet Shores Pty Ltd Thanks a bunch! -- Mike
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
