Suhas, Cullen — Thanks for posting this. It lands on a layer I've been working the other side of, so a note on how the two fit, one data point, and one question.
Your introduction's failure mode — a server changing tool descriptions after a client has approved them — is measurable in the wild. I run a daily scan of the public MCP ecosystem: in the Nov 1 scan (54,513 servers), we counted 1,509 listing swaps — servers changing what they serve under an identity clients had already approved. Your §8.2.5 consistency rules are the first client-side mechanism I've seen aimed squarely at it, for servers that adopt the card. The passport draft I posted the same week (draft-le-agent-passport-00) works the call-time side: a passport binding an agent's key to its accountable controller and a digest of its build, plus delegation receipts a relying party verifies step by step. SD-Card reads to me as the discovery-time complement — what an agent discloses, selectively, before anyone calls it — and I plan to cite it that way in -01. One question: the draft has no status or revocation mechanism, and cards can be long-lived. If a server's key is compromised or its metadata is withdrawn, expiry looks like the only kill switch. Is that a deliberate scoping choice for -00, or is a status mechanism planned? Happy to compare notes at 127. — Ben Le Redthread Security _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
