[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-20250422>.

Thanks to Sean for taking most of the notes and to all for participating,
Atul

-- 

 Atul Tulshibagwale

 CTO

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

---
WG Meeting: 2025-04-22Agenda

   -

   Update error table PR <https://github.com/openid/sharedsignals/pull/248>
   -

   Review status wrt Final

Attendees

   -

   Sean O'Dell (Disney)
   -

   Atul Tulshibagwale (SGNL)
   -

   Mike Kiser (SailPoint)
   -

   Thomas Darimont (OIDF)
   -

   Brian Soby (AppOmni)
   -

   Shannon Roddy (self)
   -

   Nancy Cam Winget (Cisco)
   -

   Rob Starling (Google)
   -

   George Fletcher (Practical Identity)
   -

   Shayne Miel (Cisco)
   -

   Tushar Raibhandare (Google)

NotesUpdate error table PR
<https://github.com/openid/sharedsignals/pull/248>

   -

   Is it related to the issue: ["Verification request should return a 400
   response if the stream is not enabled"]
   -

   (Atul, George Sean) debating error codes opposed to 400 versus 406 and
   debating backwards compatibility versus introducing a new error code
   -

   (George) Response Code and RESTful response versus parsing reason phrase
   -

   (Atul) maybe add 406 error code as new but allow 400
   -

   (George) Ok with either and a 406 could be used to process the
   createStream event (that it is not supported)
   -

   (Rob) Should we change the error codes or should we say there is a
   machine readable detailed error format.
   -

   (Atul) Just settle abiguities and how to address them. Cited more
   abiguous examples to this related PR.
   -

   (Rob) If wanted to make it richer explore more options
   -

   (George) Question we should ask is do we think there is ambiguity in the
   error response and adding new groups of SET's for domains will it create
   ambiguity does having more error structure/mechanisms make sense?
   -

   (Atul) During implementations so far this is what we have seen so far
   these are the ambiguities we have seen. It becomes more complicated with
   structured errors with interoperability.
   -

   (Multiple People) talked at the same time :)
   -

   (George) Systems will continue to do what they need to do regardless of
   being on ID1 v ID3 and the interoperability aspect might be less important.
   Would a processing structure be needed for v1 final vs ID1 or ID3.
   -

   (Shayne) We want to give some wiggle room here. Errors "should" be
   signaled versus "must"…not as forceful.
   -

   (Rob) For interops how much are error codes being used for interop tests?
   -

   (Thomas) Conformance suite does check for error codes
   -

   (Rob) might not break everyone that is "live"
   -

   (Sean) I know for stream creation we use reason phrases internally.
   -

   (Rob) What is the media type?
   -

   (Sean) We use different status codes (e.g. I'm a teapot)
   -

   (Sean) Based on the stream response you could disambiguate. You can look
   at the metadata and determine why it failed.
   -

   (Atul) One of the criticisms is that we are not getting to final fast
   enough…is this important enough to deliberate on?
   -

   (Sean) I'd just introduce a new status code and allow Transmitters to
   send the existing code (400).
   -

   (Jen) I can update the spec.
   -

   (Atul) Jen can create a separate PR to address the Verification status
   code issue 214 <https://github.com/openid/sharedsignals/issues/214>, and
   Apoorva or Jen can update the existing PR.
   -

   (Sean) So we will incorporate the comment from George
   <https://github.com/openid/sharedsignals/pull/248#issuecomment-2819549986>
   (add status 406), and keep it backward compatibility.

other notes

(https://github.com/openid/sharedsignals/issues/214)?
- But it is in the "create stream" section, not in the verification
section. Apoorva's comment
<https://github.com/openid/sharedsignals/issues/214#issuecomment-2734045078>
says "he's working on this", but doesn't mention PR.

   -

   (Atul) Review (https://github.com/openid/sharedsignals/issues/250) newly
   opened up Issue.
   -

   (Atul) Review (https://github.com/openid/sharedsignals/issues/245) to
   more than just Atul, so we can close
   -

   (Atul) Review (https://github.com/openid/sharedsignals/issues/222) to
   Tushar
   -

   (Atul) assigning 127 to Jen
   -

   (Atul) 127 to include a payload with more information with the error
   -

   (Jen) ignoring payloads from previous issues.
   -

   (Shanye) agrees to ignore payload

Review status wrt FinalBehavior when a stream is paused or disabled

   -

   For poll streams and the Receiver polls
   -

   For all streams, when the receiver requests verification
   -

   (Jen) What has everyone done in their implementations
   -

   (Shayne) We just ignore requests on paused streams, like any other event
   in a paused stream (the spec doesn't specify the behavior)
   -

   (Atul) So may be this is the behavior we go with
   -

   (Sean) For disabled streams, we return a 403 status code
   -

   (Jen) would also like to know if a stream is disabled
   -

   (George) treating disabled as a different semantic as paused and wanting
   clients to understand this.
   -

   (George) If I were writing this and got a 403, I wouldn't retry ever,
   because it is forbidden.
   -

   (Shayne) The point of the verification request is to distinguish between
   the case where the events aren't flowing (i.e. there just haven't been any
   events) and the events cannot flow (by policy).
   -

   (Atul) event could not be flowing because ther aren't any events or
   external problems or the Tx is in a state where it is forbidden from
   sending any events.
   -

   (Shayne) - Makes sense.
   -

   (Atul) - There is a certain behavior for polling streams. Do we indicate
   when the stream is paused?
   -

   (Shayne) - No.
   -

   (Shayne) - Verification Requests and Polling to a question from Rob.
   -

   (Rob) spec is pretty clear its a non-error answer.
   -

   (Atul) where did you see that?
   -

   (Rob) its not explicit.
   -

   (Atul) have to make sure we are referencing the same draft/version.
   -

   (Rob) so Draft 3 is ID3
   -

   (Atul) This is the working draft which will become 1.0 Final
   -

   (Sean) Maybe update language in 6.1.2 about expected behavior on paused
   streams.
   -

   (Atul) Not a must but just language indicating expected behavior.
   -

   (Rob) Look at section 8.1.2
   -

   (Shayne) This holds true that you queue up events and/or hold the most
   recent one.
   -

   (Rob and Shayne) disabled should not indicate an error message
   -

   (Atul) Concluding the discussion for now for lack of time.

Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250422/041fb332/attachment-0001.htm>