Why SHA-256 and not keccak
The identifier has to be checkable by somebody who installs nothing.
Claims are files. The person most worth convincing is not an Ethereum developer, it is whoever inside an administration or a law firm has been handed this and asked whether it is real.
That person has a shell. They have shasum and they very likely have jq. Giving them a one line command that reproduces the identifier on their own machine is worth more than any amount of explanation, because they can check the claim without trusting the explainer.
Keccak would mean a library, a package manager and a decision about whether to trust the package. For an identifier whose whole job is to be independently reproducible, that is the wrong trade.
So the document identifier is SHA-256 over the canonical bytes, and keccak stays where it belongs: EIP-712 signing and the optional anchor contract, both of which already assume an Ethereum toolchain. Mixing the two is deliberate, not an oversight. The verify page runs both halves in the browser and prints the shell equivalent beside the result.