# WG Meeting: 2024-08-13
## Agenda
- Reminder to vote
- Gartner interop update
- Any other business

## Attendees
- Atul Tulshibagwale (SGNL)
- Dean Saxe (Beyond Identity)
- George Fletcher (Capital One)
- Shayne Miel (Cisco)
- Apoorva Deshpande (Okta)
- Stan Bounev (VeriClouds)
- Alexey Yemelyanov (WinMagic)
- Rajvardhan Deshmukh (Cisco)
- Kartik Patel (Omnissa)
- Steve Venema (Microsoft)
- Swathi Kollavajjala (Cisco)
- Tim Cappalli (Okta)
- Yair Sarig (Omnissa)
- Sean O'Neill (Easy Dynamics)
- Jen Schreiber (Workday)

## Notes
### Vote on the drafts
- [Vote here](https://openid.net/foundation/members/polls/334)

### [PR 195](https://github.com/openid/sharedsignals/pull/195)
- (Shayne) We added a `description` field to the metadata, but did not add an explanation / list it as a receiver supplied field
- Earlier in the spec we say it is a receiver supplied field
- (George) The current vote is for an implementer's draft. We shouldn't change it in the middle of the implementer's draft vote
- It doesn't change the protocol
- You can change it before voting on final
- The process allows for making additional WG drafts without having to go through an "implementer's draft" approval before becomign final
- (Atul) I agree we can change it after the vote concludes
- (Shayne) Makes sense

### Gartner interop update
- For those who have indicated interest, please join the Google Group here: https://groups.google.com/g/ssf-interop-dec24/

### JSON Schema for Event Types
- (Jen) I have worked on the JSON schema, how to progress
- (Jen) How do I work with Tim and Apoorva?
- (Apoorva) Zoom or Slack works best
- (Tim) There is a group chat on Slack
- (George) What specific event types are we talking about?
- (Jen) We are talking about defining event types with a JSON schema, rather than having profiles for each event type
- (Dean) That would allow me to define event types for my partners without publishing it?
- (Jen) yes...
- (Tim) I'd like to clarify that the "spec format" doesn't work for discreteley defining events, with the onerous process for getting specs approved
- (Dean) Then it is about speeding up the efficacy of defining the events without going through the longer process
- (Tim) Three objectives:
- Faster process
- More appropriate format to describe
- Less interdependencies
- (George) So does this make the creation of events not provide you a context for it?
- (Tim) They are self-encompassing - the semantics will be defined in the JSON document. It just puts the description in a different spec
- (George) But we have a process to define and review events (describing the events and processing of each event)
- (Tim) Each event today has description and semantics associated with it, these will be captured in the JSON schema
- (George) So would the schema be flat or hierarchical?
- (Tim) The current names are an artifact of a document, they don't have to be that way
- (George and Dean) We would like to be involved in this activity
- (George and Dean) Review of the spec that describes the process as well as the schema are both interesting to us
- (George) One more thing we might want to do is that the eKYC and ID Assurance also have JSON based specs, so as we think about process for the OIDF, it will be useful to connect with those groups and define something global for these things
- Relying on GitHub and GitHub actions only won't work for the OIDF
- (Tim) let's discuss this in the main channel then
- (Atul) My preference is to use the mailing list because it is available online and archived

## Action Items
- Tim to add George and Dean to the slack group for JSON schema based events