Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id CCCB44B for ; Fri, 06 Nov 2026 00:13:17 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=tryskyfire.com header.s=google header.b=WtoWz7ad; spf=pass (mx.ietf.org: domain of ankit@tryskyfire.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=ankit@tryskyfire.com; dmarc=pass (policy=quarantine) header.from=tryskyfire.com; arc=pass ("google.com:s=arc-20260327:i=1") Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-2e8da6ef7ddso360945ad.3 for ; Thu, 05 Nov 2026 16:13:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1793923991; cv=none; d=google.com; s=arc-20260327; b=Uqt25wWHiMShafHOWwNkMMPfqVFuGx7ABmqohDEVPLBrO/KvIwundfWgYqAXq5eEET K5AfVExA6tqdpY+W969kc0svn+brTsp0Uhe+VifHvhq0Wv/47gUK+Wo5jP2Wi41xzsSZ /4sFNaLHu1ThJrCkTEEiBnDoml7bnw2aZSRtNS5P0Uu0G78q1rEmCGsU0Sz18s0exRKh ZorKhp6TOiYfs0cGtVm8ifQqy8QldPLmLD/s8v5YdM7qqmJm84nAlw2TH/0hKSpb1CUM sMBg2Ohbu1naWqxyhKk1Z47jRv1otY0zl/zcGt2yX4P2LSrMewuOhbFTDGjRwUlW69QZ KNqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=6xiIkoQGaAcad9T1ADOV8aQz78v3GiQd04Ays9C4gqw=; fh=o7fFbP6z1Cyl1qgHsj618GfMhdstGlLYgTvwWYyMDgE=; b=T4VNCSLZSmG6mN65T4qTXSfGPlDwBypzu82KooOL6XnXmvg6cUazQL9vjuaJwrtqUj 5HEphUIctum6tjFdMZAD7y/LymqkEFkJ1iqMyErpJXYWKy47vVQK+5UL6exIrD/2gF6i ZTSqv3kx9Bnpecnxd0m2ZQSxKnLU61p4JKocoZZmxFdIKsnDfZBQZ26hzS9SwySlaTdV idktteoUo3Uy+uwbmOGqUfiN57BRapAWITzdf7UaGeqFjpvfAWiQ8ArUi2gvGyXlQZpQ aUNV3DeXKUwySgE1F58WpXctgbx8WwQadt7nh2lX+qYAQkTZauuT81/uBEf2zEU9VEl0 UFxw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tryskyfire.com; s=google; t=1793923991; x=1794528791; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6xiIkoQGaAcad9T1ADOV8aQz78v3GiQd04Ays9C4gqw=; b=WtoWz7adpQimWhKkA0UWB6b2PvXqOWaHzPQdJeY0D+AtLFnhAJv5Rv2dusHpRHWoYy hIW968yBJi8wLWRQ6SzY9a//rFFzXdX6QXiy7rs46xsI3Ww0IWcMwvW9ut+9ieKNbufb CUQluZ7EgXlgGWakI5ED5h4OoPUrtlzZvJctAFLLGGBA8RzAFkv2VtYfy43tQKu8ltgW 7el+Ej+F1cF66RFCh0oh4nRb81cC067GGYQc+EjkwETbPWVzthOtkdkVl5Q+VAsFsJUC xKDPBCebSiLC96xZz5R7VvQPp6y/7tAIrz3KFUw1RHZOQ+P1lz85s/PSz/EWa9ve+y/i kqyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793923991; x=1794528791; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=6xiIkoQGaAcad9T1ADOV8aQz78v3GiQd04Ays9C4gqw=; b=dCIStOoDh9F9xwh1wcmfo3jzagiL885t8EEJq16msuqGF71m+k1cHk0Lp/2eSktN2s evKacef4Z7TDzX+TaGdVplxfsk0u24kpifV5tnrrMPu1IILQeLsfEM18ElMPXqiTktYB rPxQURmLXxTnUPNO79pOkt10jhmeHy7DqHGwuE97f6jcUbgUcAzwT1NN9spjYGR2X4hh lkpN64dKU/SvT5KPoVcDPlz6DPpOEKjmopzzxnUheG1ktY4+BzyY1lfsffYvV1SGc+5k cFlF+hgfxEgHciYg6mNIOPg7sjZi6e9E0Y7a1EHN4qq68ueYRwysBrOyD3scPbx+FmgM G4Dg== X-Gm-Message-State: APuU4Z/fd/l8+WSUApwRlR56EQ54inYZaMho5F+oVTyMcCAsRdMJo5UA ArT1fyGCguinuNgO3IRtRR18RXPXQCqVItXVBth+A2nJf3cR1jcnYdKAY9RfHC8H06u8RH8CCne mVhUkDvZ8qBTmL41ZVZp5xl4PkSVr9MmM99xsM7d8WQ== X-Gm-Gg: AYBFou0YlKjlSkTKf0Xvo20h7N38MZ1QaW53OTtqHyWte/PyKKOkFoNh60Tc8xdPS+v ASKzDz5ps1+MnWt68NiOhozhpynsgQRTngJqb0ReyFdNMqkEy//b9BD/lSJbxQWmLht0ndpCvBJ xLSJ+56jXDayx/lQT+/okaJLmJ74IMru2ohfBhcmFjlLyUAQj4cnVhk/CQCZ56RgvLevlHc0pwm 2DCudnjU4UqV5aIDxHqXGG46f/jGnAjDOXfILAp8oMLNhs5rGo0fadQwxJdjB4ysVOfuO4Tu09P HKkNjLNCn5jqSoyNRa4rLfcofFO0Gz1BZR0XeSEpKXPE/BuxXkXMSeHnJehexGoS5QGQRttgB9C w3ddmreUvPRXnNISvIY2uyTMhvsF9Glx5okNAG93I9Vd4oTNrWuj8Gv5sgrpOJEygfxnUk8hpIn Sqk2QzaYMiKL2ypTfi60NpRPbhBVN5EpSursaFZZR+NwZQEbOW X-Received: by 2002:a17:903:2289:b0:2e4:b37a:d577 with SMTP id d9443c01a7336-2ed40de7805mr12922645ad.43.1793923990340; Thu, 05 Nov 2026 16:13:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ankit Agarwal Date: Thu, 5 Nov 2026 16:12:59 -0800 X-Gm-Features: AclHuK_mloRGqC5Nom3s7OTB4exfPaUW9aoMGS0rK-zPFlRPuQYlITHg4tz0xEI Message-ID: To: jdiaconu@cisco.com Content-Type: multipart/alternative; boundary="00000000000032d6f7065f907a9c" X-Spamd-Bar: ------------------ Message-ID-Hash: LOUTSGK6DWJFDM2OB6ENVS7TKPZH6MAG X-Message-ID-Hash: LOUTSGK6DWJFDM2OB6ENVS7TKPZH6MAG X-MailFrom: ankit@tryskyfire.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-oauth.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: oauth@ietf.org, mike@tryskyfire.com, ankit@tryskyfire.com X-Mailman-Version: 3.3.10 Precedence: list Subject: [OAUTH-WG] Re: Review of draft-skyfire-oauth-kyapay-* List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000032d6f7065f907a9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jean, The open points from your review are now tracked as issues: - Separate KYA and PAY tokens in one request: https://www.google.com/url?q=3Dhttps://github.com/skyfire-xyz/draft-skyfire= -oauth-using-kyapay-tokens/issues/23&source=3Dgmail&ust=3D1794009644763000&= sa=3DE The token draft (-03) already says the two refer to the same initiator only when both "iss" and "sub" are equal; the issue is about pointing to that from the Using draft. - Human in the Loop, letting a site ask for a recent human confirmation: https://www.google.com/url?q=3Dhttps://github.com/skyfire-xyz/draft-skyfire= -oauth-using-kyapay-tokens/issues/24&source=3Dgmail&ust=3D1794009644763000&= sa=3DE - AML methods, normative references to vendor pages, and false, stale or sensitive assertions: https://www.google.com/url?q=3Dhttps://github.com/skyfire-xyz/draft-skyfire= -oauth-aml-methods/issues/3&source=3Dgmail&ust=3D1794009644763000&sa=3DE https://www.google.com/url?q=3Dhttps://github.com/skyfire-xyz/draft-skyfire= -oauth-aml-methods/issues/4&source=3Dgmail&ust=3D1794009644763000&sa=3DE Ankit On Mon, Sep 21, 2026 08:19 AM, "Jean Diaconu (jdiaconu)" wrote: > Hello Mike, > > I did receive the message and the PR, thanks !! > I'll check it asap. > > Best, > > > > *Jean Diaconu * > ------------------------------ > *De :* Michael Jones > *Envoy=C3=A9 :* vendredi, septembre 18, 2026 8:50 PM > *=C3=80 :* Jean Diaconu (jdiaconu) ; oauth@ietf.org < > oauth@ietf.org> > *Objet :* RE: [OAUTH-WG] Review of draft-skyfire-oauth-kyapay-* > > > Hi Jean, > > > > I replied to your reviews on the OAuth mailing list. Let me know if you > received the reply, as there has been some delivery flakiness as of late. > > > > Thanks > again, > > -- Mike > > > > *From:* Michael Jones > *Sent:* Friday, September 18, 2026 11:47 AM > *To:* 'Jean Diaconu (jdiaconu)' ; > oauth@ietf.org > *Subject:* RE: [OAUTH-WG] Review of draft-skyfire-oauth-kyapay-* > > > > Many thanks for the useful reviews, Jean! My replies are inline below, > prefixed by =E2=80=9CMike>=E2=80=9D. You=E2=80=99ll find links to a numb= er of PRs and issues filed > as a result of your reviews, Jean. Please review! > > > > -- Mike > > > > *From:* Jean Diaconu (jdiaconu) <*jdiaconu=3D40cisco.com@dmarc.ietf.org > *> > *Sent:* Wednesday, September 9, 2026 2:07 AM > *To:* *oauth@ietf.org * > *Subject:* [OAUTH-WG] Review of draft-skyfire-oauth-kyapay-* > > > > Hello Mike, Ankit, > > > > Please find below a quick review of the "draft-skyfire-oauth-kyapay-*" > drafts: > > > > *Main Draft (Human)* > > 1.1 "Because these agents can be hard to distinguish from traditional > bots, they are often inadvertently blocked, creating a need for the web > security ecosystem to distinguish between legitimate agentic traffic and > truly malicious activity" > > =3D> not all bots all malicious, maybe it's a strong word > > > > 3.2 aid is flagged as required but in 3.2.3 is optional > > (same for sti) > > > > Mike> I have attempted to address these comments in *https://github.com/s= kyfire-xyz/draft-skyfire-oauth-kyapay-token/pull/49 > = *. > Note that =E2=80=9Caid=E2=80=9D and =E2=80=9Csti=E2=80=9D are already des= ignated as REQUIRED in the > editor=E2=80=99s draft at *https://skyfire-xyz.github.io/draft-skyfire-oa= uth-using-kyapay-tokens/#go.draft-skyfire-oauth-using-kyapay-tokens.html > * > . > > > > 3.2.1 What is an example of verifier below ? Is some "method" also needed= ? > > > > verifier: > > OPTIONAL - URL of the Identity Verifier > > verified: > > OPTIONAL - Boolean Verification status. True if verified, otherwise false= . > > verification_id: > > OPTIONAL - Verification identifier. Identifier for the verification > performed, such as a GUID. > > > > Mike> I=E2=80=99ve opened *https://github.com/skyfire-xyz/draft-skyfire-o= auth-kyapay-token/issues/50 > * to > track the need to improve the verifier description. > > > > Globally > > =3D> Any thoughts about possible replay attacks > > > > Mike> Replay attacks can be detected using the =E2=80=9Cjti=E2=80=9D clai= m. I=E2=80=99ve added > this to *PR #49 > = *. > Also, short token lifetimes are recommended as a defense against replay. > > > > =3D> Maybe enrich the examples for the combinations KYA+PAY > > > > Mike> What kinds of additional examples would be useful to you? > > > > *draft-skyfire-oauth-kyapay-token-exchange-01 (Human)* > > > > 3.1 The scope becomes from "" to "openid profile email mcp =3D> what is t= he > logic behind this > > > > Mike> I have a question outstanding about this to the engineers who built > the prototype that these examples are taken from. > > > > In the example the sub is translated from the hid? I see client_metadata > but it still feels that we could add more about the delegation behind too > (act claim etc.) > > > > Mike> I am reworking this part of the spec. Stay tuned=E2=80=A6 > > > > *draft-skyfire-oauth-using-kyapay-tokens-00 (Human)* > > > > 1. Bots were unwelcome, and they remain unwelcome. =3D> It depends, can > we say "mostly unwelcome" ? > > > > See *https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-toke= ns/pull/5 > * > . > > > > Now we get the answers of the main draft: replay / verifier structure > > > > 4.3. The Proof-of-Possession Path (Planned Evolution) > > Is D&B a solution for this work ? They are working on issuing VCs (Ankit > is aware) > > > > Mike> This section is about cryptographic proof of possession. D&B is > potentially relevant to the identity proofing claims. > > > > 6.1 Maybe some precisions if there needs to be correlation between the > tokens (like KYA and PAY) > > > > Mike> They KYA and PAY claims separate sets of claims in a KYAPay token. > They are bound together by the signature over the token. Is there > additional correlation between the two sets of claims that you believe ar= e > needed and when would they be needed? > > > > Globally > > =3D> It feels that more or less we're good a proving provenance/delegatio= n. > Is it pertinent, at least for the most sensitive operations, to also > include a HIL ? > > > > Mike> Yes, there are situations in which it=E2=80=99s important to be abl= e to have > a Human in the Loop. The KYAPay flows accommodate this. =E2=80=9CHuman = in the > Loop=E2=80=9D considerations sound more like they belong in the Using KYA= Pay spec? > Do you have suggested text and a possible location, Jean? > > > > *draft-skyfire-oauth-aml-methods-00* > > [Claude] > > 1. Five normative references to vendor blogs and product pages (Thomson > Reuters, Moody's, Swift, Persona, plus a Treasury FAQ index) =E2=80=94 tw= o entirely > undated, none definitional. FATF Recommendations / Glossary are the citab= le > substitutes, and as informative references. > > > > Mike> I=E2=80=99ve filed *https://github.com/skyfire-xyz/draft-skyfire-oa= uth-aml-methods/issues/3 > = * about > this issue. > > > > 2. Records that screening ran, never its result =E2=80=94 no outcome, dat= e, lists, > or expiry =E2=80=94 so no target can discharge an AML obligation from it,= which is > the stated motivation. > > > > Mike> This parallels the way that =E2=80=9Camr=E2=80=9D values are used. = This is > described in *https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-meth= ods/pull/5 > *. > > > > 3. Privacy is one sentence for the most sensitive claim in the family. > pep, adv, and sanc disclose screening status about a named person to bot > managers, CDNs, and fraud vendors; and because there's no outcome, the on= ly > safe reading of any value is adverse. Tipping-off rules (e.g. 4AMLD > Art. 39) need analysis. > > > > Mike> The intent is that the inclusion of a value indicates compliance. > > > > 4. ofac =E2=8A=82 sanc, and it's the only jurisdiction-specific value in = a > document claiming worldwide scope; nominating the AMR designated experts = to > adjudicate AML semantics raises the venue question. > > > > Mike> In the =E2=80=9Camr=E2=80=9D values there are other values that are= subsets. For > instance =E2=80=9Chwk=E2=80=9D =E2=8A=82 =E2=80=9Cpop=E2=80=9D. This isn= =E2=80=99t necessarily a reason to remove the > subset value if it=E2=80=99s useful in some cases in practice. > > > > [GPT 5.6 Sol] > > 1. Records that screening occurred, but not whether it passed, matched, o= r > was inconclusive. > > > > Mike> Again, the intent is that if a value is included, compliance is > indicated. > > > > 2. Missing subject, time, validity, jurisdiction, list/provider, and > evidence identifier. > > > > Mike> Again, this intentionally parallels the way that =E2=80=9Camr=E2=80= =9D values are > used. > > > > 3. ofac, sanc, watch, and pep overlap without composition rules. > > > > Mike> =E2=80=9Camr=E2=80=9D values also sometimes overlap, which hasn=E2= =80=99t hurt their > applicability. That said, suggestions for particular adjustments or > refinements are welcome. > > > > 4. =E2=80=9COFAC Compliance=E2=80=9D improperly implies a broad complianc= e conclusion. > > > > Mike> How should this description be improved? > > > > 5. Security/privacy sections do not address false, stale, or sensitive AM= L > assertions. > > > > Mike> I=E2=80=99ve filed *https://github.com/skyfire-xyz/draft-skyfire-oa= uth-aml-methods/issues/4 > = * about > this issue. > > > > *draft-skyfire-oauth-amr-values-01* > > [Claude] > > 1. Four of ten duplicate already-registered values: sqa=E2=8A=82kba, code= =E2=89=88otp, > call=E2=89=88tel, facliv/face =E2=80=94 against the registry's own review= criterion. > > > > Mike> Security questions somewhat distinct from knowledge-based > questions. Not all codes are OTPs. Liveness detection is the new featur= e > in =E2=80=9Cfacliv=E2=80=9D. > > > > Mike> I agree that =E2=80=9Ccall=E2=80=9D is a dup of =E2=80=9Ctel=E2=80= =9D. This is removed in *https://github.com/skyfire-xyz/draft-skyfire-oaut= h-amr-values/pull/7 > *. > > > > 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 =E2=80=9Camr=E2=80=9D, all the applicable val= ues may be > returned. > > > > 3. psk means pre-shared key throughout the IETF (TLS-PSK, IKEv2, EAP-PSK)= . > Rename; and the distinction worth conveying =E2=80=94 device-bound vs. sy= nced > passkey =E2=80=94 can't be expressed by one flat value. > > > > Mike> Renamed "psk" to "passkey" in the PR because of the potential > confusion with pre-shared key. Device-bound passkeys can be indicated > using =E2=80=9Chwk=E2=80=9D and synced passkeys can be indicated using = =E2=80=9Cswk=E2=80=9D. > > > > 4. Every description is unsourced, a regression from RFC 8176, which > anchored all 21 values in external definitions. > > > > Mike> I have added *https://github.com/skyfire-xyz/draft-skyfire-oauth-am= r-values/issues/6 > *= to > track this issue. > > > > [GPT 5.6 Sol] > > 1. call duplicates existing tel; sqa overlaps kba; code overlaps otp. > > > > Mike> Same answer as above > > > > 2. Values mix channels and products (email, app) with actual > authentication methods. > > > > Mike> This matches requests from deployers. > > > > 3. No composition rules for combinations such as email + code or passkey = + > biometric. > > > > Mike> As with other uses of =E2=80=9Camr=E2=80=9D, all the applicable val= ues may be > returned. > > > > 4. bg bundles unrelated device, network, geolocation, and risk signals. > > > > Mike> It being silent makes it unique. > > > > 5. sqa lacks a warning that security questions are not acceptable > authentication secrets under current NIST guidance. > > > > I have added this warning to the security considerations in the PR. > > > > *draft-skyfire-oauth-id-verification-01* > > [Claude] > > 1. Duplicates verified_claims =E2=80=94 already in the IANA JWT Claims re= gistry, > with time, assurance_level, and evidence methods pipp/sripp/eid mapping > almost one-to-one onto these values =E2=80=94 and RFC 8485's vot (P =3D i= dentity > proofing). Neither is mentioned. > > > > Mike> This parallels the way that =E2=80=9Camr=E2=80=9D values are used. = This is > described in *https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verif= ication/pull/8 > * > . > > > > Mike> The relationship to the OpenID IDA work is also described, as is > the relationship to Vectors of Trust. > > > > 2. Records the method but not the time, outcome, verifier, or level, so i= t > can't support the assurance decisions the siblings build on it. > > > > Mike> The PR describes that the "ivm" claim contains a set of identity > verification methods that succeeded. > > > > 3. One top-level array cannot scope to hid vs. apd, both of which the bas= e > spec allows to be independently verified. > > > > Mike> This applies to =E2=80=9Chid=E2=80=9D. > > > > 4. Three different IANA field-name schemes across eight registrations > (template says "Specification Document(s)"; six entries say "Reference"; > two use the AMR registry's field names). > > > > Mike> Thanks =E2=80=93 corrected in the PR > > > > [GPT 5.6 Sol] > > 1. No verification result, time, assurance level, trust framework, or > evidence provenance. > > > > Mike> Same answer as above > > > > 2. dbv, dbv1, and dbvm overlap; source count alone does not establish > assurance. > > > > Mike> Business people tell me that single and multiple and different from > a compliance perspective. Yes, the overlap is expected - just as "hwk=E2= =80=9D, > =E2=80=9Cswk=E2=80=9D, and =E2=80=9Cpop=E2=80=9D overlap. > > > > 3. Evidence types (dig, phy) are mixed with channels or ceremonies (inp, > vid). > > > > Mike> The same is true of =E2=80=9Camr=E2=80=9D. The vocabulary is inten= ded to be > expressive =E2=80=93 not mutually exclusive. > > > > 4. Methods are not bound to particular verified attributes or entities. > > > > This applies to =E2=80=9Chid=E2=80=9D. > > > > 5. The draft duplicates concepts already modeled more completely by OpenI= D > Identity Assurance. > > > > Mike> The relationship to OpenID Identity Assurance is now described. > > > > Have a nice day, > > Best, > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org > --00000000000032d6f7065f907a9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jean,

The open points fro= m your review are now tracked as issues:

- Separate KYA and PAY toke= ns in one request:
ht= tps://www.google.com/url?q=3Dhttps://github.com/skyfire-xyz/draft-skyfire-o= auth-using-kyapay-tokens/issues/23&source=3Dgmail&ust=3D17940096447= 63000&sa=3DE
The token draft (-03) already says the two refer = to the same initiator only when both "iss" and "sub" ar= e equal; the issue is about pointing to that from the Using draft.
- Hum= an in the Loop, letting a site ask for a recent human confirmation:
https://www.google.com/url?q= =3Dhttps://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/i= ssues/24&source=3Dgmail&ust=3D1794009644763000&sa=3DE
- = AML methods, normative references to vendor pages, and false, stale or sens= itive assertions:
https://www.= google.com/url?q=3Dhttps://github.com/skyfire-xyz/draft-skyfire-oauth-aml-m= ethods/issues/3&source=3Dgmail&ust=3D1794009644763000&sa=3DE
https://www.google.com/url?q= =3Dhttps://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/4&= amp;source=3Dgmail&ust=3D1794009644763000&sa=3DE

Ankit


=
On Mon, Sep 21, 2026 08:19 AM, "Jean Diaconu (jdiaconu)" <= ;jdiaconu@cisco.com= > wrote:
Hello Mike,

I did receive the message and the PR, thanks !!
I'll check it asap.

Best, =C2=A0=C2=A0=C2=A0

=C2=A0

Jean Diaconu=C2=A0=C2=A0

De=C2=A0= :=C2=A0Michael Jones <michael_b_jones@hotmail.com>
Envoy=C3=A9=C2=A0:=C2=A0vendredi, septembre 18, 2026 8:50 PM
=C3=80=C2=A0:=C2=A0Jean Diaconu (jdiaconu) <jdiaconu@cisco.com>; oauth@ietf.org <oauth@ietf.org>
Objet=C2=A0:=C2=A0RE: [OAUTH-WG] Review of draft-skyfire-oauth-kyapa= y-*
=C2=A0

Hi Jean,

=C2=A0

I replied to your reviews on the OAuth maili= ng list.=C2=A0 Let me know if you received the reply, as there has been som= e delivery flakiness as of late.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From:= =C2=A0Michael Jones
Sent:=C2=A0Friday, September 18, 2026 11:47 AM
To:=C2=A0'Jean Diaconu (jdiaconu)' <jdiaconu=3D40cisco.com@dmarc.iet= f.org>; oauth@ie= tf.org
Subject:=C2=A0RE: [OAUTH-WG] Review of draft-skyfire-oauth-kyapay-*<= /span>

=C2=A0

Many thanks for the useful reviews, Jean!=C2= =A0 My replies are inline below, prefixed by =E2=80=9CMike>=E2=80=9D.=C2= =A0 You=E2=80=99ll find links to a number of PRs and issues filed as a resu= lt of your reviews, Jean.=C2=A0 Please review!

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From:= =C2=A0Jean Diaconu (jdiaconu) <jdiaconu=3D40cisco.com@dmarc.iet= f.org>
Sent:=C2=A0Wednesday, September 9, 2026 2:07 AM
To: oau= th@ietf.org
Subject:=C2=A0[OAUTH-WG] Review of draft-skyfire-oauth-kyapay-*

=C2=A0

Hello Mike, Ankit,

=C2=A0

Please find below a quick review of the "d= raft-skyfire-oauth-kyapay-*" drafts:

=C2=A0

Main Draft (Human)

1.1 "Because these agents can be hard to d= istinguish from traditional bots, they are often inadvertently blocked, cre= ating a need for the web security ecosystem to distinguish between legitima= te agentic traffic and truly malicious activity"

=3D> not all bots all malicious, maybe it= 9;s a strong word

=C2=A0

3.2 aid is flagged as required but in 3.2.3 is = optional

(same for sti)

=C2=A0

Mike> I have attempted to address these c= omments in https://github.com/skyfire-xyz/draft-skyfire-oauth-kyapay-token/pull/4= 9.=C2=A0 Note that =E2=80=9Caid=E2=80=9D and =E2=80=9Csti=E2=80=9D are already desi= gnated as REQUIRED in the editor=E2=80=99s draft at https://skyfire-xyz.git= hub.io/draft-skyfire-oauth-using-kyapay-tokens/#go.draft-skyfire-oauth-usin= g-kyapay-tokens.html.<= /p>

=C2=A0

3.2.1 What is an example of verifier below ? Is= some "method" also needed ?

=C2=A0

verifier:

OPTIONAL - URL of the Identity Verifier<= /p>

verified:

OPTIONAL - Boolean Verification status. True if= verified, otherwise false.

verification_id:

OPTIONAL - Verification identifier. Identifier = for the verification performed, such as a GUID.

=C2=A0

Mike> I=E2=80=99ve opened https://github.com/skyfire= -xyz/draft-skyfire-oauth-kyapay-token/issues/50=C2=A0to track the need to improve the verifier description.

=C2=A0

Globally

=3D> Any thoughts about possible replay atta= cks

=C2=A0

Mike> Replay attacks can be detected usin= g the =E2=80=9Cjti=E2=80=9D claim.=C2=A0 I=E2=80=99ve added this to PR #49.=C2=A0 Also, short token lifetimes are recommended as a defense against replay.

=C2=A0

=3D> Maybe enrich the examples for the combi= nations KYA+PAY

=C2=A0

Mike> What kinds of additional examples w= ould be useful to you?

=C2=A0

draft-skyfire-oauth-kyapay-token-exchange-01= (Human)

=C2=A0

3.1 The scope becomes from "" to &quo= t;openid profile email mcp =3D> what is the logic behind this

=C2=A0

Mike> I have a question outstanding about th= is to the engineers who built the prototype that these examples are taken f= rom.

=C2=A0

In the example the sub is translated from the h= id? I see client_metadata but it still feels that we could add more about t= he delegation behind too (act claim etc.)

=C2=A0

Mike> I am reworking this part of the spec.= =C2=A0 Stay tuned=E2=80=A6

=C2=A0

draft-skyfire-oauth-using-kyapay-tokens-00 (= Human)

=C2=A0

1. Bots were unwelcome, and they remain unwelco= me. =3D> It depends, can we=C2=A0say "mostly unwelcome" ?

=C2=A0

See https://github.com/skyfire-xy= z/draft-skyfire-oauth-using-kyapay-tokens/pull/5.

=C2=A0

Now we get the answers of the main draft: repla= y / verifier structure

=C2=A0

4.3. The Proof-of-Possession Path (Planned Evol= ution)

Is D&B a solution for this work ? They are = working on issuing VCs (Ankit is aware)=C2=A0

=C2=A0

Mike> This section is about cryptographic= proof of possession.=C2=A0 D&B is potentially relevant to the identity= proofing claims.

=C2=A0

6.1 Maybe some precisions if there needs to be = correlation between the tokens (like KYA and PAY)

=C2=A0

Mike> They KYA and PAY claims separate se= ts of claims in a KYAPay token.=C2=A0 They are bound together by the signat= ure over the token.=C2=A0 Is there additional correlation between the two s= ets of claims that you believe are needed and when would they be needed?

=C2=A0

Globally

=3D> It feels that more or less we're go= od a proving provenance/delegation. Is it pertinent, at least for the most = sensitive operations, to also include a HIL ?

=C2=A0

Mike> Yes, there are situations in which = it=E2=80=99s important to be able to have a Human in the Loop.=C2=A0 The KY= APay flows accommodate this.=C2=A0 =E2=80=9CHuman in the Loop=E2=80=9D cons= iderations sound more like they belong in the Using KYAPay spec?=C2=A0 Do you have suggested text and a possible location, Jean?

=C2=A0

draft-skyfire-oauth-aml-methods-00

[Claude]

1. Five normative references to vendor blogs an= d product pages (Thomson Reuters, Moody's, Swift, Persona, plus a Treas= ury FAQ index) =E2=80=94 two entirely undated, none definitional. FATF Reco= mmendations / Glossary are the citable substitutes, and as informative references.

=C2=A0

Mike> I=E2=80=99ve filed https://git= hub.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/3= =C2=A0about this issue.

=C2=A0

2. Records that screening ran, never its result= =E2=80=94 no outcome, date, lists, or expiry =E2=80=94 so no target can di= scharge an AML obligation from it, which is the stated motivation.

=C2=A0

Mike> This parallels the way that =E2=80= =9Camr=E2=80=9D values are used.=C2=A0 This is described in https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/pull/5.

=C2=A0

3. Privacy is one sentence for the most sensiti= ve claim in the family. pep, adv, and sanc disclose screening status about = a named person to bot managers, CDNs, and fraud vendors; and because there&= #39;s no outcome, the only safe reading of any value is adverse. Tipping-off rules (e.g. 4AMLD Art.=C2=A039) need = analysis.

=C2=A0

Mike> The intent is that the inclusion of= a value indicates compliance.

=C2=A0

4. ofac =E2=8A=82=C2=A0sanc, and it's the only jurisdiction-specific value in a = document claiming worldwide scope; nominating the AMR designated experts to adjudicate AML semantics raises the venue question.

=C2=A0

Mike> In the =E2=80=9Camr=E2=80=9D values= there are other values that are subsets.=C2=A0 For instance =E2=80=9Chwk= =E2=80=9D =E2=8A=82=C2=A0=E2=80=9Cpop=E2=80=9D.= =C2=A0 This isn=E2=80=99t necessarily a reason to remove the subset value i= f it=E2=80=99s useful in some cases in practice.

=C2=A0

[GPT 5.6 Sol]

1. Records that screening occurred, but not whe= ther it passed, matched, or was inconclusive.

=C2=A0

Mike> Again, the intent is that if a valu= e is included, compliance is indicated.

=C2=A0

2. Missing subject, time, validity, jurisdictio= n, list/provider, and evidence identifier.

=C2=A0

Mike> Again, this intentionally parallels= the way that =E2=80=9Camr=E2=80=9D values are used.

=C2=A0

3. ofac, sanc, watch, and pep overlap without c= omposition rules.

=C2=A0

Mike> =E2=80=9Camr=E2=80=9D values also s= ometimes overlap, which hasn=E2=80=99t hurt their applicability.=C2=A0 That= said, suggestions for particular adjustments or refinements are welcome.

=C2=A0

4. =E2=80=9COFAC Compliance=E2=80=9D improperly= implies a broad compliance conclusion.

=C2=A0

Mike> How should this description be impr= oved?

=C2=A0

5. Security/privacy sections do not address fal= se, stale, or sensitive AML assertions.

=C2=A0

Mike> I=E2=80=99ve filed https://git= hub.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/4= =C2=A0about this issue.

=C2=A0

draft-skyfire-oauth-amr-values-01=

[Claude]

1. Four of ten duplicate already-registered val= ues: sqa=E2=8A=82kba, code=E2=89=88ot= p, call=E2=89=88tel, facliv/face =E2=80=94 against the registry's own r= eview criterion.

=C2=A0

Mike> Security questions somewhat distinct from knowledge-based question= s.=C2=A0 Not all codes are OTPs.=C2=A0 Liveness detection is the new featur= e in =E2=80=9Cfacliv=E2=80=9D.

=C2=A0

Mike> I agree that =E2=80=9Ccall=E2=80=9D is a dup of =E2=80=9Ctel=E2=80= =9D.=C2=A0 This is removed in https://github.com/skyfire-xyz/draft-skyfire-oauth-amr-val= ues/pull/7.

=C2=A0

2. email, code, and url overlap each other with= no composition rules; email is literally defined as the union of the other= two.

=C2=A0

Mike> As with other uses of =E2=80=9Camr=E2= =80=9D, all the applicable values may be returned.

=C2=A0

3. psk means pre-shared key throughout the IETF= (TLS-PSK, IKEv2, EAP-PSK). Rename; and the distinction worth conveying =E2= =80=94 device-bound vs. synced passkey =E2=80=94 can't be expressed by = one flat value.

=C2=A0

Mike> Renamed "psk" to "passk= ey" in the PR because of the potential confusion with pre-shared key.= =C2=A0 Device-bound passkeys can be indicated using =E2=80=9Chwk=E2=80=9D a= nd synced passkeys can be indicated using =E2=80=9Cswk=E2=80=9D.

=C2=A0

4. Every description is unsourced, a regression= from RFC 8176, which anchored all 21 values in external definitions.

=C2=A0

Mike> I have added https://github.com/skyfire-xyz/draft= -skyfire-oauth-amr-values/issues/6=C2=A0to track this issue.

=C2=A0

[GPT 5.6 Sol]

1. call duplicates existing tel; sqa overlaps k= ba; code overlaps otp.

=C2=A0

Mike> Same answer as above

=C2=A0

2. Values mix channels and products (email, app= ) with actual authentication methods.

=C2=A0

Mike> This matches requests from deployers.<= /span>

=C2=A0

3. No composition rules for combinations such a= s email + code or passkey + biometric.

=C2=A0

Mike> As with other uses of =E2=80=9Camr=E2= =80=9D, all the applicable values may be returned.

=C2=A0

4. bg bundles unrelated device, network, geoloc= ation, and risk signals.

=C2=A0

Mike> It being silent makes it unique.

=C2=A0

5. sqa lacks a warning that security questions = are not acceptable authentication secrets under current NIST guidance.

=C2=A0

I have added this warning to the security consi= derations in the PR.

=C2=A0

draft-skyfire-oauth-id-verification-01

[Claude]

1. Duplicates verified_claims =E2=80=94 already= in the IANA JWT Claims registry, with time, assurance_level, and evidence = methods pipp/sripp/eid mapping almost one-to-one onto these values =E2=80= =94 and RFC 8485's vot (P =3D identity proofing). Neither is mentioned.

=C2=A0

Mike> This parallels the way that =E2=80= =9Camr=E2=80=9D values are used.=C2=A0 This is described in https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verification/p= ull/8.

=C2=A0

Mike> = The relationship to the OpenID IDA work is also described, as is the relati= onship to Vectors of Trust.

=C2=A0

2. Records the method but not the time, outcome= , verifier, or level, so it can't support the assurance decisions the s= iblings build on it.

=C2=A0

Mike> The PR describes that the "ivm&qu= ot; claim contains a set of identity verification methods that succeeded.

=C2=A0

3. One top-level array cannot scope to hid vs. = apd, both of which the base spec allows to be independently verified.

=C2=A0

Mike> This applies to =E2=80=9Chid=E2=80=9D.=

=C2=A0

4. Three different IANA field-name schemes acro= ss eight registrations (template says "Specification Document(s)"= ; six entries say "Reference"; two use the AMR registry's fie= ld names).

=C2=A0

Mike> Thanks =E2=80=93 corrected in the PR

=C2=A0

[GPT 5.6 Sol]

1. No verification result, time, assurance leve= l, trust framework, or evidence provenance.

=C2=A0

Mike> Same answer as above

=C2=A0

2. dbv, dbv1, and dbvm overlap; source count al= one does not establish assurance.

=C2=A0

Mike> Business people tell me that single an= d multiple and different from a compliance perspective.=C2=A0 Yes, the over= lap is expected - just as "hwk=E2=80=9D, =E2=80=9Cswk=E2=80=9D, and = =E2=80=9Cpop=E2=80=9D overlap.

=C2=A0

3. Evidence types (dig, phy) are mixed with cha= nnels or ceremonies (inp, vid).

=C2=A0

Mike> The same is true of =E2=80=9Camr=E2=80= =9D.=C2=A0 The vocabulary is intended to be expressive =E2=80=93 not mutual= ly exclusive.

=C2=A0

4. Methods are not bound to particular verified= attributes or entities.

=C2=A0

This applies to =E2=80=9Chid=E2=80=9D.

=C2=A0

5. The draft duplicates concepts already modele= d more completely by OpenID Identity Assurance.

=C2=A0

Mike> The relationship to OpenID Identity As= surance is now described.

=C2=A0

Have a nice day,

Best,

=C2=A0

_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
--00000000000032d6f7065f907a9c--