# WG Meeting: 2025-03-18
## Agenda
- [Charset restriction on stream id](https://github.com/openid/sharedsignals/pull/242)
- Format of Conformance test output
- [Supporting multiple versions of the spec](https://github.com/openid/sharedsignals/issues/241)

## Attendees
- Atul Tulshibagwale (SGNL)
- Apoorva Deshpande (Okta)
- Tushar Raibhandare (Google)
- Swathi Kollavajjala (Cisco)
- Thomas Darimont (OIDF)
- Elizabeth Garber (OIDF)

## Notes
### PR 242
- Fix format
- Although change is normative, it is what everyone would have done, so it is good to be included

### Conformance test output
- (Atul) Can it be made easier to share
- (Thomas) The requirement is good, we don't have anything right now, but we can look into it.

### Issue 214 (Verification request should return a 400 response if the stream is not enabled)
- (Apoorva) We should not have a error code that is tied to the status of the stream
- (Atul) How about 403?
- (Swathi) 403 would not be appropriate, because it represents an authorizaiton issue. 400 is better because it is a bad request
- (Apoorva) We should not add this status dependency.
- (Atul) I am OK with not including this change in final, because it doesn't look like implementation feedback
- (Swathi) If we are not returning a response to the caller, then the receiver will not know for a while that something is wrong
- (Tushar) We also have 404, so we are responding differently based on the stream status
- (Apoorva) 404 is OK because we have the stream id, and if the resource is not available, then a 404 makes sense

### Supporting multiple versions of the spec
- (Swathi) If we have one customer on draft 1, and another is on draft 2, then we need to set up different instances of the service. There doesn't seem to be a way to support multiple versions of the spec with the same endpoint.
- (Apoorva) I'm strongly against taking this because it will break backward compatibility
- (Apoorva) Going forward, I support removing the metadata version from the metadata
- (Swathi) The proposal will be backward compatible, but if we remove the spec version, then how would the receiver know which version the transmitter is supporting.
- (Swathi) The problem with the spec right now is that the transmitter cannot setup a stream of a specific version without manual intervention. When we advance the spec to v2, and I am already supporting multiple customers on v1, then how do we support both set of customers
- (Atul) The metadata can support multiple versions using paths
- (Swathi) But the receiver won't know which path to go for to begin with
- (Apoorva) That's a different intention of the headless configuration, because we anyway need to put the configuration url. We support ID1 and ID3 receivers in production today
- (Atul) We do not have a way to discover transmitters automatically today. The Receiver needs to know the URL in advance, and they can then find the appropriate version number
- (Swathi) When Apoorva says that they support two versions, how do you construct the metadata? How does the receiver know which version to use?
- (Apoorva) "subject" and "sub_id" are not compatible. However, is this needed practically? New implementers should always start at the highest version?
- (Tushar) IMO not changing the URL will require transmitters (and receivers) to be super smart, and possibly won't be able to figure out which version to use. So keeping the same URL might be an anti-pattern
- (Swathi) I'm proposing that there should be unique URLs for metadata, but the well-known config will be the same. If we give this one metdata URL to the customer
- (Apoorva) With this approach, the receiver would have the burden of knowing all versions.
- (Atul) This might be something we take up after v1 Final.

## Action Items
- (Atul) To propose removing "v1Final" from Issue 214 (Verification request should return a 400 response if the stream is not enabled)