[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

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

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

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

WG Meeting: 2022-06-06 <https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Agenda>
Agenda

   - #60 Are Subjects Required in SSF Events
   <https://github.com/openid/sharedsignals/issues/60>
   - #45 Before a Receiver creates a stream…
   <https://github.com/openid/sharedsignals/issues/45>
   - #36 Should poll URL be specified…
   <https://github.com/openid/sharedsignals/issues/36>

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Stan Bounev (VeriClouds)
   - Steve Venema (ForgeRock)
   - Peter Travers (Beyond Identity)
   - Eric Karlinsky (Okta)
   - Apoorva Deshpande (Okta)
   - Edmund Jay ()

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Notes>Notes

Issues picked up for discussion today are those tagged as bugs in GitHub
<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Issue-60>Issue #60

   - Are subjects always explicitly added to a stream? We had disucssed
   this topic a few weeks ago.
   -

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Issue-45>Issue #45

   - We need not have a way for Receivers to discover event types before
   creating a stream.
   - Instead, we can clarify that a Transmitter should ignore any event
   types in “events requested” from a Receiver Create Stream request that it
   doesn’t understand.
   - Similarly, a Receiver should only rely on the “events delivered”
   parameter of the stream configuration to understand which events it can
   expect from a Transmitter, regardless of what it has requested.

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Issue-36>Issue #36

   - Modify the spec to clarify that “delivery” is not always Receiver
   Supplied.
   - The “delivery_method” is always Receiver Supplied
   - The “url” is Receiver supplied for “Push” method, and Transmitter
   supplied for the “Poll” method

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#General-Discussion>General
Discussion

   - [Apoorva] What is the guidance for implementers? Should they use the
   current Implementer’s Draft or the new draft that we will propose to become
   the next Implementer’s draft
   - [Atul] Since most implementations are starting now, and we are going
   to propose the new draft to become the next Implementer’s Draft very soon,
   we should use the new draft and not the current Implementer’s Draft
   - [Eric] Qustions about AuthZ and AuthN: The spec requires that the
   Transmitter create a stream with a unique ID, based on the request to
   create the stream. The Transmitter is expected to use the AuthN
   information. If we were to use a “client ID”, then there would need to be
   only one stream per client. If somehow the stream ID could be specified as
   a part of the Receiver Create Stream request, then
   - [Peter] An OIDC client ID should not be required to create a stream.
   - [Eric] The client ID is really the only unique identifier relating to
   the Receiver that is available to the Transmitter
   - [Apoorva] Spec today does not clarify how a Transmitter / Receiver
   should agree on a Stream ID
   - [Peter] Are all fields in the Stream Configuration required unless
   specified as optional? Would this observation apply to the entire spec?

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#Action-Items>Action Items

   - Atul to update spec to resolve issue #45
   - Atul to update the spec to resolve issue #36

<https://hackmd.io/7D09oTRhTm-yyrypScXEaQ#>
Select a repo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230606/6d8c1be7/attachment-0001.html>