[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230919>:

Thanks to those who attended,
Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

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

WG Meeting: 2023-09-19
<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#Agenda>Agenda

   - Issue 116 <https://github.com/openid/sharedsignals/issues/116>
   - PR 117 Discussion on empty events_requested
   <https://github.com/openid/sharedsignals/pull/117>
   - Resolution on sub_id vs subject in PR #82
   <https://github.com/openid/sharedsignals/pull/82>
   -

<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Phil Hunt (Independent ID)
   - Mike Kiser (SailPoint)
   - Shayne Miel (Cisco)
   - Sean O’Dell (independent)
   - Yair Sarig (VMWare)
   - Nick Wooler (Cisco)
   - Nancy Cam Winget (Cisco)
   - Tim Cappalli (Microsoft)
   - Edmund Jay ()

<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#Notes>Notes
<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#Updates-to-the-Transmitter-Configuration-Metadata-Issue-116>Updates
to the Transmitter Configuration Metadata Issue #116
<https://github.com/openid/sharedsignals/issues/116>

   - (Atul) Change implies we’re describing a Receiver
   - (Phil) Didn’t want to make a breaking change, but I’d like to describe
   something that is both a Receiver and a Transmitter. This is why I’ve only
   proposed a new delivery method supported and not changed
   transmitter_configuration
   - (Phil) I’m facing this in my SCIM server implementation. I need the
   server to be both a Transmitter and Receiver
   - (Atul) Does this make the spec a little confusing because the spec as
   it stands does not provide a way to describe a Receiver. Adding Receiver
   details in a Transmitter Configuration Metadata may confuse readers
   - (Sean) An ACK for a client and an ACK for a SCIM server is different(?)
   - (Sean) Need to understand the SCIM use case better. Is the SCIM server
   both a SCIM server and a client?
   - (Atul) While this is important, I would like to move this to post
   draft-02, so that people starting to implement can work on draft-02 instead
   of draft-01
   - (Phil) We are trying to lock down a relationship by way of this
   protocol. If you don’t set up a Receiver right now, we will have a breaking
   change later
   - (Phil) I have to do this, and I will implement it a certain way, but
   - (Shayne) The reason we have an API for Transmitters is because some
   other entity coming to the Transmitter to receive signals. It may not be
   the case the other way around
   - (Phil) Is this a “push only” perspective? In the current spec the
   Transmitter has to start first, and then the Receiver
   - (Tim) We are at risk of people not considering SSF because we are not
   making progress. We need to draw a line somewhere, and get a new draft out.
   - (Atul) We can keep the PR open and consider it after draft-02 is
   proposed for vote

<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#PR-117-Discussion-on-empty-events_requested>PR
117 Discussion on empty events_requested
<https://github.com/openid/sharedsignals/pull/117>

   - (Shayne) Should verification and “stream updated” events always be in
   streams?
   - (Shayne) It should be possible for Receivers to request empty streams,
   because they can add event types later
   - (Atul) I suggest we add language in the spec that says the
   verification and stream updated events are always present in the stream
   regardless of what the Receiver has requested
   - (Phil) We have both events_delivered and events_requested So what is
   the meaning of passing a empty value
   - (Atul) We should update the language in the PR to say something like:
   events_requested SHOULD NOT be empty. If no changes are to be asserted
   in a stream update, this field MUST NOT be included.

<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#Resolution-on-sub_id-vs-subject-in-PR-82>Resolution
on sub_id vs subject in PR #82
<https://github.com/openid/sharedsignals/pull/82>

   - (Atul) Trying to resolve Apoorva’s comment that changing subject in
   the verification event is a breaking change.
   - (Phil) Do we need to have a subject in a verification event?
   -

<https://hackmd.io/CKKYvT1YSCqgm5iM23aRiQ?view#Action-Items>Action Items

   - Atul to send out an email describing this issue (PR #82) better and
   soliciting comments on email, or discuss in next meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230919/feaf81bc/attachment-0001.html>