[Openid-specs-risc] Notes from WG call 2025-09-09

Tue Sep 9 18:06:50 UTC 2025

WG Meeting: 2025-09-09
Agenda

  *   Demo of SSF Receiver conformance tests
  *   Stream Updated Event and Disabled / Paused Streams

Attendees

  *   Shayne Miel (Cisco)
  *   Thomas Darimont (OIDF)
  *   John Marchesini (Jamf)
  *   Kenn Chong (RSA)
  *   Wade Ellery (Radiant Logic)
  *   Yair Sarig (Omnissa)
  *   Jen Schreiber (Workday)
  *   Sarah Cecchetti (Beyond Identity)
  *   Apoorva Deshpande (Okta)
  *   Gail Hodges (OIDF)

Notes
Demo of SSF Receiver conformance tests

  *   Conformance Tests for SSF Receivers
  *   (Thomas) –-Shared the conformance tests live–-
  *   (Apoorva) Is this only for poll?
  *   (Thomas) No, it supports both push and poll
  *   (John) Will these test plans be published?
  *   (Thomas) The Transmitter tests have been published and the Receiver tests will be soon
  *   (John) What is the process for getting certified?
  *   (Thomas) We don't offer certification yet, but we plan to have this soon
  *   (Thomas) Hoping to have Receiver tests ready 2 weeks before Authenticate
  *   (Apoorva) Are we going to stick with the Transmitter test suite for the interop?
  *   (Thomas) Goal is to have Receiver tests ready before Authenticate
  *   (Shayne) We will let Atul weigh in on what will be required for the interop
  *   (Apoorva) Is there the ability to generate a pdf report of the tests?
  *   (Thomas) Not at the moment
  *   (Thomas) Transmitter tests are available here<https://demo.certification.openid.net/schedule-test.html>
  *   (Gail) Great work!
  *   (Gail) We would like to know which companies are interested in using these tests to self-certify. Cost will be $700 for members, $3500 for non-members
  *   (Apoorva) Is certification required for Authenticate's interop
  *   (Shayne) My understanding is that certification will not be available by then
  *   (Gail) Correct. The interop is a step along the way to getting the tests to a final state.

How should we test Receivers?

  *   (Thomas) The SSF spec is about what a Transmitter should do. There is very little about what a Receiver should do.
  *   (Yair) Can there be expectations based on the profile chosen?
  *   (Thomas) Who will come up with this kind of profile?
  *   (Apoorva) We don't say much about the Receiver as an entity in the SSF spec. We may need ot address that before any profile.
  *   (Thomas) Such a profile should contain things like: if Rx create a stream, it should then send a Verification event to show that the stream is working
  *   (Thomas) Could we make capabilities configurable for a Receiver? This could be a profile or possibly more metadata for Rx
  *   (Yair) What is purpose of test? If to test our code, that is one thing. If certification, we may need more.
  *   (Apoorva) These are all optional operations that do not hinder the interoperability. Maybe we should keep it to the minimum.
  *   (Yair) For certification, we should keep it to the minimum. This is true for the Tx too.
  *   (Thomas) If we focus on delivery, we can talk about whether
  *   (Apoorva) Push Receiver responding with HTTP 202 is something most of the vendors miss in the first go! We should include things like these that will aid interoperability
  *   (Thomas) If the working group comes up with a Receiver profile they would like to test, I can update the tests
  *   (Thomas) Problem I ran into when writing the tests is that there is no way to force the Tx to generate an event.
  *   (Shayne) The only way to trigger an event is the Verification event
  *   (Shayne) How do you test that the Rx received the events?
  *   (Thomas) 202 on push or ack on poll
  *   (Shayne) A Rx could fake that
  *   (Yair) There is no requirement that a Rx parse the events
  *   (Shayne) Do we need something more for testing Rx or does this imply that Rx is not testable?
  *   (Apoorva) Should the WG propose a set of tests before Thomas spends a lot of time on this
  *   (Thomas) SSF Receiver tests working doc: https://docs.google.com/document/d/1ft_-NIdWwvUiDAfyWrvxaO-WvhJDDLbMQ-gRtsKBMJw/edit?tab=t.0

Stream Updated Event and Disable / Paused Stream

  *   (Thomas) Raised question in Slack about Stream Updated event - when it should be emitted
  *   (Shayne) Stream Updated event only gets sent if the Tx decides to change the state of the stream without the Rx's input
  *   (Shayne) Spec says that if switching to paused/disabled, the Tx must send the event before changing status
  *   (Shayne) That leaves us with a question about what to do for poll delivery streams. Does the Tx need to wait for acknowledgement of the event before it can change status?

Action Items

  *   Please comment on the SSF Receiver tests working doc<https://docs.google.com/document/d/1ft_-NIdWwvUiDAfyWrvxaO-WvhJDDLbMQ-gRtsKBMJw/edit?tab=t.0>
  *   Co-chairs to work out checkpoints / cadence to get these tests to the finish line in Nov

[cid:aaa5ffa6-d6b2-4e5b-8cde-480986a9a187]
[https://duo.com/assets/img/email/spacer.gif]
Shayne Miel  / Principal Engineer (he, him, his)
smiel at cisco.com<mailto:smiel at cisco.com>
(919) 923-6230
cisco.com<https://www.cisco.com/site/us/en/products/security/index.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250909/828dbfbf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13713 bytes
Desc: image.png
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250909/828dbfbf/attachment-0001.png>