WG Meeting: 2026-01-13

# WG Meeting: 2026-01-13 ## Agenda - Review certification launch items: - Should we remove the status endpoint requirement from the interop spec ([PR #314](https://github.com/openid/sharedsignals/pull/314), [issue 318](https://github.com/openid/sharedsignals/issues/318))? - Access token related queries ([issue 308](https://github.com/openid/sharedsignals/issues/308)) - Status code for malformed stream configuration requests ([issue 319](https://github.com/openid/sharedsignals/issues/319)) - Device metadata ## Attendees - Atul Tulshibagwale (SGNL) - Yair Sarig (Omnissa) - Kenn Chong (RSA) - John Marchesini (Jamf) - Tushar Raibhandare (Google) - Ashish Kedia (Google) - Apoorva Deshpande (Okta) - Thomas Darimont (OIDF) - Sean O'Dell (CVS Health) - Jen Schreiber (SGNL) - George Fletcher (Practical Identity) ## Notes ### Review certification launch items / Stream Status Endpoint - (Atul) Should we have the status endpoint requirement in the profile? - (Atul) Interop profile should guide the certification (aspires to get there) - (Atul) Major implemementations for the status endpoint - need feedback - (Apoorva) - Not having it does not change interoperability status from an operational standpoint. Supporting NOT adding status endpoints in the interop profile. - (Tushar) - Certification is based on the SSF Interop Spec, so status as a receiver is important and might want to periodically check the status of the stream, as an example. Pushing for including rather than excluding it. - (Ashish) - Agree in general but trying to balance making life easy for new partners. Can keep status as part of the spec but DO NOT enforce it. It does not add much value so reducing it as a requirment might make it easier for new implementers. - (Apoorva) - Goal - Interop profile should not be contradictory to the SSF Spec. - (Atul) - purpose of the interop spec should be cut and dry no optionality. We do not want any optionality in the interoperability profile. - (Apoorva) - Would the interop profile and ssf spec cause more confusion if they are not as closely aligned 1:1? - (Atul) - As an example, 2 companies can come together and implement the SSF spec, without using the interop specification/profile. If you want a certified implemenation you need to have, must have all of "these things" - which is decalred in the interoperability spec. In general this is the approach to the interoperability spec, nothing specific per se. - (Apoorva) - Is status really needed in order to display the interoperability as opposed to AuthN, verification. - (Thomas) - Having support for the status endpoint does provide value when you support reading status. Without status all you can see is configuration but not events. Status, to Thomas, makes it obvious that your stream may be paused. - (Atul) - We can just support read on the status endpoint, yes. - (Tushar) - Let's talk about use cases to support status...like observability. When a stream is created the status is checked. Reading is important as a part of observability. - (Apoorva) - Thomas' use case makes sense and the verification endpoint is designed to do this and can support the use case defined above. - (Tushar) - If verification does not get delivered there could be many things that are wrong, so value is still there. Status is out of band, separate channel as compared to Verification. - (Yair) - there is a difference between status and verification. Status is a call from Rx to Tx so it is a bit different. - (Atul) - I dont see in the SSF spec defined behavior when a stream is paused or disabled. - (Yair) - When a stream is disabled Tx must not send events. - (Atul) - The Tx could pause or disabled and the status endpoint could provide value to show this. - (Apoorva) - What would the remediation be? Destroy the stream and re-create it? - (Tushar) - We want to check the status of a stream...wolud we destroy / re-create every hour for a week? - (Thomas) - Deleting and recreating a stream could be expensive and abusing this to do some checks might be more troublesome than it is worth vs doing what the endpoint was intended for. - (Yair) There was a reason for disabling in the first place, this should honor the disablement from the transmitter. - (Apoorva) Just adding status doesn't offer remediation. Only way to remediate is to pause, but then we need to add a dependency on stream updation, are we willing to do that? - (Apoorva) I'm not suggesting that no one should implement status, but is it required for interoperability - (Tushar) Updating the stream also provides additional value. The semantics is different. When the stream is paused, the I can take action outside of affecting the stream. Both are required IMO. - (Yair) Apoorva's point is good, that not every function is required. I don't think update is required. Status should be a fundamental requirement though. - (Atul) Do Receivers feel like the status endpoint is required for transmitters - (Tushar) We don't want to go through Transmitter documentation to figure out what they support outside of the certification. We won't have information about why the transmitter is behaving a certain way. - (Yair) What does it mean to be certified? If you are going with the minimum, then you don't need almost anything. Is it really useful for customers though? Where do we put the line? Perhaps the answer is that certification isn't boolean, but it gives you a list of capabilities. - (Thomas) Adding to Yair's point: The status endpoint is an endpoint on the Transmitter. There may be a lot fewer transmitters than receivers. Some receivers may be dumb, and others may be more sophisticated. If you want to support all receivers, then transmitters should be able to deal with that. The other case may be true as well - more transmitters than receivers 1. No support of status endpoint 2. Support of READ only for status endpoint (supports observability) 3. Support of read/update for status endpoint (supports observability and stream control) - (Apoorva) We've been doing this since 2023, but we haven't run into the status requirement yet. - (Kenn) From RSA's perspective, we are looking at being a receiver and transmitter, and provide a formal answer. ### Access token questions (issue 308) - (Atul) Should we be specifying the maximum lifetime of access token in interop spec and therefore require in certification. - (Apoorva) How can we validate that? - (Atul) Transmitter would be expected to validate exp of the JWT. Do we require a AT JWT? - (Thomas) Expiraiton is a separate field in the token response - (Atul) We want to certify the transmitter and not the AS. - (Thomas) If expires in is too far in the future, we could have a warning. - (Apoorva) This may be getting to far into security protocols for the interop profile - (Atul) Warning in the certification suite would be ok with the current interop profile - (Thomas) Will check the FAPI 2 certification suite - (Atul) If giving a warning, we should agree on what it means to be short lived. - (Apoorva) Profile already mentions 60 mintues (Section 2.7.1) - (Thomas) What is the final decision on authorization code flow? - (Atul) Will add a comment to the issue about this - (Thomas) If we keep the auth code flow, then we must test it - (Atul) Auth code flow is being used by Apple/large enterprises. We would be remiss if we had a certification that didnt include for these enterprises - (Atul) Continue the discussion on the issue ## Action Items