Karl,
Keeping governance_record on the approval event works for me. The purchase
decisions then link to M17 from the receipt side.
For this integration I would make these required: approver and humanDisposed,
policyDigest, and argumentsCommitment in the decision receipt (Section 6.8),
and decisionDigest in the execution receipt (Section 3.7).
To name the Mission, -14 already has issuerAsserted.taskId, inside the signed
payload (Section 3.4). The issuer writes M17 there. A verifier checking it
against the Mission it expects gets bound, conflict or unsupported, and an
absent taskId means the issuer bound none.
A verifier holding BD-9001 then checks, in order: the signature; taskId bound
to M17; approver "policy" with humanDisposed false for an activation under
governed_policy; the commitment opened with PO-9001's arguments; and in the
execution record, decisionDigest equal to BD-9001's.
For the authority check the verifier needs one value from the Mission side.
policyDigest covers the issuer's whole decision state, including the policy it
loaded, and the issuer keeps that object so a third party can recompute the
digest (Section 6.8.3). If the Mission names the approved policy version by a
digest over the same JCS form, the verifier compares it with the policy inside
the decision state. A sketch from your side would show whether that holds.
Whether the approval itself was valid, and whether its authority still holds at
execution, stays with the Mission and the deployment, as you put it in 6.9.
Henri
Henri Sirkkavaara
Founder, Vaara
vaara.io | [email protected]
Helsinki, Finland
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
