[Openid-specs-risc] Meeting notes

[Atul Tulshibagwale]

Hi all,
The notes from today's meeting are stored here:
Meeting on 2025‐09‐16
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9009%E2%80%9016>
(note
that the location has changed to be the GitHub repo for SSWG).

I'm copying them below for convenience.

Atul

--

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
---
WG Meeting: 2025-09-16 <#Agenda>Agenda

   - Announcement from Shayne
   - CAEP Interop Spec Update
   - SSF Conformance Testing Transmitter feedback
   - SSF Conformance Testing Profile

<#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Yair Sarig (Omnissa)
   - John Marchesini (Jamf)
   - Thomas Darimont (OIDF)
   - Sean O'Dell (Disney)
   - George Fletcher (Practical Identity LLC)
   - Stan Bounev (Blue Label Labs)
   - Kenn Chong (RSA)

<#Notes>Notes <#CAEP-interop-spec-update>CAEP interop spec update

   - (Thomas) Sent a PR to update the interop spec:
   https://github.com/openid/sharedsignals/pull/292
      - Interop spec references draft versions of the other docs, CAEP,
      SSF, FAPI, OPRM, etc.
      - Now that those specs are final, we should update this document
      - Can we get this to final too?
   - (Atul) Should we propose the updated interop spec as final?
   - (Shayne) There is a PR open from Jen which has a few open comments.
      - Issue: https://github.com/openid/sharedsignals/issues/203
      - PR: https://github.com/openid/sharedsignals/pull/245

<#SSF-Conformance-Testing-Transmitter-Feedback>SSF Conformance Testing
Transmitter Feedback

   - (Thomas) Until now, we have offered conformance tests for
   transmitters, which are available via the demo environment. The tests are
   in preview. Would it make sense to move them to the next stage?
   - (Atul) Currently difficult to share the result of SSF tests. Can we
   make that easier to share the results of the test runs?
   - (Thomas) Some privileged information in the HTML
   - Conclusion: Current functionality is sufficient for interop testing
   review.
   - (Yair) Transmitter tests worked well recently. Question: how to deal
   with optional features? E.g. Our transmitter does not support to pause a
   Stream. Currently the testsuite produces a "warning" - we might just
   generate an "info" message for this.
   - (Atul) Do we need to make this clear in the interop spec?
   - (Atul) In the matrix for interop testing Log Format SIT Oct 2025
   Interop testing:
   https://docs.google.com/document/d/1YYEA4VeU6bq_pfkE75XDt3K7ZO5GhG_NHjynaAILWRQ/edit?usp=sharing
   )
   - (Atul and Yair) The language in the spec was confusing what it is to
   be for the Status Endpoint. What does it mean to pause and how long do you
   persist the events?
   - (Yair) 2 Issues were opened on this and one was closed.
   - (Atul) Take a look at the issues to see.
   - (Atul) Until a final interoperability spec it will be hard to come up
   with a certification of SSF implementations. Thoughts?
   - (Peanut Gallery) makes sense and no objections.
   -

<#SSF-Conformance-Receiver-Testing>SSF Conformance Receiver Testing

   - (Thomas) The spec barely mentioned anytyhing about an orchestrating
   receiver. The onlly testing for Rx is to validate requests for faious
   endpoints and expect that certain outcomes are observed. A Rx can receive a
   stream and maybe update it or change status, as examples. Maybe even a
   verifiaiton and eventually the stream is maybe deleted?
   - (Atul) What features or behaviors should a recevier address? Is a
   basic question that the interop spec should address.
   - (Thomas) What can work…at some point a stream will be created,
   verified and deleted.
   - (Atul) Talks about lifcycle of a receiver scenario.
   - (Thomas) Trigger the tests on the receiver side and what is observed
   is the request of the receivers and acknowledgements.
   - (Sean) Why is there a time element in the conformance testing?
   Shouldn't it just be create and destroy?
   - (Thomas) Since it is controlled from the outside, the conformance test
   acts as a transmitter. As long as the test is running, I keep the state of
   the transmitter (whether it creates one or multiple streams)
   - (Thomas) The test could potentially run for ever, but the state is in
   memory
   - (Sean) This should not be any different from OAuth or OIDC compliant.
   - (Thomas) Those tests do the same thing. They have an interactive
   interface
   - (Sean) We do unit testing, and you are doing the same thing, right?
   - (Thomas) If you want to provide certification, you need to be the
   "authority in the middle" to observe and record behaviors.
   - (Sean) You're not running this continuously, right?
   - (Thomas) The infra is up continuously. You start an instance of tests,
   which observes the requests.
   - (Thomas) The OIDC RP tests - expectation that the tests are being done
   and no "UI" is needed. All the attributes and flows needed are provided.
   - Example notes about how to run an OIDC RP Conformance Test:
   https://openid.net/certification/connect_rp_testing/
   - (Atul) Interop participants has already determined that the receiver
   conformance tests won't be required for the Authenticate conference
   interoperability tests
   -

https://docs.google.com/document/d/1YYEA4VeU6bq_pfkE75XDt3K7ZO5GhG_NHjynaAILWRQ/edit?usp=sharing
<#Action-Items>Action Items

   - (Thomas) Verify html export is available for SSF Interop participants
   - (Thomas) Create an issue on the interop spec around features and
   behaviors expected
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250916/50303049/attachment.htm>