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)' <[email protected]>;
[email protected]
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)
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, September 9, 2026 2:07 AM
To: [email protected]<mailto:[email protected]>
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,
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
