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

["Jean Diaconu (jdiaconu)" <[e-mail]>]

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]<mailto:jdiaconu=[e-mail]>>
Sent: Wednesday, September 9, 2026 2:07 AM
To: [e-mail]<mailto:[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.  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.

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 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.

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 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.

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 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.

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 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.

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,