# WG Meeting: 2023-08-15
## Agenda
- Versioning proposal
- Remove authorization scopes / URLs from SSF metadata
- Comments in ["Sub_id" PR](https://github.com/openid/sharedsignals/pull/82/files)

## Attendees
- Atul Tulshibagwale (SGNL)
- Asad Ali (Thales)
- Steve Venema (ForgeRock)
- Apoorva Deshpande (Okta)
- Tim Cappalli (Microsoft)
- Peter Travers (Beyond Identity)
- Mike Kiser (SailPoint)
- Phil Hunt (Independent ID)

## Notes
### Versioning Proposal
- How do we document what has changed between versions?
- We can tag releases on GitHub with the changes
- The tag should say which release version of the document it refers to.
- Typically handled in non-spec output (e.g. blog posts)
- Ideally every change has an associated GitHub issue, and we can just capture the list of issues that have been addressed.
- Breaking vs. Non-breaking changes
- We could have normative text that specifies implementers should ignore any unknown additional claims
- How do we ascertain compliance?
- Breaking should imply that an existing deployment would no longer work with a newer version
- Proposed wording: "Must ignore claims or attributes that are not understood"
- Is there some reference language we can borrow?
- There's an old BCP? In the IETF
- The JWT spec has text in it.
- We had discussions about document version / protocol version correlation
- We should not do this.
- A variation of the question is: As we're iterating on a version, what do we do in the interim
- All versions in the interim (before an approved version is released) reference a same version number
- We might want to title the doc "protocol versioning"
- What does it mean to change a dictionary (e.g. the set of events described in the CAEP spec)
- Any change to a dictionary is a protocol / schema revision
- How would a Receiver know which dictionary version is supported by the Transmitter?
- Phil: just do version by dictionary, but include in each URN
- Tim: agreed, then doc can match event versions
- Tim: matches current OIDF process of being in a spec
- Also need a versioning guide (or section) specifically for event dictionaries as they differ from protocol versions
- Steve: could also have the same event listed with different versions in metadata if Tx supports two versions of the dictionary
- Steve: What if only 1 event changes in a dictionary update?
- Phil: change them all for conveinance
- Need use cases for version changes of events vs dictionary
- Tim: one question is whether rev-ing a version of an event when it didn't change is as a bad thing

## Action Items
- [ ] Atul to incorporate text from the JWT spec for specifying what is backward compatibility. Get consensus and add it to the spec.
- [ ] Steve to write up use cases for event version changes
- [ ] All: review issue #95 before next call per Apoorva's request