Karl, all,
In your procurement example, BD-9001 could be a receipt under
draft-sirkkavaara-vaara-receipt-14, with PO-9001 as the call it
decided. The issuer signs the verdict and can record who disposed of
it, "human" or "policy", plus a flag that is true only when a person
acted on this decision. A replayed earlier approval does not set it.
The record names the call and commits to its arguments with a fresh
salt per decision. The holder opens the commitment with the order's
arguments, and that opens this decision and no other. The execution
record can carry the digest of the decision it answers, so an outcome
cannot be attached to a different decision about the same call.
decidedAt is the issuer's clock. A relying party that needs time it
does not take from the ERP checks an RFC 3161 token over the signed
receipt, which shows the receipt existed no later than that time. The
state the decision was made under travels as a digest of the issuer's
decision state, which includes the policy it loaded.
The relying party checks the signature, the evidence digest, the opened
commitment and the decision digest in the execution record. The record
says nothing about whether M17's approval was valid or the policy
sound. The disposition, the policy digest and the decision digest are
optional members in -14, so the example needs an issuer that writes
them. Member names are in Sections 3.7, 5 and 6.8.
Cliff's standing check is outside -14 too. The receipt records who
disposed of the decision at the time it was made. Section 10 says a
signature that verifies tells a consumer nothing about the signing key
now, and the same holds for the approver: whether they still hold the
role on 12 Nov is checked by the deployment at use, against its own
records. The receipt does not carry that.
Henri Sirkkavaara
Founder, Vaara
vaara.io | [email protected]
Helsinki, Finland
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
