Module keyless 

Keyless-signed bodies, consumer side (RFC-ACDP-0021 §8, §11; 0.5.0 Draft).

KeylessPolicy says which registries this consumer accepts as attesters (§11). It exists in every build so that VerificationPolicy has one shape; the default accepts none, and without the keyless feature it is not consulted at all: a keyless key id then fails closed in VerifiedContext::fetch like any key the DID document does not list.

With the keyless feature, VerifiedContext runs §8.1 in place of RFC-ACDP-0001 §5.11 for a keyless key id, in this order (the first failure decides, and its reason token rides on the error, see KeylessReason::of):

1. the attestation, fetched from the serving registry by key_attestation.ctx_id, matches key_attestation.content_hash, is signed under its registry’s DID, carries a valid receipt and meets §5.3 (attestation_invalid);
2. the attesting registry is accepted (untrusted_attester);
3. agent_id, key_id and algorithm match it (attestation_mismatch);
4. the body’s receipt verifies, comes from the attester and names the attested fingerprint (unplaceable) — the receipt is required whatever ReceiptPolicy says, because it is the only time that places a keyless signature;
5. its created_at lies in the window (outside_attestation_window);
6. the signature verifies under the attested key (invalid_signature);
7. the attestation is not retracted (attestation_withdrawn);
8. RFC-ACDP-0014 revocations of the attested fingerprint, gathered by agent_id under RevocationPolicy (revoked, or pre-compromise);
9. the controller’s current DID document lists the identity (currently authorized), does not (historically authorized), or cannot be fetched (controller_unreachable, transient).

The outcome is one of the three existing KeyAuthorization values or an error.

Keyless-signed revocations (§9.3). Revocation discovery sets a candidate signed by a keyless key aside and verifies its signer by §8.1 steps 1–7 under this same KeylessPolicy. One under an org_wide attestation is producer-signed and applies; one under a non-org-wide attestation is only a hint (kl-005 G). One that cannot be evaluated (no keyless feature, an unaccepted attester, an attestation that does not verify) makes the verdict for the key it names unknown, never not-revoked.

Structs

KeylessPolicy

Which registries a consumer accepts as keyless attesters (§11).

KeylessTrust

The RFC-ACDP-0020 inputs for §11 trust-list acceptance: the pins’ §5.4 state at t (from TrustLists::select) and, when fetched, the attesting registry’s advertised profiles (C).