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" <sthumma= [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 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]
