[SCITT] Re: Last Call: <draft-ietf-scitt-receipts-ccf-profile-04.txt> (CCF Profile for COSE Receipts) to Proposed Standard

[pki <[e-mail]>]

All,


I am evaluating this profile as the transparency-anchoring layer for
AIC-JWT (draft-wei-aic-jwt-00), a JOSE-based agent identity token whose
validation pipeline and audit records we implement in Go and in
browser WebCrypto. Three comments, one of which is a request for
clarification rather than a defect.


1. Binding a non-COSE statement to the receipt (interop). The profile
defines the verifiable data structure and the inclusion proof, but the
receipt's binding to the signed statement implicitly assumes a
COSE_Sign1 whose payload is the covered data. When the statement to be
anchored is a JOSE token (in our case a nested JWS with an inner
principal-signed DelegationAuthorization), there is no specified way to
reference or embed that statement so a verifier can recompute the leaf
deterministically. draft-noa-scitt-ai-agent-receipt-01 will profile
receipts for agent actions whose authority evidence may be JOSE. It
would help if the profile (or the receipt architecture it builds on)
stated whether the covered data is always the COSE payload bytes and,
if not, how a non-COSE statement is normalized before the leaf is
computed (e.g., a digest over the JWS compact serialization). Two
deployments computing different leaves for the same JOSE statement
would yield non-interoperable receipts -- the same class of problem as
the deterministic-encoding discussion on this list.


2. Single-transaction trees (supporting Iman's point). I agree with
the observation on the ccf-inclusion-proof path cardinality: a valid
inclusion proof for a single-transaction tree has an empty path, and
[* ccf-proof-element] matches the verification algorithm in Section
3.2. Please adopt that cardinality.


3. Evidence semantics vs current token validity (suggestion for
Security Considerations). A receipt is evidence of a past inclusion.
When the anchored statement is a short-lived agent token that has since
expired or been revoked via a status list, the receipt still proves the
past inclusion -- that is exactly the property agent accountability
needs, because the decision evidence outlives the token. One sentence
stating that receipt verification does not and must not depend on the
current validity of the anchored statement would prevent implementers
from accidentally coupling the two.


Happy to provide test vectors or run the profile against our Go and
WebCrypto implementations.


Best,
Jijie Wei