coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Principal is the requesting party, not the approver

Browse source 
informed-decision asked whether its binding.principal and ours name the same
field, since both GH rulings said its slice canonicalizes "two of the five".
They do not: ours is the party on whose behalf the act is performed, taken from
the decision request's subject, while theirs is the approver — which appears
here only as an entry and never in binding. Only target overlaps.

Records the four-role distinction normatively in docs/approval-claim.md and
guards it with a test asserting the act digest is insensitive to the approver
while the approver stays recorded on the entry. Folding approver identity into
the digest would now break view_hash's assumption here rather than silently in
that repository.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QDzGbdDFnVJBxDgdp7RvpH

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2191554@bnt-lap001
Assistant-Session: d69bb7c3-b7b2-41c4-8287-6baef48c0993
This commit is contained in:
tegwick 2026-09-10 22:43:33 +02:00
parent 2fdb01d42a
commit a0a602976e
3 changed files with 81 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

27
docs/approval-claim.md
View file

@ -132,6 +132,33 @@ there is exactly one canonicalization of the act, computed here, referenced by
the presentation hash — and a mismatch is detectable rather than being two
independently correct answers about the same approval.
### `principal` is the party on whose behalf, not the approver
`informed-decision` asked (`principal_role_overlap`) whether this engine's
`binding.principal` and its own `binding.principal` name the same field, since
both rulings used the shorthand that its binding slice canonicalizes "two of the
five". **They are different roles, and the shorthand covered only one of them.**
| Field | Role | Shape |
| --- | --- | --- |
| `binding.principal` (here) | the party **on whose behalf** the act is performed — the requesting side, taken from the decision request's subject | scalar identifier |
| `binding.actor` (here) | the identity that may **use** the approval | scalar identifier |
| approver | the identity that **bound itself** to the act, with its verified `principal_type` and assurance | an entry, one per approver, never part of the binding |
| `binding.principal` (`informed-decision`) | the person **being bound** — the approver | party object |
Only `target` overlaps between the two binding slices. The approver does not
appear in this engine's binding at all, and therefore does not enter
`binding.digest`: two approvals of the same act bound by different people share
one digest. A presentation hash that must commit to *who was shown this* cannot
obtain that from our digest, so `view_hash` keeping its own approver field is
correct and is not a second canonicalization of the act.
`tests/test_claim_contract.py::test_approver_identity_is_not_in_the_act_digest`
asserts both halves: the digest is insensitive to the approver, and the approver
remains separately recorded on the entry. A future change that folded approver
identity into the digest would break `informed-decision`'s assumption here
rather than silently in that repository.
### Mapping from a flex-auth CheckRequest
| Claim binding | CheckRequest |