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" => 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) 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. Globally => Any thoughts about possible replay attacks => Maybe enrich the examples for the combinations KYA+PAY draft-skyfire-oauth-kyapay-token-exchange-01 (Human) 3.1 The scope becomes from "" to "openid profile email mcp => what is the logic behind this 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.) draft-skyfire-oauth-using-kyapay-tokens-00 (Human) 1. Bots were unwelcome, and they remain unwelcome. => It depends, can we say "mostly unwelcome" ? 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) 6.1 Maybe some precisions if there needs to be correlation between the tokens (like KYA and PAY) Globally => It feels that more or less we're good a proving provenance/delegation. Is it pertinent, at least for the most sensitive operations, to also include a HIL ? 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) — two entirely undated, none definitional. FATF Recommendations / Glossary are the citable substitutes, and as informative references. 2. Records that screening ran, never its result — no outcome, date, lists, or expiry — so no target can discharge an AML obligation from it, which is the stated motivation. 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 only safe reading of any value is adverse. Tipping-off rules (e.g. 4AMLD Art. 39) need analysis. 4. ofac ⊂ 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. [GPT 5.6 Sol] 1. Records that screening occurred, but not whether it passed, matched, or was inconclusive. 2. Missing subject, time, validity, jurisdiction, list/provider, and evidence identifier. 3. ofac, sanc, watch, and pep overlap without composition rules. 4. “OFAC Compliance” improperly implies a broad compliance conclusion. 5. Security/privacy sections do not address false, stale, or sensitive AML assertions. draft-skyfire-oauth-amr-values-01 [Claude] 1. Four of ten duplicate already-registered values: sqa⊂kba, code≈otp, call≈tel, facliv/face — against the registry's own review criterion. 2. email, code, and url overlap each other with no composition rules; email is literally defined as the union of the other two. 3. psk means pre-shared key throughout the IETF (TLS-PSK, IKEv2, EAP-PSK). Rename; and the distinction worth conveying — device-bound vs. synced passkey — can't be expressed by one flat value. 4. Every description is unsourced, a regression from RFC 8176, which anchored all 21 values in external definitions. [GPT 5.6 Sol] 1. call duplicates existing tel; sqa overlaps kba; code overlaps otp. 2. Values mix channels and products (email, app) with actual authentication methods. 3. No composition rules for combinations such as email + code or passkey + biometric. 4. bg bundles unrelated device, network, geolocation, and risk signals. 5. sqa lacks a warning that security questions are not acceptable authentication secrets under current NIST guidance. draft-skyfire-oauth-id-verification-01 [Claude] 1. Duplicates verified_claims — 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 — and RFC 8485's vot (P = identity proofing). Neither is mentioned. 2. Records the method but not the time, outcome, verifier, or level, so it can't support the assurance decisions the siblings build on it. 3. One top-level array cannot scope to hid vs. apd, both of which the base spec allows to be independently verified. 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). [GPT 5.6 Sol] 1. No verification result, time, assurance level, trust framework, or evidence provenance. 2. dbv, dbv1, and dbvm overlap; source count alone does not establish assurance. 3. Evidence types (dig, phy) are mixed with channels or ceremonies (inp, vid). 4. Methods are not bound to particular verified attributes or entities. 5. The draft duplicates concepts already modeled more completely by OpenID Identity Assurance. Have a nice day, Best,
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
