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. 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. 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. 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. 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. 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. 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. 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. 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. Roberto Antonio Zagarella Violet Shores Pty Ltd
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
