[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes for today's call. Thanks Shayne for taking notes after I
left. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20250708>.

Atul

-- 

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>

--
WG Meeting: 2025-07-08 <#Agenda>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>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>Notes <#Working-draft-numbering>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-PR283>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>Action Items

   - (Shayne) Create PR for ip-addresses and aliases in Complex Subject
   matching Issue 282 <https://github.com/openid/sharedsignals/issues/282>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250708/dd0fa584/attachment.htm>