[Openid-specs-risc] openid/sharedsignals: New Issue opened

[github at oidf.org]

openid/sharedsignals event

Issue opened
Issue Title: CAEP Interop Profile: Event Subjects section does not permit Complex Subjects
https://github.com/openid/sharedsignals/issues/351

## Context CAEP Interoperability Profile 1.0 §2.5 (Event Subjects) requires support for three subject identifier formats from RFC 9493: * `email` * `iss_sub` * `opaque` (for the Verification event only) Receivers MUST accept any of these; Transmitters MUST be able to send at least one. The profile says nothing about Complex Subjects, which SSF 1.0 §3.3 defines as a Subject Member whose value is a JSON object with `"format": "complex"` and one or more named Simple Subject Members (`user`, `device`, `session`, `application`, `tenant`, `org_unit`, `group`, or others). A conforming Receiver is therefore not required to accept a Complex Subject at all, and a Transmitter that identifies subjects that way has no assurance a conforming Receiver will understand its events. ## Motivation This is not a hypothetical gap. **Device Compliance Change — Interop Profile §3.3, one of its own qualifying use cases — cannot be exercised as CAEP specifies it while staying inside §2.5.** CAEP 1.0 §3.5.2 gives exactly one example of `device-compliance-change`, and its subject is a Complex Subject: ```json "sub_id": { "format": "complex", "user": { "format": "iss_sub", "iss": "https://idp.example.com/123456789/", "sub": "jane.smith at example.com" }, "device": { "format": "opaque", "id": "123456789" } } ``` This is the natural shape for the event: device compliance is a property of a *device in the context of a user*, and a bare `email` or `iss_sub` cannot express which device changed state. But under §2.5 as written, a Receiver conforming to the profile is required to accept neither the `complex` wrapper nor an `opaque` identifier outside the Verification event. Auditing CAEP 1.0 for `"format": "complex"` in event examples: | CAEP event | complex examples | in the Interop Profile? | |---|---|---| | Session Revoked | 2 (incl. user + device + tenant) | yes — §3.1 | | Device Compliance Change | 1 (user `iss_sub` + device `opaque`) | yes — §3.3 | | Credential Change | 0 | yes — §3.2 | | Token Claims Change | 0 | no | | Assurance Level Change | 0 | no | | Session Established | 0 | no | | Session Presented | 0 | no | | Risk Level Change | 0 | no | So two of the three profiled use cases have complex-shaped examples in the specification the profile profiles, and neither is supported by §2.5. A further consequence: the `opaque` restriction is doing unintended work. Restricting `opaque` to the Verification event makes sense for a *simple* subject — an opaque identifier standing alone is not resolvable by a Receiver. That reasoning does not carry to a Complex Subject that also names the principal in a resolvable format, where `opaque` is the natural way to identify a device or session and the `user` member anchors the whole subject. ## Decisions for the WG ### 1. Normative language and scope Two independent axes: | | **Profile-wide (§2.5)** | **Per-event (§3.x)** | |---|---|---| | **MUST** | **(A)** Every Receiver must accept Complex Subjects. Closes the gap completely. Makes every existing conforming Receiver that does not parse `complex` non-conforming. | **(C)** Only Receivers implementing the use cases that need it. Smaller blast radius; arguably writes down what already had to be true. | | **MAY** | **(B)** Documents Complex Subjects as permitted, guarantees nothing. | **(D)** Weakest option; adds essentially nothing. | **Why MAY does not close the gap.** §2.5's existing structure is the standard interop asymmetry: Receivers MUST accept *any* listed format, Transmitters MUST send *at least one*. The Transmitter's "at least one" is only safe because the Receiver side is "any." Make the Receiver side MAY and a conforming Transmitter/Receiver pair can still fail to interoperate — which is the gap described above, now documented as permitted. SSF already allows Complex Subjects, so profile-silence and profile-MAY carry nearly the same normative content. **Suggested: (C), scoped to §3.1 and §3.3.** Credential Change needs nothing. In fairness to (A): at two of three use cases, (C) is close enough to a blanket MUST that the "narrow ask" argument is weaker than it first appears. Only a Credential-Change-only Receiver is exempt. ### 2. Where the requirement lives (C) raises a structural question. §3.1–§3.3 today constrain only event-specific *claims* (`change_type`, `current_status`, `reason_admin`). None of them say anything about subjects, so a per-event subject requirement would introduce a new kind of rule into §3. A cleaner drafting alternative keeps the conditional in §2.5, where subjects already live, and references the use cases from there — narrow scope without new structure. Written out in "Proposed text" below. ### 3. How much interpretation to require Separable from the MUST/MAY question. Two candidate bars: - **Full** — the Receiver must interpret all Subject Member names defined in SSF §3.3. - **Minimal** — the Receiver MUST NOT reject an event solely because its subject is complex, and MUST be able to extract the `user` member. Everything else may be ignored. Minimal is a substantially cheaper conformance bar and is likely sufficient for interoperability. Note SSF §3.3 permits member names beyond the seven it defines, so some form of "do not fail closed on unrecognized members" is needed either way. ### 4. The `opaque` carve-out Required under any option above, since CAEP §3.5.2 identifies the device as `opaque`. - **Scoped** — `opaque` allowed for any non-`user` member, provided the Complex Subject also carries an `email` or `iss_sub` member. Preserves the apparent original intent: the Receiver can always resolve the principal. - **Blanket** — drop the restriction inside Complex Subjects and rely on SSF §3.3.1. ## Proposed text Reflecting (C) + §2.5 placement + minimal interpretation + scoped `opaque`. Append to §2.5: > Receivers implementing Session Revocation / Logout (§3.1) or Device Compliance Change (§3.3) > MUST be prepared to accept events whose Subject Member is a Complex Subject, as defined in > §3.3. Other Receivers MAY. Transmitters MAY send Complex Subjects. > > Such Receivers MUST NOT reject an event solely because its Subject Member is a Complex > Subject, or because it carries a Subject Member name they do not recognize, and MUST be able > to extract the `user` Subject Member. > > Within a Complex Subject, the `opaque` format MAY be used for any Subject Member other than > `user`, provided the Complex Subject also contains at least one Subject Member using the > `email` or `iss_sub` format. > > Receivers MUST treat Subject Members absent from a Complex Subject as wildcards, per > §3.3.1. The wildcard clause is called out explicitly because it is easy to miss and fails silently when missed — a Receiver that reads an absent `device` member as "no device" rather than "any device" will mis-scope enforcement. ## Relationship to other issues Raised in the same discussion at the 2026-08-18 WG call as [#347](https://github.com/openid/sharedsignals/issues/347), but the two are independent and should be evaluated separately. #347 is additive: it widens the set of qualifying use cases in §3, and no existing conforming implementation is affected. This proposal changes an existing requirement that applies to Receivers regardless of the outcome of #347. [#348](https://github.com/openid/sharedsignals/issues/348) is adjacent: a Complex Subject with a `session` member may be a better answer to the session-correlation problem than extending `ext_id` to a complex type. That belongs in #348 rather than here — Session Established is not a profiled use case, so it is out of scope for the Interop Profile either way. Note that this is a normative change to a specification currently in its public review period for Final Specification approval. The WG should confirm with the OIDF whether a change of this kind can be made without restarting the review clock. ## Conformance suite impact Needs assessment from @thomasdarimont. The change would require the receiver test modules to emit at least one Complex Subject example (user + device, matching CAEP 1.0 §3.5.2) and the transmitter tests to accept them, but I have not verified how the existing subject-format tests in the suite are structured.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260825/89e792f6/attachment.htm>