[Openid-specs-risc] [Public review] CAEP Interoperability Profile 1.0 draft 01 — §3.1 should require event_timestamp on session-revoked

[Anton Sokolov]

Hi all,

One comment on CAEP Interoperability Profile 1.0 draft 01, for the review
closing
25 September 2026.

For an implementation supporting the Session Revocation / Logout use case,
the
profile requires a reason_admin object but nothing stating when the
revocation
occurred, so a conformant session-revoked event cannot be positioned
against the
Receiver's session state.

Section 3.1 reads in full:

"In order to support session revocation or logout, implementations MUST
support
the CAEP event type `session-revoked`. The `reason_admin` field of the event
MUST be populated with a non-empty object."

"iat" is REQUIRED by [RFC8417] Section 2.2, but it records when the SET was
issued, not when the revocation took effect — CAEP's Section 3.1 examples
place
the two 168 seconds apart. The claim carrying revocation time,
event_timestamp,
is OPTIONAL in [CAEP] Section 2 and constrained only conditionally in
Section
3.1.1.

Scenario. A Transmitter revokes Alice's session at T; delivery is queued
(poll
interval, or push retry); Alice re-authenticates at T+30s; the event
arrives at
T+60s with sub_id {"format": "email"}. Section 2.5 requires support for
email,
iss_sub and opaque (Verification event only) — no session-scoped subject is
guaranteed, and Transmitters need send only one of the three. The Receiver
has a
principal and nothing else: one implementation drops Alice's new session,
another
keeps it, and both conform.

[RFC8417] is a normative reference here and speaks to this directly.
Section 5.3
says that where an event "conveys a logged in or logged out status for a
user
subject, then order becomes important", and places an obligation on
documents in
exactly this position: "Specifications profiling SET SHOULD define a
mechanism for
detecting order or sequence of events when the order matters." Section 5.4
offers
two concrete remedies — "revoke a specific session or ID Token rather than a
general logout statement about a 'user'", or "timestamps that allow new
sessions
to be started immediately after a stated logout event time". Draft 01
guarantees
neither, and its Security Considerations state that "There are no additional
security considerations that arise from this document."

Proposed addition to Section 3.1, in the style of the existing sentence:

"The `event_timestamp` field of the event MUST be populated, and its value
MUST
represent the time at which the session revocation occurred."

It is wire-observable, certifiable, and already present in all three [CAEP]
Section 3.1 examples. If the working group prefers to leave it optional,
could the
Security Considerations say what a Receiver should do with a
session-revoked event
older than the session it matches? Certification tests will otherwise
assume an
answer.

Best regards,

Anton Sokolov
Tyche Institute, Tallinn, Estonia
Affiliation given for identification only; this comment is my own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260814/a8784037/attachment.htm>