Thanks, all. On Jiahui's question, I'd point to the particular decision event, with a separate reference to the governing policy. But we should be clear about which decision we mean.
In draft-mcguinness-oauth-mission <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html#record-provenance-members> , approval_event_id identifies the approval event that creates a Mission (under a standing-consent basis, the creation of that instance). The Approval Governance Record in draft-mcguinness-mission-approval-governance <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html#approval-policy> binds the governance evaluation to that event and names the governing policy by id, version and snapshot digest. That approval created the Mission, and it isn't necessarily the business decision behind a later action. A Mission to buy office supplies differs from the decision to place one order, and the draft's procurement example <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html#portable-binding-example> keeps them apart: linking the two requires separate action evidence. For the approval itself, recent changes in the editor's copies add a portable path. A Mandate <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html#claims> may carry approval_governance_digest alongside approval_event_id. When it does, a verifier relying on a presented record must match the digest and pass the portable approval-binding check <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html#portable-binding>. Success establishes agreement between the authenticated artifacts on the approval event and Mission anchors. It doesn't independently verify the retained Mission Record, re-check the governance evaluation, or establish approval of a later action. The record digest is built as Henri describes: SHA-256 over the record's JCS bytes with the signature included. It doesn't retrieve the record or establish trust in the issuer. I'd keep governance_record a boolean for now. When the record carries the Approval Context Commitment, which covers approval_basis, a record digest inside approval_basis would be circular. A format-independent reference is a separate question, and Henri's per-media-type preimage rule is a good start, but I'd want to work through a concrete second format first. Could we use the procurement or insurance example to pin down the business decision, its scope and timing, and the evidence a relying party needs? I think this will help us stay on the same page. -Karl On Fri, Oct 23, 2026 at 12:57 PM Henri Sirkkavaara <[email protected]> wrote: > Kieran, all, > > I agree with swapping the boolean for a typed digest. > > The type should name the record's media type, because each record kind > fixes its own preimage. The Approval Governance Record digest covers > the whole record with its envelope. A receipt under > draft-sirkkavaara-vaara-receipt-14 covers the signed receipt with > existenceProof removed (Section 3.6). The value itself can use the > form the Mission drafts already use, "sha-256:" and base64url, so a > verifier parses one encoding. > > Both records hash JCS bytes with the signature included, so a holder > can check the digest and the issuer's signature from the record alone. > > Henri Sirkkavaara > Founder, Vaara > vaara.io | [email protected] > > Red Hat Partner > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
