A KYAPay proposal is not an endorsed identity standard
KYAPay's old profile has an active successor. That matters—but an individual Internet-Draft still does not establish IETF endorsement or prove that two implementations interoperate.
The expired document is not the end of the KYAPay story. The older profile's Datatracker record points to a replacement: the KYAPay Token proposal. Stop at the first status badge and you can mistake a document handoff for an abandoned design.
The opposite mistake is just as expensive. A proposal appearing on an IETF website does not make it an endorsed interoperability standard. For a merchant choosing an agent-identity integration, both distinctions belong in the buying decision.
The July 19, 2026 revision of KYAPay Token is an individual Internet-Draft by Ankit Agarwal and Michael B. Jones. Its record identifies it as active and says it is not endorsed by the IETF. The text describes JWT-based agent identity and payment tokens intended to support interoperability between vendors. That is the design goal, not a report of a successful cross-vendor deployment.
Read the status before buying the promise
My rule is to keep three separate entries in an integration review: the specification being implemented, its standards-process status and the interoperability actually demonstrated. A team should be able to answer each without substituting the other two.
The draft's intended Standards Track destination is an ambition within the document. It is not evidence that the work has already reached that destination. Equally, submitting an individual draft is a legitimate way to put engineering work into public discussion. The status is a reason to scope the commitment, not a reason to dismiss the authors.
I would ask a vendor for the exact revision it implements. Then ask which other implementation has exchanged tokens with it, what was tested and where the failures are recorded. A shared acronym cannot answer those questions. Neither can two teams separately saying they support the same proposal.
Make the migration question part of the purchase
As an illustration, imagine a merchant integrating an agent-identity token at checkout. The acceptance test should cover more than a token arriving successfully. I would include an unfamiliar issuer, an expired credential and a changed claim that the merchant's policy does not understand. Those are proposed tests, not results from a KYAPay implementation I have run.
The commercial question follows the technical one: who changes the integration when the draft changes? Ask which version remains supported, how incompatible changes are announced and how the merchant can withdraw trust without rebuilding checkout under pressure.
That makes an early integration an explicit bet. The team may reasonably choose a useful proposal before standardisation finishes. What it should not do is buy it on the assumption that future portability has already been settled.
I would keep the initial adapter small and the merchant's acceptance policy separate from vendor-specific token parsing. That is a proposed way to contain migration work, not a guarantee that changing providers becomes free. Identity trust, operational support and business agreements can remain separate dependencies.
Demand evidence at the right layer
The useful outcome of checking Datatracker is not a red or green verdict on Skyfire. It is a more accurate integration brief: a named proposal, a specific revision and a list of compatibility claims that still need evidence.
Do not call the replacement dead because its predecessor expired. Do not call it an endorsed standard because the draft exists. Both shortcuts turn a procedural fact into a product conclusion it cannot carry.
Adopt a proposal deliberately. Buy interoperability only against evidence of the implementations you will actually connect.
