[Openid-specs-risc] Call notes

Tue Aug 1 23:59:13 UTC 2023

Hi all,
Notes from today's working group call are here. They are also stored here.

Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>
WG Meeting: 2023-08-01
<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#Agenda>Agenda

   - (tim) GitHub configuration and hygeine
   - What should happen when only one stream is allowed? PR 50 discussion
   <https://github.com/openid/sharedsignals/pull/50/files#diff-193e4a2db2f645f1b4f19c4a9f8facbef29f86e122a8da4c529542750a291a1c>
   - (smiel) Why do we have a format field in the Stream Configuration? PR
   87 discussion
   <https://github.com/openid/sharedsignals/pull/87#discussion_r1276951345>
   - (atul) Review breaking changes in current draft

<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#Attendees>Attendees

   - Atul Tulshibagwale (SGNL)
   - Shayne Miel (Cisco)
   - Tim Cappalli (Microsoft)
   - Apoorva Deshpande (Okta)

<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#Notes>Notes
<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#Github-Configuration-and-Hygiene>Github
Configuration and Hygiene

   - (tim) Anyone who has a signed IPR can be a part of “members”, and they
   should be able to branch
   - (atul) Main branch is being used for the GitHub pages, so we don’t
   need additional protection there.
   - (tim) Who is “amali90”? We should only add users who have a properly
   populated GitHub profile
   - (shayne) What was the pull request from Gilbert Aguerdo. Who is that
   person?
   - (tim) I’ve turned on “resolve all comments”

<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#What-should-happen-when-only-one-stream-is-allowed-PR-50-discussion>What
should happen when only one stream is allowed? PR 50 discussion
<https://github.com/openid/sharedsignals/pull/50/files#diff-193e4a2db2f645f1b4f19c4a9f8facbef29f86e122a8da4c529542750a291a1c>

   - (smiel) Tim’s original proposal was that the Transmitter should
   respond with a 200 OK
   - (smiel) But what happens if the Receiver tries to create a second
   stream with a Transmitter that only supports a single stream?
   - (atul) IF the Transmitter returns the same Stream ID, wouldn’t the
   receiver know it’s the same stream?
   - (apoorva) +1
   - (smiel) The Receiver may not have the other Stream ID lying around
   - (atul) This could lead to Receivers being unaware of events being sent
   to them (if there are multiple apps within the Receiver)
   - (smiel) What if the Receiver crashes and reboots?
   - (atul) The Transmitter will keep trying to send the events until
   they’re acknowledged, so no events will be lost.
   - (smiel) What if the Receiver asks for a different delivery method when
   it re-creates the stream?
   - (atul) Because the Transmitter is not creating a new stream, it should
   return the stream config as it created the first time.
   - (smiel) OK
   - (tim) The 200 OK is problematic because that is not what the calling
   party requested
   - (atul) The Transmitter could return a “Forbidden” status, but still
   provide the same stream configuration
   - (tim) Transmitter could return a 205 (Reset Content)
   - (smiel) I’d suggest we just throw an error - some 400 error, but not
   do anything to the existing stream
   - (atul) I’m OK with that
   - (aproova) We will break idempotency because of this
   - (atul) But is Create Stream expected to be idempotent?
   - (smiel) No.
   - (smiel) I would suggest status 409 (Conflict)
   - (smiel) Apoorva said that this indicates that the user could do
   something to fix it, which is still the case
   - (apoorva) 409 indicates that if you change the request inputs you
   should get a different response
   - (smiel) I don’t see that expected behavior documented anywhere
   - (atul) How about 400 (Bad request)
   - (tim) This could be on a per-receiver basis - a Transmitter could
   allow multiple streams for one receiver, but not for another
   - (smiel) How about 501 (not implemented)?
   - (atul) +1
   - (tim) What is our expected behavior?
   - (atul) The client should get an error, because it has a wrong
   understanding of what the server can do (i.e. create multiple streams)
   - (tim) Does a single-stream transmitter still have stream Ids?
   - (smiel) yes, and you can even delete and create the stream again
   - (tim) why would you create the exact same stream
   - (atul) The Transmitter has an obligation when the stream is present
   - (smiel) As a Receiver, you should check for the existing code first,
   and then try to create a stream
   - (smiel) What if you are tyring to create a new stream that is
   identical to one that exists before?
   - (apoorva) Why can’t the Receiver call a Get first and then do a Create?
   - (smiel) Because the Receiver does not have any way of knowing whether
   the Transmitter supports multiple streams
   - (atul) Giving a clear error is the right thing to do here
   - (tim) 422 looks like the best option
   - (apoorva) What are we trying to achieve with this?
   - (smiel) If the Receiver depends on multiple streams, then then they
   can’t do anything because the Transmitter doesn’t support it.
   - (apoorva) How would the Receiver self-remediate
   - (atul) Receiver could delete the existing stream and create a new one
   - (atul) Or it can do a “Get” to get the existing stream
   - (smiel) If the Receiver was trying to create a stream with different
   properties, it would need to delete and re-create
   - (tim) Good Stack Overflow discusson on 409 vs 422
   <https://stackoverflow.com/questions/3825990/http-response-code-for-post-when-resource-already-exists>
   - (atul) That seems to argue for 409 (Conflict)
   - (tim) I’d vote for 409 after reading this
   - (atul) Me too
   - (smiel) +1
   - (apoorva) that works
   - (smiel) So any request to create a second stream (regardless of
   whether it matches the first stream or not) in a single-stream transmitter
   results in a 409
   - (apoorva) Existing spec says 403
   - (apoorva) I’m good with 409
   - (everyone else) good

<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#Misc>Misc

   - (tim) We should create an OpenAPI 3 spec
   - (apoorva) sharedsignals.guide has the spec, it just needs to be
   updated.
   - (tim) Can we host the spec file in an OpenID repo so that we can issue
   pull requests on it?
   - (atul) Would Cisco consider contributing that to the OpenID Foundation

<https://hackmd.io/8nkgc3QtSY23IWUZWJAK7A#Action-Items>Action Items

   - (atul) Merge Apoorva’s PR
   <https://github.com/openid/sharedsignals/pull/89>
   - (tim) Update PR to specify response to Create Stream in single-stream
   Transmitters
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230801/af30fd30/attachment-0001.html>