Mike, thanks again, and sorry for the slow follow-up. I’ve answered the remaining points inline below as Rob> Rob.
On Mon, 21 Sep 2026 at 8:08 am, Michael Jones <[email protected]> wrote: > 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.) > Rob> Good catch. I think I overstated the ISO point in my original note. ISO/IEC 30107-3 gives us the PAD framework and the testing/reporting terminology, but I don’t think we should say that “passive” and “active/challenge” are formal ISO categories. Rob> I would probably describe the distinction more plainly as unprompted liveness/PAD versus prompted challenge-response liveness/PAD. NIST gives a useful example of the second one in remote proofing, where the person is asked to move their head, raise or lower their eyes, or answer questions during a live video capture. Rob> I don’t think facliv itself necessarily needs to encode that distinction. I would be happy with facliv meaning that facial liveness/PAD was performed, and leave the finer distinction to a profile or another value if implementations later need it. > 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? > Rob> Yes. One small terminology point first, I assume you mean iat rather than iss here, since iss is the issuer and iat is the token issue time. Rob> I think there are cases where carrying both iat and auth_time matters. The simple one is where the human authentication or step-up happens at T0, but the action token is minted, exchanged or re-issued at T1. iat tells the relying party when that JWT was created. auth_time tells it when the human authentication event actually happened. Rob> For example, the human could confirm the action at 10:00, the agent could do some orchestration or token exchange, and the action token could be presented at 10:03. If the relying party has a rule that the human confirmation must have happened within the last two minutes, it cannot work that out from iat alone. Rob> If the architecture guarantees that the token is minted immediately from the authentication ceremony, with no later exchange or re-issuance, then I agree the two may be effectively redundant. So I would only carry auth_time where the freshness of the actual authentication event matters and it may differ from token issuance. > 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. > Rob> I’ve answered this one in Issue #9 with the implementation detail and references: https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verification/issues/9 > 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? > Rob> I wouldn’t define it mechanically as either the oldest or the newest individual step. Rob> If idv_time is a single scalar claim, I think the cleanest meaning is the time when the current identity-verification result was established. Rob> In a multi-step flow, that would normally be the point when all the required verification steps had completed successfully and the issuer was first in a position to assert the resulting identity-verification state. That will often be the last required step, but I think the meaning should be about when the overall result became valid, rather than just taking the minimum or maximum timestamp. Rob> If a relying party needs to know the age of the individual components, for example the document was checked two years ago but the biometric binding was refreshed yesterday, then one idv_time is not enough. In that case I think the individual evidence or verification records should carry their own timestamps. Rob> So my preference would be one idv_time for when the current aggregate verification result was established, with per-step times used where that extra detail matters. > 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! > Rob> Happy to. I think the main places where suggested text may help are facliv, the auth_time clarification, and the idv_time semantics. I can send proposed wording once we agree on the direction above. > > > Roberto Antonio Zagarella > Violet Shores Pty Ltd > > > > Thanks a > bunch! > > -- Mike > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
