Add risk level change user-case to CAEP IOP by thomasdarimont · Pull Request #349 · openid/sharedsignals

thomasdarimont · 2026-08-18T17:24:37Z

During the public review period of the CAEP Interop profile we got the feedback that we should cover the Risk Level Change as a valid use-case for the CAEP Interop Profile.

Fixes #347

During the public review period of the CAEP Interop profile we got the feedback that we should cover the Risk Level Change as a valid use-case for the CAEP Interop Profile. Fixes openid#347

Follow-ups to openid#349, all confined to the section it added. - Defer the allowable values of current_level to CAEP rather than enumerating them inline. openid#330 proposes adding UNKNOWN to that enum, which would leave the profile carrying a stale list. The other fields in the section, and Sections 3.1-3.3, already defer to CAEP. - Use "Section 3.8.1" rather than the section sign. The document sets coding: us-ascii, so the section sign is transliterated and the published text currently renders as "1.0 S.3.8.1". - Strip trailing whitespace from three definition list terms, which kramdown would otherwise treat as line breaks. - Restore the trailing newline at end of file. No normative change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The CAEP Interop Profile added risk-level-change as a fourth qualifying use case (section 3.4, openid/sharedsignals#349), but the suite's hard-coded interop event list only knew the original three: a transmitter supporting only risk-level-change was failed, and one sending it got no payload validation at all. - risk-level-change joins CAEP_INTEROP_EVENT_TYPES (qualifying-use-case checks, per-subject event generation, format-coverage bookkeeping and the events the suite requests as a receiver all follow from the set) - new OIDSSFValidateCaepRiskLevelChangeEvent validates the CAEP 1.0 section 3.8 fields: principal (REQUIRED, open-ended per "or any other entity" - unknown values are logged, not rejected), current_level (REQUIRED, LOW/MEDIUM/HIGH), previous_level (OPTIONAL, same values; absence means unknown), risk_reason (string when present) - the interop reason_admin requirement (CAEPIOP 3.4) applies to it like the other use cases, and the emulated transmitter's example event now carries a reason_admin - summaries and messages list the fourth use case Closes #1961 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The current certification review period targets the published CAEP Interop Profile 1.0 draft-01, whose qualifying use cases are sections 3.1-3.3 (session-revoked, credential-change, device-compliance-change). risk-level-change exists only as section 3.4 of the working-group head (openid/sharedsignals#349) and is not part of the document under review, and real transmitter implementations largely do not support it yet. Split the event sets accordingly: the CAEP interop transmitter test now derives its REQUIRED events only from the qualifying trio, so a transmitter advertising risk-level-change (or any other CAEP type) is no longer forced to trigger it during the run - voluntarily delivered events are still fully validated against CAEP 1.0 Final 3.8, with the WG-head-only reason_admin requirement downgraded to a warning. The advertised-support and stream gates count only qualifying use cases, so risk-level-change alone no longer qualifies a stream on either side. Receiver support is unchanged: the emulated transmitter still advertises risk-level-change and generates it for receivers that request it. Generated-event anchors moved from the dangling CAEPIOP-3.4 to OIDCAEP-3.8, which resolves in the published CAEP 1.0 Final. Fold risk-level-change back into the qualifying set once the profile vote lands with section 3.4 included. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>