Public keys for execution grants and claim attestations
The Ed25519 public keys, as a JWKS, that sign execution grants and
claim attestations. A deploy target or a downstream system of record
verifies either offline against this set; during a signing-key
rotation the previous key stays listed until the grants signed with
it have drained. The kid in a token's protected header names the
key to use.
Response Body
application/json
application/json
curl -X GET "https://example.com/.well-known/decionis-execution-grant-jwks.json"{ "keys": [ { "kty": "OKP", "crv": "Ed25519", "x": "string", "kid": "string", "alg": "EdDSA", "use": "sig" } ]}Revalidate and atomically claim one execution-bound authorization POST
Deprecated alias of `POST /v1/authority/grants/{grantId}/claims`: the same handler. Required immediately before the downstream commit. Verifies the dossier signature and complete execution binding, resolves current policy, signal, and Presence state, then atomically claims the nonce and mutable concurrency scope. Execution is authorized only when `should_execute` is `true`, `claim_token` is non-null, and `claim_lease_expires_at` is still live at the downstream boundary. `valid` alone is diagnostic; in SHADOW it may describe hypothetical validity without execution authority. A live claim also returns `claim_attestation`: a compact EdDSA JWS, signed with the execution-grant key, that a downstream system of record can verify offline against `/.well-known/decionis-execution-grant-jwks.json`. It names the grant, the decision, the dossier, the binding the grant carried (intent hash, canonical payload digest and its profile, expected effect digest, nonce, correlation), a digest of the claim token, and an expiry equal to the claim lease. The executor forwards it with the downstream request; the provider checks that the request it received is the one the attestation describes. See `ClaimAttestationClaims`.
Finalize a claimed downstream commit attempt POST
Deprecated alias of `POST /v1/authority/grants/{grantId}/receipts`: the same handler. Records COMMITTED, FAILED, or INDETERMINATE. INDETERMINATE effects must be reconciled and are never safe for automatic retry. A COMMITTED claim proves an attempt was finalized, but an effect is confirmed only when digest-bound `effect_evidence` with status CONFIRMED is accepted. If the signed grant expires after a successful claim, finalization may continue only while the exact persisted claim token, nonce, correlation, and database claim lease remain valid. An expired unclaimed grant is never execution-eligible. A finalize request at or after the database-clock lease boundary fails closed and atomically records the claim as INDETERMINATE. A verifying provider's signed effect receipt (Verifying Provider Profile, VP-3) may accompany the finalization as `effect_receipt`. It is verified against the organisation's registered provider keys and recorded in the commit evidence as presented, verified or not; it is never a reason to refuse the finalization. When the grant named the effect it expected and the verified receipt carries an effect digest, the receipt is also read as `SIGNED_RECEIPT` effect evidence, and confirms the effect only when the digests agree and the outcome is COMMITTED. An explicit `effect_evidence` takes precedence.