WG Meeting: 2023-10-03

# WG Meeting: 2023-10-03 ## Agenda - [Versioning update](https://github.com/openid/sharedsignals/issues/124) - When do we vote on this draft? ## Attendees - Atul Tulshibagwale (SGNL) - Yair Sarig (VMWare) - Tim Cappalli (Microsoft) ## Notes ### Versioning - (Tim) It's surprising we need to address this before we get to a final spec - (Atul) A little bit of work can help exisitng implementations adhere to standards - (Yair) The examples mentioned are extensions, and not a part of the core spec, so I'm not sure the example applies. - (Atul) Although the examples are non-core to OAuth, the mechanism for indicating features in metadata can address the issue - (Tim) Using feature names is going to require a lot of thought. - (Yair) Agree. How will we come up with these names - (Atul) I don't have an answer to that - (Yair) It's not just coming up with a name, it is what does it mean - (Tim) E.g. in "sub_id at top level" - (Tim) We should come up with a pattern, either descriptive names or boolean variables, and what are the defaults - (Atul) I can create a PR that takes the "boolean" approach - (Atul) to address Shayne's dependency question: It should be the Transmitter's responsibility to create consistent metadata that doesn't contradict itself. - (Tim) We could use version numbers for core features and use feature flags for optional features - (Tim) We can introduce an object in the metadata that lists the features that the Transmitter does not support - (Tim) Why not introduce a "spec_version" claim in the Transmitter Configuration Metadata that just has the proposed version number of ID2 (i.e. "1_0-ID2") - (Yair) The spec already has ways to indicate which optional features (e.g. status endpoint) are supported ## Voting on Current Draft - (Tim) We should just announce on the list that we are at a cutoff point for the ID2. - ## Action Items - Atul to write PR to incorporate "spec_version" in Transmitter Configuration Metadata - Tim to post an update with mention of the spec version issue (and any way in which the spec may be inimplementable)