WG Meeting: 2025-07-08

# WG Meeting: 2025-07-08 ## Agenda - [Proposal for intermediate draft identification](https://github.com/openid/sharedsignals/issues/284) - Revised language for CAEP Examples [PR#283](https://github.com/openid/sharedsignals/pull/283) - ## Attendees - Atul Tulshibagwale (SGNL) - Vatsal Gupta (Apple) - Shayne Miel (Cisco) - George Fletcher (Practical Identity) - Robert Gallagher (Mastercard) - John Marchesini (Jamf) - Apoorva Deshpande (Okta) - Stan Bounev (Blue Label) - Yair Sarig (Omnissa) - Martin Gallo (Independent) - Jen Schreiber (Workday) - Sean O'Dell (Disney) ## Notes ### Working draft numbering - (Apoorva) Does that mean we cut a branch when we have to do a release? - (Atul) No, we have a separate publication repo - (Shayne) There was a proposal to publish every single one, but we decided that that's not a good idea. But do we want to check-in the output HTML for every intermediate version? - (Apoorva) The HTML is useful - (Jen) Other working groups do not check-in their HTML - (George) In the OIDC working group for Native SSO drafts, we do publish drafts that are not implementers' drafts. They have sequential number for intermediate drafts, and the latest intermediate draft becomes the implementer's draft - (George) The DCP working group also publishes intermediate drafts, so this is working group specific, and there's no OIDF recommendation - (Jen) Publishing the intermediate HTML would require every PR to have it - (Shayne) Since we don't check-in the txt and XML right now, we shouldn't do the intermediate HTML either - (Shayne) So just to clarify: The version number in the WIP draft is the next version number (i.e. the version number that we are working toward) - (Jen) Yes ### CAEP example clarification [PR#283](https://github.com/openid/sharedsignals/pull/283) - (Atul) I suggested that we create a non-normative subsection and put the additional text there - (Shayne) There can be multiple kinds of session, for example SSO can be a session, so it's a little confusing that the "session established" is sent when the application session is created, and the "session presented" is sent when the SSO session shows up. - (Atul) The original intent was for the "session established" to be a closed-loop communication back to the IdP, and the "session presented" to be used as a means of building an ITDR solution - (Apoorva) We don't say which entity sends the event except Transmitter and Receiver, so why are we adding those concepts in the spec? - (George) If I'm a receiver, and I receive a session request, then I can create a session presented event. If my application creates a new session, then I can send a session established event. Is the distinction then whether someone else pushed a session to me, versus a session I created - (Atul) We should not have concepts of IdP, etc in the normative language of the spec - (Sean) The intent is to pull these examples and the ones that are there already into a non-normative section of example use cases. Eventually, this section would cover the other event types as well. ## Action Items - (Shayne) Create PR for ip-addresses and aliases in Complex Subject matching [Issue 282](https://github.com/openid/sharedsignals/issues/282)