---
# System prepended metadata

title: '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)