What is broken
The reference Guardian keeps a per-session hash chain and writes it to a log, but never puts chain_hash on a response. The README's ACS-Core table records this in the SessionContext row: "The Guardian keeps a hash chain per session and writes it to a log. It does not put chain_hash on any response."
Every other unimplemented row in that table has an issue behind it. system/ping is #129, the baseline HMAC signature is #70, replay protection is #140, and ask without ask_details is #141. The SessionContext row does not.
Where
reference-implementations/agt/packages/guardian/, response construction
What the specification says, and what happens instead
docs/spec/conformance.md puts "SessionContext + published chain head" in the ACS-Core mandatory list. response-envelope.json carries chain_hash on AcsResult and states the requirement directly:
The Guardian MUST include it on every response for a step where it wrote a ContextEntry, the content-bearing steps (Specification 8). Publishing the head on the wire lets an observer that records traffic detect a chain rewritten after the fact.
The Guardian computes the chain, writes it to a log, and withholds it from the wire. The sentence above names the exact property that is lost.
A consumer that wants to verify the audit chain has to read the Guardian's own log file. That works only for someone with filesystem access to the Guardian host, which is not the party the published chain head exists to serve.
Impact on implementers
The chain head is the one field that lets a party who is not the Guardian check that the audit chain is intact. Withholding it means no client, and no third party reading a client's records, can verify a session.
Combined with #125 (SessionContext hash does not follow the §8.2 construction) and #70 (nothing signs an envelope), the audit chain this tree produces cannot be verified by conformant tooling even if the chain head were published. The three are one defect surface and are worth sequencing together.
Current Priority Scope
Feeds the runnable Guardian reference implementation
What is broken
The reference Guardian keeps a per-session hash chain and writes it to a log, but never puts
chain_hashon a response. The README's ACS-Core table records this in the SessionContext row: "The Guardian keeps a hash chain per session and writes it to a log. It does not putchain_hashon any response."Every other unimplemented row in that table has an issue behind it.
system/pingis #129, the baseline HMAC signature is #70, replay protection is #140, andaskwithoutask_detailsis #141. The SessionContext row does not.Where
reference-implementations/agt/packages/guardian/, response constructionWhat the specification says, and what happens instead
docs/spec/conformance.mdputs "SessionContext + published chain head" in the ACS-Core mandatory list.response-envelope.jsoncarrieschain_hashonAcsResultand states the requirement directly:The Guardian computes the chain, writes it to a log, and withholds it from the wire. The sentence above names the exact property that is lost.
A consumer that wants to verify the audit chain has to read the Guardian's own log file. That works only for someone with filesystem access to the Guardian host, which is not the party the published chain head exists to serve.
Impact on implementers
The chain head is the one field that lets a party who is not the Guardian check that the audit chain is intact. Withholding it means no client, and no third party reading a client's records, can verify a session.
Combined with #125 (SessionContext hash does not follow the §8.2 construction) and #70 (nothing signs an envelope), the audit chain this tree produces cannot be verified by conformant tooling even if the chain head were published. The three are one defect surface and are worth sequencing together.
Current Priority Scope
Feeds the runnable Guardian reference implementation