RFC 0111: Decision attestation fields (decision_id, policy_set_hash)

[tomjwxf]

Summary

Add two optional fields to Cedar's AuthorizationResponse so downstream systems can bind a decision to (a) a stable identifier and (b) the exact policy set that produced it.

• decision_id: Option<Uuid> — UUID v7 (time-ordered)
• policy_set_hash: Option<String> — SHA-256 over the JCS-canonical policy set

Both additive, both optional, zero breaking changes. Opt-in via a request-level config field so existing callers see identical behavior.

Motivation

Cedar is increasingly used as the policy layer for systems that maintain persistent audit trails: agent-governance toolkits, compliance frameworks, signed-receipt emitters, transparency-log anchors, and multi-tenant authorization services. Every downstream system needs to answer two questions that are currently hard:

1. "Is this the same decision we saw before?" Without a canonical decision_id, every downstream system generates its own identifier. Fragmentation: two systems that need to cross-reference the same decision cannot do so without a side-channel mapping.

2. "Which policies produced this decision?" Without a canonical policy_set_hash, a consumer cannot attribute a past decision to a specific policy version once policies have rotated.

Today, downstream systems work around the gap by generating their own UUIDs (in incompatible formats) and recomputing policy digests externally (duplicating Cedar's internal state). Both are less reliable than a field on the response produced at the point of evaluation.

Scope boundary

This RFC sits within the language-layer scope Cedar owns. It does not cross the scope boundary established in cedar-policy/cedar-for-agents#76, which redirected domain schemas to community venues. Decision attestation fields are general-purpose infrastructure useful to any Cedar consumer, not specific to agent governance.

Follows the design vocabulary precedents in RFCs #58 (Cedar standard library) and #69 (Schema libraries) where they apply.

Rendered

See text/0111-decision-attestation.md for the full RFC text.

Open questions

Four design points flagged in the "Open questions" section of the RFC:

1. UUID version (v7 vs v4)
2. Canonicalization rules for policy_set_hash
3. Opt-in mechanism (request-config vs authorizer-config)
4. Whether to include schema hash alongside policy hash

Happy to iterate based on team preferences on any of these.

[victornicolet]

I am not sure this is something the Cedar maintainers want to consider because this seems peripheral to the policy and authorization problem.
Can you provide more details on why currently the Cedar library is not sufficient for your use case?
The library client that calls the authorization API can wrap the authorization decision with the information it requires, and compute a hash of the policy set before it passes it to the authorization call.

[tomjwxf]

Thanks @victornicolet, fair question.

The Cedar library works for making the authorization decision. The opportunity is not policy evaluation itself, it is making the decision independently referable after the fact.

A client can wrap the decision today, but without a shared field shape every downstream audit/logging system invents its own names for decision id, policy-set hash, request hash, and evaluation context. The RFC is meant to standardize the minimum portable metadata around a Cedar decision, not move receipt signing or audit storage into Cedar core.

If you would prefer this outside Cedar RFC scope, I can narrow the proposal to an external integration profile that documents the wrapper pattern rather than asking Cedar to carry the fields directly.

Best,
Tom

P.S. sorry for delayed response, I've been travelling.