# WG Meeting: 2025-04-22
## Agenda
- 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)

## Notes
### [Update 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 Final

### Behavior 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