Hi Iman, Thanks, this is a good catch and I agree. Identity, delegated authority, and request authorization are three separate things, and the wording should keep them apart. I made the two surgical changes you suggested to the hid sentence: "asserts" to "can carry" (aid REQUIRED, apd OPTIONAL, hid conditional), and "authorizing human principal" to "identified principal the issuer asserts the agent acts for.”
Revised paragraph: KYAPay tokens replace network-level inference with un-forgeable, issuer-signed assertions. Signed by a trusted issuer and verified against public keys, the token can carry the agent instance (aid), the execution platform (apd), and the identified principal the issuer asserts the agent acts for (hid). Where network indicators only establish that a request comes from a known operator's network, a KYAPay token establishes that a specific agent is acting for a specific, verified subscriber. Pushed the changes. Thanks, Srini From: Iman Schrock <[email protected]> Date: Wednesday, September 23, 2026 at 1:08 AM To: [email protected] <[email protected]> Subject: [OAUTH-WG] Re: draft-skyfire-oauth-using-kyapay-tokens: Introduction rewrite (PR #6) This Message Is From an External Sender This message came from outside your organization. Hi Srini, This is a useful improvement. I especially agree with separating identification from admission. One phrase may still collapse two different facts. hid, aid, and apd identify the principal, agent, and platform under the issuer’s assertions; they do not by themselves say what authority the principal delegated or establish that the principal authorized this exact request. aud, tdm, and tsi bind the intended recipient, and, where used, cnf plus a request signature binds the presenter to the request. Those are still different from human authorization of the action. Would you consider changing “authorizing human principal” to “identified principal on whose behalf the issuer asserts the agent acts,” and adding one sentence that delegated authority and request or action authorization remain separate inputs to the site’s admission policy? Also, since apd is optional and hid is conditional in the token draft, “can carry” may be more accurate than saying every token asserts all three. Best, Iman On Wed, 23 Sep 2026 04:54:27 +0000, "Thumma, Srini" <[email protected]<mailto:[email protected]>> wrote: Hi all, I've opened a PR against draft-skyfire-oauth-using-kyapay-tokens that rewrites the Introduction: https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/pull/6<https://urldefense.com/v3/__https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-tokens/pull/6__;!!GjvTz_vk!U3koDVyAhZVGcxSIUnJIW8NIBZYrm2kJJeR6kenIaegxRI4bEzIRVZTaGcGCoAXOuXdjM0OVRrOuWbeyV4yIOxM6RZu9Ew$> The rewrite frames KYAPay tokens as the cryptographic successor to the network metadata (IP ranges, ASNs, User-Agent strings) that intermediaries already use to identify verified bots and apply configured policies. It makes explicit what the token asserts — the agent instance (aid), the execution platform (apd), and the authorizing human principal (hid) — and the design goal that identification is distinct from admission: the token is authenticated context for a site's policy engine, not an automatic pass. Review and comments on the PR are welcome. Thanks, Srini
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
