aeoess-aps: revocation mapping, two TRACE surfaces, three questions

[aeoess]

Follow-up to #46 as promised: revocation for the aeoess-aps exporter.

I retested the exporter against the current trace first (#139 carries tested_against: agentrust-trace 0.9.0). Then I mapped APS revocation against TRACE, and it splits into two surfaces that I've kept separate on purpose.

Surface 1, released. agentrust-trace 0.9.0 (newest on PyPI) ships no revocation schema. Its executable revocation path is the RevocationStore consulted by verify_record(): a membership test on the record-signing key's RFC 7638 thumbprint or kid, fail-closed on error, absence accepts. I ran it against an APS key: empty store accepts, listed kid rejects, raising store rejects.

Surface 2, current main at 738358d, untagged. schema/trace-revocation.json and schema/trace-revocation-bundle.json (landed 2026-08-19, in no release). A TraceRevocation/1.0 statement withdraws a record-signing key from a log entry onward; required fields are type, compromised_key_id, last_valid_entry_id, log_id, revocation_key_id, sig, with additionalProperties: false. I reproduced the schema shape and its rejections with jsonschema 4.26.0 (omitting any of the three id fields, empty string, null, and an extra property are all rejected). docs/verification.md says the store does not yet do entry-id-scoped revocation, so nothing executes this statement today.

What APS revocation is. A delegation revocation withdraws a delegationId; a principal-binding revocation withdraws a binding_id. Neither names a record-signing key and neither asserts a compromise. revokedBy is the key that signed the revocation, not the key being withdrawn. This exporter also emits unsigned records with transparency: none, so it has no key in any store and no log position.

Mapping.

Surface 1 (0.9.0 store): no_mapping for all three APS artifacts. TRACE revokes a key; APS withdraws an authority; and there is no record-signing key on this integration's records to enter. Divergence to keep in view: an empty store accepts and an omitted store skips the check, while APS treats "no artifacts observed" as no evidence, not as not revoked.

Surface 2 (main, prospective only):

TRACE field	APS source	result
type	none, emitter constant	not APS-derived
compromised_key_id	none	no_mapping, blocking. APS withdraws an authority and asserts no compromise; revokedBy is the signer and must never land here
last_valid_entry_id	none	no_mapping, blocking (no log position)
log_id	none	no_mapping, blocking (transparency none)
revocation_key_id	none	no_mapping, blocking (names the key that signs the TRACE statement; the exporter holds none)
sig	none	no_mapping, blocking (different preimage; no signing contract)
revoked_after_entry	none	optional, omitted
revoked_at	revokedAt / revoked_at	partial: converted to Unix seconds; informational in TRACE
reason	reason / reason_code	partial: delegation reason carries; binding reason_code renders as text, code semantics lost
(none)	affected_scope, revocation ids, artifact digest	no_mapping, no slot
bundle	SignedRevocationObservation	no_mapping: closest role analogue, but an observation cannot construct a bundle

So: no valid TraceRevocation/1.0 statement can be emitted from this integration today, and no store entry should be manufactured from an APS revocation. That's why this is an issue and not a PR.

Three questions:

1. Which basis should the APS integration use for revocation? The integration currently pins agentrust-trace 0.9.0, whose executable revocation surface is the key-level RevocationStore. Current main also has TraceRevocation/1.0 and its bundle, but the verifier documentation says entry-id-scoped revocation is not implemented yet. Should the integration describe released 0.9.0 only, or is a separate prospective mapping against current main useful now?
2. Authority revocation versus key revocation. APS revokes a delegation or principal binding. Neither artifact asserts that an associated record-signing key is compromised or globally revoked. My mapping therefore marks both RevocationStore membership and compromised_key_id as no_mapping. Is that the intended boundary on the TRACE side?
3. Constructing a current-main statement. The APS exporter has no TRACE log_id / entry boundary and no agreed key that would sign a TraceRevocation/1.0 statement. My reading is that it should emit no revocation statement today, while recording the fields that do map (revoked_at, reason) and the required gaps. Is that the right interpretation?

Whatever you answer, I'll update the exporter's mapping doc accordingly and keep tested_against honest. The APS-side revocation verification these artifacts come from is aeoess/agent-passport-system#123.

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	LOW
Overall	HIGH

Automated check by AgenTrust Contributor Check.

[solloek369-arch]

One existing maintainer ruling may help narrow questions 2 and 3.

The maintainer response on cA2A #129 separates two verifier questions that seem directly relevant here: whether authority/evidence was valid under the state that existed at the time, and whether that authority is still applicable now. Those answers can diverge without making the historical evidence cryptographically invalid.

I rechecked current TRACE main as well. TraceRevocation/1.0 is still specifically a withdrawal of a record-signing key, and compromised_key_id identifies that key.

That seems to support the boundary this mapping has found. An APS delegation or principal-binding revocation can change the present applicability of authority without asserting compromise or revocation of the TRACE record-signing key, and without retroactively invalidating the historical authority evidence on that basis alone.

On that reading, no_mapping to both the released RevocationStore and current-main TraceRevocation.compromised_key_id is not necessarily a missing implementation. It may be the correct claim boundary: mapping either one would collapse authority applicability into signing-key revocation and assert something the APS artifact does not say.

Likewise, emitting no TraceRevocation/1.0 statement from the APS artifact alone seems safer than manufacturing the missing key/log/signing semantics.

One related ceiling I would preserve: absence of an observed APS revocation establishes only that no such revocation was established from the evidence evaluated; it does not by itself prove that the authority remains presently applicable.

Just offering the existing cA2A distinction as a donor for the mapping decision. Not proposing where an APS revocation artifact should live or what applicability vocabulary a consumer should use.

[imran-siddique]

Sorry for the delay, and thank you for the shape of this. Retesting against the release before mapping, pinning main at 738358d rather than saying "main", and opening with what does not map is the reason I can answer the questions rather than re-derive the situation first.

Three answers, then two things you could not have known.

1. Which basis: both, because they are not two surfaces

Describe released 0.9.0 as the operative behaviour and the entry-scoped statement as the same rule at a higher level of evidence. Not as a prospective replacement.

docs/verification.md is explicit that the key-level store is §3.2.3's own fallback, not a legacy mechanism:

A record with no usable inclusion entry ID has no anchor to place it before or after the compromise, so §3.2.3 falls back to binary revocation for it: "a verifier MUST reject every record signed by the revoked key". That fallback is what the current verify_record() store implements, and it is the correct behaviour for deployments carrying no receipts.

So RevocationStore membership and TraceRevocation/1.0 are one mechanism degrading gracefully: entry-ID-scoped where there is an inclusion proof, binary on the key where there is not. Your instinct to keep the two columns separate is right for tested_against honesty and wrong for the framing above them. I would keep the columns and change the heading.

2. Authority revocation versus key revocation: yes, that is the boundary

Confirmed, and no_mapping on both RevocationStore membership and compromised_key_id is correct. TRACE revokes a record-signing key and asserts compromise. APS withdraws an authority and asserts nothing about a key. revokedBy must never land in compromised_key_id, and I am glad you said so explicitly, because that is the substitution someone will eventually make on the grounds that both fields hold a key identifier.

One thing to add to your reasoning, which strengthens it. This exporter emits unsigned records with transparency: none, so it has no record-signing key and no log position. Under §3.2.3's fallback above, a record with no inclusion entry ID is revoked binarily on its signing key, and these records have none. So the no_mapping is not a gap in your mapping to be closed later. It is a property of the record class: an unsigned record with no transparency has no revocation surface at all, by construction. Worth stating that way in the doc, so nobody reads the row as pending work.

3. Emit nothing today: yes

Your reading is right. Record revoked_at and reason as partial, record the blocking gaps, emit no TraceRevocation/1.0 statement and manufacture no store entry. Filing this as an issue rather than a PR was the right call for exactly the reason you give.

The divergence you found is the best thing in this report, and our own spec agrees with you

You wrote:

an empty store accepts and an omitted store skips the check, while APS treats "no artifacts observed" as no evidence, not as not revoked

APS is right and we are inconsistent with ourselves. §3.2.3 takes the APS position at the bundle level:

a verifier with no bundle "MUST report that it performed no revocation check"

and an expired bundle "MUST report the record as unverified for revocation rather than as verified". Absence of evidence is reported as absence, not promoted to a pass. But the store path does the opposite: an empty store accepts, silently. Same question, two answers, in one specification.

I am filing that separately against trace-spec rather than asking you to carry it. Nothing changes in your mapping; you should keep the divergence noted exactly as you wrote it, because it is now a known defect on our side rather than an APS-versus-TRACE difference.

The surface you tested changed a few hours ago

trace-spec#236 merged today, and one of its nine fixes lands on the path you exercised. RevocationStore is Callable[[str], bool] and _check_not_revoked read the return by truthiness, so None, "", 0 and [] all read as "not revoked". None is what a CRL, status or SCITT lookup returns when its author handled the 200 and forgot the rest, which is the outage the existing except clause was written to survive.

You tested that an empty store accepts, a listed kid rejects, and a raising store rejects. All three still hold. A store returning None would have silently accepted on 0.9.0 and now fails closed on main:

A callable that returns a non-bool has also not determined anything, and is treated the same way.

Unreleased, so 0.9.0 still has the old behaviour and your tested_against: agentrust-trace 0.9.0 remains accurate. Worth a re-run when it ships.

[aeoess]

Thank you, all three land. Doc changes on my side, one PR against integrations/aeoess-aps: heading over the two revocation columns rewritten to one mechanism degrading gracefully, columns kept as they are; the no_mapping rows restated as a property of the record class: unsigned with transparency: none, so no revocation surface by construction, not pending work; the empty-store observation kept with a pointer to your trace-spec issue once it has a number; and a line under tested_against that #236 changes the store path's non-bool handling, unreleased, with a re-run on the release that carries it.

Nothing emitted, no store entry. I'll link the PR here.

[aeoess]

Mapping PR opened: #149. It records one TRACE mechanism at two levels of evidence for revocation, adds the tested_against note, and fills the trace-spec#246 pointer. Nothing is emitted on the APS side that TRACE does not define.

[imran-siddique]

Closed by #149, which lands the mapping under the ruling above. The store-accepts-on-absence divergence you found is tracked separately as agentrust-io/trace-spec#246.