# WG Meeting: 2026-02-03
## Agenda
- Status endpoint interop requirement (Issue [318](https://github.com/openid/sharedsignals/issues/318))
- Other open issues for certification ([319](https://github.com/openid/sharedsignals/issues/319), [308](https://github.com/openid/sharedsignals/issues/308))
- Proposal for receiver getting point-in-time signal status
- For Review: Add Receiver requirements to CAEP Interop Profile https://github.com/openid/sharedsignals/pull/315
- Questions / remark from the FOSDEM presentation:
- Currently, session revoked, etc. focus on one user identifier. How can a Transmitter tell a receiver to sign out a whole org?
- The event IDs are quite long, are there any plans to have short hands / short-codes to indicate event types, so that the JWTs are more compact.

## Attendees
- Atul Tulshibagwale (SGNL)
- John Marchesini (Jamf)
- Sachin Mamoru (Gapstars | OKRA.ai)
- Kenn Chong (RSA)
- George Fletcher (Practical Identity)
- Mike Kiser (SailPoint)
- Aaron Parecki (Okta)
- Luiky (?)
- Yair Sarig (Omnissa)
- Tushar Raibhandare (Google)
- Thomas Darimont (OIDF)
- Sean O'Dell (CVS)

## Notes
### Unblocking Thomas / Certification - Especially the status endpoint
* (Atul) From Jan 20th, there is still ongoing discussion around the issue
* (Yair) there are two elements: the get and the post. I think that the consesus was that get was needed, but post was not as crucial
* (Atul) Asks if this alighnment works. . .
* (Tushar) Our plan is to implement a live status (not in prod yet, so may change in the future). We can work with only having get (will require some modification, but will work)
* (Aaron) The moset recent comments are current, I belive
* (Atul) So let's move forward with that approach and mark this as resovled
* (Thomas) We'll need to update the conformance test to indicate this change, will advise if he finds anything that might be an issue
* (Yair) We should remember too that Apporva was against get as well, just fyi
* (Atul) agreed, but get is likely doable as a read / get
* (Thomas) We'll need to update the CAEP interop spec now (8.1.2) stream status . . .
* (Atul) noted. but we can go ahead with certs assuming that change gets made

### 319 / 308 - Clarify status code usage for malformed stream configurations sent to the configuration endpoint #319
* (thomas) seeking clarification on what to do with malformed configuration
* (Atul) I think that 400 is the right malformed response (to prevent any probing / leakage)
* (Thomas) then let's doc it and I can make the change
* (Tushar) is the stream id actually valid ?
* (Thomas) one test uses a malformed json object , and uses the replace operation . Some transmitters are returning 404's instead. (do you check stream id or well formed config first?) - there is variance among current transmitters
* (Thomas) malformed config should be a 400, not a 404
* (Yair) if the config is good, but not existing stream id, then it should be a 404
* (Sean) we need to update the spec?
* (Atul) think we're ok, b/c it specifies a 404 for non-valid stream id
* (George) So we want to set an order of precedence for processing the input:
1. Process the json - return 400 if malformed
2. If valid and has usable data, then return a 404
* Need to document this approach so that implementers can understand why they are failing the conformance test, etc.
* (Atul) Agreed, we should doc this in the spec- we'll have to do it in a succesive release. We can create a new release ...
* (Yair) we could allow a return of 400 or 404 to make it broader if we need to
* (George) if you accept both, do you want the code to represent a particular semantic (meaning). 404 means "no stream with this id found". 400 would mean something different (malformed json, for example).
* Sean seemed to be saying that allowing 404, then an attacker can just try stream id's until they hit a valid stream id
* If we want to allow either to be returned, then we have to keep the meanings attached to the codes
* Allowing both error codes to mean the same things creates more complexity and confusion
* (atul) my question is - arent' there a lot of places where you get a 404 if you use a bad stream id? we don't protect against that anywhere in the spec
* (Tushar) This attack would only need a well formed json in order to probe. Also, if we define the order of processing, then we'd have to do it every place we do this
* (George) For me, from a a pure api return code - as long as it's clear what code comes back when, any code can come back. My concern is removing the mystery from what a return code means.
* (atul) the spec has that clarity already, I think. Should we just agree that malformed is 400 here?
* (consensus seems to be achieved here)

### CAEP interop profile - Access token related queries from certification team #308
* (Atul) didn't we agree that we would give a warning here?
* (thomas) the last line of the issue left it unresolved- do we allow for auth code, or only do credential client flow for oauth?
* (Atul) there are some that use the code flow already. Using code flow with short lived tokens is ok according to security review. I think that short lived tokens can be allowed without DPoP. This is a bit out of scope because it is an oauth issue rather than an SSF issue.
* We can warn about long lived tokens .. .
* (Thomas) the issue was not contraints, but since it is a service-to-service flow, the conformance suite does not support authz code for service-to-service flow at this point.
* sounds a bit strange to do that for a service-to-service flow
* also it is uncommon compared to the rest of the conformance suite
* (atul) did we discuss that there could be a place to paste in an access token?
* (thomas) currently there is a place to enter an access token - we'd have to modify the part that goes and obtains an access token dynamically
* (atul) that's a good point. if someone is trying to rely on these tests, they'd want the token acquisition to be part of that (ideally, at least)
* What are ya'll looking for , Tushar. Aaron?
* (tushar) we dont' really care about that part
* (aaron) I'd need to double check on this, but he expects that okta is in a similar situation as well
* (atul) so maybe we could just have a warning about long-lived token . . .
* (Thomas) yes, assuming that the conformance tests can see the TTL for the token
* (Atul) I'd argue for just skipping this. it would be a concern for the oidc group (but we're just using the access token . . .)
* (Thomas) so it seems like we'll say that we support client creds out of the box, and if you're doing auth code, then you'll have to do that out of band and present the token directly
* (atul) thomas, please update the issues as possible

## Proposal for receiver getting point-in-time signal status
* (yair) only proposing for doing this for a single subject
* use case is similar to tushar's:
* say you manage devices, and you're getting a device compliance change event. The receiver may not know what the status is in the moment. (if no change has not happened, you wouldn't know the "original" status.)
* There's currently no way of knowing the live status
* Propose that there should be a way for getting the device status for a particular subject
* If the subject isn't in the stream, etc, then you won't have the potential for that
* "I want the device compliance status of subject AAA"
* The answer might be as simple as sending a device compliance signal . . .
* The request might be identity based instead of specific device based
* (atul) you're not asking for the actual data, you want an event with the status embedded in it
* (yair) the event is more in line with what we're already doing
* it might be as simple as a device compliance event (via a trigger or some such)
* (Atul) an event request semantic would be more intersting - calling an api direct for the status may be a different area of responsibility
* The event is device compliance change, not "status"
* This is a real requirement
* (Mike) This reminds me of other events where we need the original status. If we don't have the original baseline for example. SCIM events had this issue. It does that using the SCIM API though.
* (Mike) Do we want to add a "status" event for every "change" event? That looks like a lot
* (Yair) This is a little bit more work, but the actual information we are looking for is quite clear, but it is being sent through a "change" event right now.
* (Tushar) A lot of these events are about "change", so it might be easier / cleaner to have a corresponding "status" event to each one of those.
* (Tushar) This'll make it easier for Receivers too.
* (Tushar) we could have an "explain" endpoint for any subject that triggers this event.

## open items
* (thomas) questions from fosdem-
* Session Revoked, etc are focused on a single user...
* How can I tell a receiver to sign out a whole tenant (is there a standard for representing, say, a tenant, rather than a single user?)
* (Kenn) interesting use case ...
* (Aaron) yeah, I just wanted to point out that there's some work going on in open id connect called "enterprise extensions" -along with openid provider commands that works with this use case
* (Kenn) When can this happen?
* (Thomas) when an entire tenant is compromised, for example
* (Atul) This is possible today in SSF using the appropriate subject identifier

- Event identifier length
- (Atul) looks like an interesting proposal
- (Yair) It shouldn't be a big deal, given the JWT is pretty big
-

## Action Items