[Openid-specs-risc] Meeting notes

[Atul Tulshibagwale]

Hi all,
We are happy to confirm Mike Kiser as a co-chair of the SSWG. Thank you,
Mike, for stepping up and taking this responsibility.

The notes from today's call, including the video transcript is here
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023>.
I'm pasting them below for convenience.

Atul

--

 Atul Tulshibagwale

 CTO

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

---
WG Meeting: 2025-09-23
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#wg-meeting-2025-09-23>
Video Transcript
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#video-transcript>

   - Video Transcript is available here
   <https://zoom.us/rec/share/bkr_DZyMoHUZpgbdph8jgEZLDVPl_q5YWpsdFliZl0K2e6GY7ddxzbROAculnPtT.i50UvuQjh-CxCZYK?pwd=DG6pt6E8II4UXTl2yAAAIAAAADp1hVdNNgjwidf1gLgZ4BHvTqEU127WN0m6b1O2DJAsNDku6F-vDzmkoFCJ8cHmGzAwMDAwNA>
   .

Agenda
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#agenda>

   - New notes archive
   - Co-chair nomination
   - Interoperability spec next steps
   - PoC for SSF Receiver CAEP Interop Testing

Attendees
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#attendees>

   - Atul Tulshibagwale (SGNL)
   - John Marchesini (Jamf)
   - Thomas Darimont (OIDF)
   - Mike Kiser (SailPoint)
   - Tushar Raibhandare (Google)
   - Sean O'Dell (Disney)
   - Jen Schreiber (Workday)
   - Vatsal Gupta (Apple)

Notes
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#notes>
Co-chair nomination
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#co-chair-nomination>

   - (Sean) As you hear - Shayne is pulled into different things, so he has
   stepped down as co-chair
   - (Sean) Would like to nominate the "Dolphin Man" Mike Kiser
   - (Atul) Any objections / feedback / comments? (none heard)
   - Mike Kiser is now the third co-chair of SSWG (insert Dolphin Sound
   here ;)

Interoperability Spec
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#interoperability-spec>

   - Apporva is a bit busy, so updates may be slightly delayed
   - Atul had hoped to finish updates by end of September ; End of October
   is a new goal for interop spec
   - There are a lot of issues available to work on if members have any
   spare time
   - One area is clearly identifying what the receiver requirements are
   (transmitter is already more defined)
   - Vatsal notes that he is available to help (has some spare cycles)
      - Atul will make introductions
      - (Mike L usually sends the slack invites)
   - Thomas created a few issues for the interop
      - posted 2 issues about interop
         - https://github.com/openid/sharedsignals/issues/294
         - https://github.com/openid/sharedsignals/issues/291
      - we should use labels going forward for interop issues

PoC for SSF Receiver CAEP Interop Testing
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#poc-for-ssf-receiver-caep-interop-testing>

   - (Thomas) I came up with a way to do this. Would like to demo.
   - (Thomas) (Starting demo)
   - (Thomas) Tests generate a Transmitter and expects certain things from
   a Receiver
   - (Thomas) Transmitters expect:
      - Create stream
      - Read stream config
      - Read stream status
      - Trigger a stream verification
      - Acknowledge stream verification
      - Receive session-revoked and credential-change events

openid-ssf-receiver-stream-caep-interop:
This test verifies the receiver stream management according to the
capabilities listed in the CAEP Interop Profile 1.0.
The test generates a dynamic transmitter and waits for a receiver to
register a stream.
The testsuite expects to observe the following interactions:
* creating a stream
* reading the stream configuration
* reading stream status
* trigger a stream verification
* acknowledge the stream verification.
* retrieve and acknowledge the CAEP events 'session-revoked' and
'credential-change'


   - (Thomas) Is this what you had in mind?
      - (Atul) This is exactly what I was expecting to see
   - (Thomas) What other kind of interop testing do you expect?
   - (Mike) This isn't in the interop spec, but we should also do some
   testing around device compliance, because the use-case is fairly common.
   - (Thomas) Is there a way to return something that proves that the
   receiver understood / could read the event properly?
   - (Atul) Just the presence of the right acknowlegement is likely enough
   - it implies that the receiver can use the event and understand it properly
      - at the beginning of the test, the receiver should choose what type
      of event it wants to receive
   - (Mike) the stream config should be set up correctly for the selected
   event type as well
   - (Thomas) Does the receiver need to be able to do stream update?
   - (Atul) for now, it will be out of scope because of the
   interoperability spec
   - (Thomas) Can they be "may" options?
   - (Atul) The interop spec has to be definitive, so let's avoid the use
   of "may"
   - (Thomas) should the standard events be reported as supported events or
   are they implied?
   - (Atul) all events should be listed in the configuration ...
   - (Thomas) verification events and update events aren't listed in the
   examples . .
   - (Atul) Didn't we have a discussion about that? I know that there were
   differing opinions as to whether or not they were supposed to be in the
   metadata / config

Google's SSF announcement
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9023#googles-ssf-announcement>

   - (Sean) Are you supporting all the event types in the conformance tests?
   - (Thomas) effectively, yes - all the events listed in RISC / CAEP are
   supported, with generic metadata and updated timestamps
   - (Tushar) actively looking for partners for the closed beta with Google
   - (Thomas) Do we need to have Google Workspace?
      - (Tushar) You can have Google Cloud to participate in the beta
      - (Tushar) Right now we have implemented only a Shared Signals
      Receiver, so partners will need to be Transmitters
      - (Sean) So if you have instances of GCP in your company, then we can
      interop, right?
      - (Sean) The use case is that "I want to kick someone out of their
      GCP session", will that work?
      - (Tushar) That might not work
      - (Tushar) It is a little open ended. We have implemented session
      revoked. We can revoke 3rd party IdP sessions.
      - (Tushar) You can sign up here:
      https://workspaceupdates.googleblog.com/2025/09/enhancing-security-outcomes-shared-signals-framework-beta.html
      - (Tushar) Two kinds of user sessions are revoked: All Google
      sessions, and sessions mapped from the IdP session-id.
      - (Sean) Do you support "alias" subjects?
         - (Tushar) It can either be email, or session id.
      - (Sean) In large orgs, you might need an alias subjects
   - (George) Doesn't using aliases have privacy issues?
      - (Sean) Because it is necessarily about employees, the privacy
      concerns are not high
      - (George) I agree it makes sense in the enterprise case, but you
      need to be careful in consumer use cases.
      - (Sean) The complexity of your org may change the type of subjects
      you use, which results in the need for aliases for employees
(e.g. employee
      id, M&A resulting in multiple types of employee id, etc.)
      - (George) GDPR laws may prevent different organizations from sharing
      alias data.

Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250923/ba51d0de/attachment-0001.htm>