WG Meeting: 2026-01-20

# WG Meeting: 2026-01-27 ## Agenda - Device Metadata in signals - Stream Status Update for Certification tests - WG Operating Model (Meeting Frequency, Spec Dev, Cert Dev) ## Attendees - Mike Kiser (SailPoint) - Thomas Darimont (OIDF) - Gail Hodges (OIDF) - Kenn Chong (RSA) - Tushar Raibhandare (Google) - Ashish Kedia (Google) - Yair Sarig (Omnissa) - Vatsal Gupta (Apple) - John Marchesini (Jamf) - Apoorva Deshpande (Okta) ## Notes ### Device Metadata - (Yair) in many cases, it might be helpful to add additional data about the device in question. - Is it part of the subid? or the payload? - In subid , there is a spec for the device, but not for info about the device - it is not the purpose of subid, so where should it go? - (Kenn) - if this is about device compliance, you want to have as much as possible in there , just for clarity - a minimum specified in the payload would be helpful - (Thomas) - I was originally leaning toward using a device info as part of the subid; it's more a matter of where do you want to filter? - (Yair) - I agree with Kenn, most likely, becuase it fits within the payload section. Unless we add device metadata . . . - an issue / ticket was closed on this topic - (Thomas) - does it matter if the event was coming *from* the device? a present user using the device vs the device itself - (Yair) - but this is about the device - today, the device in the subID is very limited . . . - (Mike) we should link the device in subid with the payload if it's a specific one attached to a user - (Yair) Helpful to know more info on this - (Apporva) - I think we discussed event metadata earlier - so that may be the earlier context . . . - (Ashish) - we have seen this , but with user also - you may want metadata about the user (in addiiton to the session metadata) (location, IP address, etc) - This feels broad enough for metadata for various elements - (Gail) This is simliar to what Juliana Cafik is doing with eKYC work on metadata (back account / mDL / wallet). May be a schema bleedover / resuse - (Apporva) https://github.com/openid/sharedsignals/issues/221 that's the issue for event data field . . . - https://oidf.slack.com/archives/C02Q0762E83/p1767896644198309 - slack comment to create an issue ### Stream Status Update for Certification Tests - (Tushar) - see email from 20/1 to the mail list excerpt: - If a stream is paused the only way to unpause it is to update the stream. - If we compel Transmitters to implement Stream Update, we are indirectly forcing them to implement pausing/unpausing as well. (Or we could soften the language in the SSF spec to say that pausing is optional and can be rejected. But that does complicate Stream Update.) - (Apoorva) - working on getting consensus internally - if you want to know why the stream is not working, isn't verificaiton enough ? - (Tushar) - but verification doesn't return status, isn't it better to be explicit for stream status. . . - the current flow is to request a verificaiton event, but then wait for a time out so that you mark it as a disabled stream - (Apporva) - but isn't verification supposed to be nearly instantaneous? - (Yair) - I don't think that update is mandatory, because it's only useful if the receiver wants to pause. (not needed if the transmitter wants to pause) - if the receiver doesn't get a verification event, then it can go get the status directly - status and verification are two different pathways - (tushar) - it's not neccesarilty that there is an error with the stream; verification doesn't tell us if the stream is paused. (lots of potential possibilities for what's going on) - (Apporva) - the pause and disabled are also optional properties here .. . we are trying to include usecases that are for a "perfect" solution- interop is a minimum viable requirement for interop. - (tushar) - the goal for successful interoperability ; not just a MVP, but a usable , functional integration. Certification is the key here . . . - (Yair) I agree with both. Status is something that is part of the certification , becuase you have to know what's going on with the stream. Status update is not part of it but status get is - (Thomas) - pause and unpause is better than recreation. Recreating a stream might have other impliaitons (new keys, for example) - (Approva) - the keys creation would be independent of th stream (it's at the transmitter level)... essentially now we are bringing in pause / unpause. This is increasing the scope - perhaps a separate version of certification. . . - (Yair) Agreed with approva - pause is more of a niche functionality . . . if you do want to have a stream pause available - is the certification part of that ? - (Thomas) - if I don't have supprot for update and pause, then I can't test that part of the specification (can't check for no events from paused stream) - (Yair) - optionality is important here . . . but you can't force every transmitter. . .- - (Gail) - we need to identify what is mandatory and optional (and what optional things HAVE to work if they're included) - (Apporva) - we were trying to avoid interoperability - interop spec was mandatory. ### WG Operating Model (Meeting Frequency, Spec Dev, Cert Dev) - (Ashish) - Just wanted to highlight a need for decision models . . . the process feels slow, and want to accelerate the process where possible - example: there are issues that we are interested in solving ## Action Items - Mike to go hunt down what Juliana is doing with eKYC / wallet / shared signals - Chairs to propose a way forward based off the discussion from the issue . . . - Yair to create a new issue for the device metadata discussion (https://github.com/openid/sharedsignals/issues/320)