# WG Meeting: 2025-06-24 ## Agenda - Feedback received during review period: - [Uniqueness of stream id](https://github.com/openid/sharedsignals/issues/272) - [Txn value should be a string](https://github.com/openid/sharedsignals/issues/273). [Pull request created](https://github.com/openid/sharedsignals/pull/277) - Editorial issues in [SSF](https://github.com/openid/sharedsignals/issues/274), [CAEP](https://github.com/openid/sharedsignals/issues/275), and [RISC](https://github.com/openid/sharedsignals/issues/276) specs - Documetation / clarity update for [Session Established and Session Presented CAEP Events](https://github.com/openid/sharedsignals/issues/281) ## Attendees - Sean O'Dell (Disney) - Yair Sarig (Omnissa) - John Marchesini (Jamf) - Tushar Raibhandare (Google) - Shayne Miel (Cisco) - Vatsal Gupta (Apple) - Jen Schreiber (Workday) ## Notes ### < Stream ID > - (Atul - from Email) - The issue about uniqueness of stream id is important, but might require a normative change if we have to add the clarification as suggested by Tushar. We have three choices here: -Make a normative change, and restart the review process. -We can take the position that practically IdPs will determine uniqueness with some limitations and not add any text. -Or we could add something to the non-normative security considerations section. I'm slightly in favor of doing nothing (option 2 above). I think restarting the review period for this would be disruptive and probably not worth it. -(Shayne) Agreed with Joseph on the PR that they do not need to be globally unique, but rather unique to a Tx / Rx pair. (Shayne) Could be confusing if a stream is deleted by either party. -(Yair) Maybe with an "existing" stream id not being re-used but deleted, not so much. - (Yair) UUID might be used, so it might not be problematic. - (Yair) Does not need it to be globally unique but saying it the spec would remove confusion. - (Sean) re-iterated Atul's point via email (is the normative change worth it?) - (George) Why not add it in Security Considerations? - 9.4 "Stream Identifiers" its important to realize that ID's can be re-used but should not to ensure there are no unintended conflicts. - (Yair) It might put more burdent on Tx's - (George) - Highlight the spec does not highlight the non-reuse of ID's for streams. - If there is not a super pressing need to get to final and it is a significant security problem..start over for v1 - Security Considerations brings it to the implementer to be more "aware". (of the re-use...so a caveat emptor) - (Sean) Agreed - (Shayne) Agreed - (Tushar) Agreed ### < TXN as string > - (Group) Makes sense ### < Editorial Issues > - (Shayne & Group) Pick "A SSF" or "An SSF" - (Shayne) In the spec, we should only say "SSF Event" if it is a verification or status updated event - (Jen) Maybe the linter caught these? - (Jen) Linter looks fine ### < Editorial Issues - CAEP > (Shayne) - formatting issues (Sean) - Make the event examples match, remove the wrapping in RISC and make them match ### < Session Presented and Established wording > (Shayne) - no new sub section needed for use cases, just add bullet points and minor verbiage tweaking. ## Action Items (Sean & Shanye) - Remove the wrapping in RISC and remove the NOTE.