[OAUTH-WG] Re: Review of draft-skyfire-oauth-kyapay-*

[Ankit Agarwal <[e-mail]>]

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=https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/issues/23&source=gmail&ust=1794009644763000&sa=E
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=https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/issues/24&source=gmail&ust=1794009644763000&sa=E
- AML methods, normative references to vendor pages, and false, stale or
sensitive assertions:
https://www.google.com/url?q=https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/3&source=gmail&ust=1794009644763000&sa=E
https://www.google.com/url?q=https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/4&source=gmail&ust=1794009644763000&sa=E

Ankit


On Mon, Sep 21, 2026 08:19 AM, "Jean Diaconu (jdiaconu)" <[e-mail]>
wrote:

> Hello Mike,
>
> I did receive the message and the PR, thanks !!
> I'll check it asap.
>
> Best,
>
>
>
> *Jean Diaconu  *
> ------------------------------
> *De :* Michael Jones <[e-mail]>
> *Envoyé :* vendredi, septembre 18, 2026 8:50 PM
> *À :* Jean Diaconu (jdiaconu) <[e-mail]>; [e-mail] <
> [e-mail]>
> *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)' <jdiaconu=[e-mail]>;
> [e-mail]
> *Subject:* RE: [OAUTH-WG] Review of draft-skyfire-oauth-kyapay-*
>
>
>
> Many thanks for the useful reviews, Jean!  My replies are inline below,
> prefixed by “Mike>”.  You’ll find links to a number of PRs and issues filed
> as a result of your reviews, Jean.  Please review!
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Jean Diaconu (jdiaconu) <*jdiaconu=[e-mail]
> <jdiaconu=[e-mail]>*>
> *Sent:* Wednesday, September 9, 2026 2:07 AM
> *To:* *[e-mail] <[e-mail]>*
> *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"
>
> => 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/skyfire-xyz/draft-skyfire-oauth-kyapay-token/pull/49
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-kyapay-token/pull/49>*.
> Note that “aid” and “sti” are already designated as REQUIRED in the
> editor’s draft at *https://skyfire-xyz.github.io/draft-skyfire-oauth-using-kyapay-tokens/#go.draft-skyfire-oauth-using-kyapay-tokens.html
> <https://skyfire-xyz.github.io/draft-skyfire-oauth-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’ve opened *https://github.com/skyfire-xyz/draft-skyfire-oauth-kyapay-token/issues/50
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-kyapay-token/issues/50>* to
> track the need to improve the verifier description.
>
>
>
> Globally
>
> => Any thoughts about possible replay attacks
>
>
>
> Mike> Replay attacks can be detected using the “jti” claim.  I’ve added
> this to *PR #49
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-kyapay-token/pull/49>*.
> Also, short token lifetimes are recommended as a defense against replay.
>
>
>
> => 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 => what is the
> 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…
>
>
>
> *draft-skyfire-oauth-using-kyapay-tokens-00 (Human)*
>
>
>
> 1. Bots were unwelcome, and they remain unwelcome. => It depends, can
> we say "mostly unwelcome" ?
>
>
>
> See *https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/pull/5
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/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 are
> needed and when would they be needed?
>
>
>
> 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 ?
>
>
>
> Mike> Yes, there are situations in which it’s important to be able to have
> a Human in the Loop.  The KYAPay flows accommodate this.  “Human in the
> Loop” considerations sound more like they belong in the Using KYAPay 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) — two entirely
> undated, none definitional. FATF Recommendations / Glossary are the citable
> substitutes, and as informative references.
>
>
>
> Mike> I’ve filed *https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/3
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/3>* about
> this issue.
>
>
>
> 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.
>
>
>
> Mike> This parallels the way that “amr” values are used.  This is
> described in *https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/pull/5
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/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 only
> 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 ⊂ 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 “amr” values there are other values that are subsets.  For
> instance “hwk” ⊂ “pop”.  This isn’t necessarily a reason to remove the
> subset value if it’s useful in some cases in practice.
>
>
>
> [GPT 5.6 Sol]
>
> 1. Records that screening occurred, but not whether it passed, matched, or
> 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 “amr” values are
> used.
>
>
>
> 3. ofac, sanc, watch, and pep overlap without composition rules.
>
>
>
> Mike> “amr” values also sometimes overlap, which hasn’t hurt their
> applicability.  That said, suggestions for particular adjustments or
> refinements are welcome.
>
>
>
> 4. “OFAC Compliance” improperly implies a broad compliance conclusion.
>
>
>
> Mike> How should this description be improved?
>
>
>
> 5. Security/privacy sections do not address false, stale, or sensitive AML
> assertions.
>
>
>
> Mike> I’ve filed *https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/4
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-aml-methods/issues/4>* about
> this issue.
>
>
>
> *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.
>
>
>
> Mike> Security questions somewhat distinct from knowledge-based
> questions.  Not all codes are OTPs.  Liveness detection is the new feature
> in “facliv”.
>
>
>
> Mike> I agree that “call” is a dup of “tel”.  This is removed in *https://github.com/skyfire-xyz/draft-skyfire-oauth-amr-values/pull/7
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-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 “amr”, all the applicable values may be
> returned.
>
>
>
> 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.
>
>
>
> Mike> Renamed "psk" to "passkey" in the PR because of the potential
> confusion with pre-shared key.  Device-bound passkeys can be indicated
> using “hwk” and synced passkeys can be indicated using “swk”.
>
>
>
> 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-amr-values/issues/6
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-amr-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 “amr”, all the applicable values 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 — 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.
>
>
>
> Mike> This parallels the way that “amr” values are used.  This is
> described in *https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verification/pull/8
> <https://github.com/skyfire-xyz/draft-skyfire-oauth-id-verification/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 it
> 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 base
> spec allows to be independently verified.
>
>
>
> Mike> This applies to “hid”.
>
>
>
> 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 – 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”,
> “swk”, and “pop” overlap.
>
>
>
> 3. Evidence types (dig, phy) are mixed with channels or ceremonies (inp,
> vid).
>
>
>
> Mike> The same is true of “amr”.  The vocabulary is intended to be
> expressive – not mutually exclusive.
>
>
>
> 4. Methods are not bound to particular verified attributes or entities.
>
>
>
> This applies to “hid”.
>
>
>
> 5. The draft duplicates concepts already modeled more completely by OpenID
> Identity Assurance.
>
>
>
> Mike> The relationship to OpenID Identity Assurance is now described.
>
>
>
> Have a nice day,
>
> Best,
>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>