[Openid-specs-risc] Meeting notes 2025-08-19

Tue Aug 19 17:58:52 UTC 2025

Please see the meeting notes from today's SSF WG meeting below.

[cid:ed1f10a6-a320-4ea7-afae-405bc042d89f]
[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>

WG Meeting: 2025-08-19
Agenda

  *   Sending "deleted" status with a Stream Update Event
  *   Interop spec status
  *   Interop event info
  *   SSF Conformance Tests update
  *   The vote is open

Attendees

  *   Yair Sarig (Omnissa)
  *   Thomas Darimont (OIDF)
  *   Shayne Miel (Cisco)
  *   George Fletcher (Practical Identity LLC)
  *   Kenn Chong (RSA)
  *   John Marchesini (Jamf)
  *   Mike Kiser (SailPoint)
  *   Jen Schreiber (Workday)

Notes
The vote is open for the new drafts

  *   (Shayne) https://openid.net/foundation/members/polls/373
  *   (Shayne) Please vote
  *   Shared Signals draft 5, CAEP draft 5, RISC draft 3
  *   (Thomas) What about the interop spec?
     *   (Shayne) Not part of the vote. There are still issues to work out and we didn't want to delay the vote any further
  *   (Shayne) These drafts will become the true release v1 of these specs after vote.
  *   (George) The vote itself is to promote these drafts to final

Interop spec status

  *   (Shayne) As mentioned above, draft 1 of the interop spec is not included in the current vote.
  *   (Shayne) There is work to do in this group to get it fully ready for its own vote.
  *   Issue 203<https://github.com/openid/sharedsignals/issues/203> which is being addressed in PR 245<https://github.com/openid/sharedsignals/pull/245> still needs to be resolved.
  *   (Shayne) Atul needs to confirm, but I believe we are using the unofficial draft 1 (i.e. what is published on github) for the upcoming interop event.

Interop Event Info

  *   (Shayne) I don't have much to share other than that it is happening at Authenticate in October.
  *   (Shayne) We will probably start up the pre-interop meetings like usual. Please stay tuned for more details.

SSF Conformance Tests Update

  *   (Thomas) Working on aligning the conformance tests with the latet unofficial interop spec
  *   (Thomas) Old tests were based on SSF implementers draft 3, we are bringing them up to draft 5
  *   (Thomas) Next week begin implementing Receiver tests
  *   (Thomas) Aiming for a usable set of tests for Transmitters and Receivers by mid September
  *   (Shayne) Do I remember correctly there was a document?
  *   (Thomas) Yes, link here: https://docs.google.com/document/d/1ft_-NIdWwvUiDAfyWrvxaO-WvhJDDLbMQ-gRtsKBMJw/edit?usp=sharing
  *   (Yair) Can you provide details about the site? Main or staging?
  *   (Thomas) Did a bunch of conformance tests for OpenID4VCI (Verifiable Credential Issuance). We set up a demo environment that lets us regularly update the tests. We will repeat that procedure for SSF.
  *   (Thomas) SSF Conformance tests will be provided via the demo env: https://demo.certification.openid.net/index.html
  *   (Thomas) It would be helpful if implementers would run these again to help us improve the tests.

Sending "deleted" status with a Stream Update Event

  *   (Yair) The spec says to send a Stream Update event when the status changes.
  *   (Yair) Do we need a "deleted" status to send when a stream is deleted?
  *   (Thomas) If we don't add a deleted status, how will Receivers know that resources should be cleaned up?
  *   (Mike) Does that imply that streams live on forever with status "deleted"?
  *   (Yair) No, the stream would be deleted and gone.
  *   (Thomas) What happens for Receivers that don't get the event?
  *   (Yair) This event is for the benefit of the Receiver.
  *   (Thomas) But that means the stream can only be deleted after the deleted event was consumed.
  *   (Yair) I don't think the stream should wait for the event to be delivered before deleting
  *   (Thomas) Should we use something like the inactivity timeout to say the stream should hang around for a specific amount of time after the event is sent before deleting itself?
  *   (Shayne) It's a little bit strange to think about status of "deleted". I wonder if we want a new event, StreamDeleted.
  *   (George) I agree with the idea of a specific event. There is no way to guarantee that the Receiver will receive the event, but having a mechanism to alert in an optimistic case is nice.
  *   (George) Both the Transmitter and Receiver should have some documented logic to determine when a stream is no longer active. This new event is an optimization, but the fallback mechanisms have to be present as well.
  *   (Yair) What is the expectation today for what happens when a stream is deleted?
  *   (Shayne) I don't think we have any expectations today.
  *   (Yair) For now, we could send a "disabled" status before deleting the stream
  *   (Shayne) I'm not against the idea of sending a "disabled" in this case. What does the Receiver do when it gets that event?
  *   (Yair) I would expect that getting an unexpected disabled status would alert a human operator.
  *   (Mike) Someone might trigger a verficiation event which would then return a 404 because the stream would no longer exist. Is the expectation that a 404 should cause the Receiver to shut down the stream on their end?
  *   (Yair) I would expect that the customer or Receiver host would want to trigger some kind of investigation
  *   (Shayne) Does the deleted event vs a 404 change the customer's behavior?
  *   (Yair) It depends on whether the customer triggered the action
  *   (Shayne) A deleted event might be a nice thing for a Receiver that requests the deletion.
  *   (Mike) A 204 from the delete request should be the thing that tells the Receiver the deletion was successful.
  *   (Thomas) What about multiple Receivers on the same stream?
  *   (Mike) It feels cleaner to have a deleted event to go out before deletion
  *   (Thomas) Possible race condition without some kind of timeout before deleting the stream
  *   (Yair) For push streams, that shouldn't be a problem, but poll streams do have that issue
  *   (Shayne) One more argument for making this an event not a status is that statuses seem to talk about whether events can "enter" the stream, not whether they can be broadcasted over the stream.
  *   (Yair) Is there any other change that can affect the stream besides status? If so, why do we only have StreamUpdate events with status info?
  *   (Shayne) Some examples of things that could change - the Tx could add or remove subjects, could change the delivery method, could change timeout intervals. We don't really restrict the Tx's actions.
  *   (Shayne) What I'm hearing is that maybe we want to extend StreamUpdated to cover more than just status changes. Then we are not creating a new event type for stream deletion, but just adding new metadata to the StreamUpdated event.

Action Items

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250819/38738b11/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/20250819/38738b11/attachment-0001.png>