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

Please note: No call next week (3/25) due to Gartner IAM. I won't be able
to host on April 1st either, but if one of the other co-chairs is
available, we can have the next call on April 1st.

Thanks,
Atul

-- 

 Atul Tulshibagwale

 CTO

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

---
WG Meeting: 2025-03-18Agenda

   -

   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)

NotesPR 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250318/c7614897/attachment-0001.htm>