# WG Meeting: 2024-05-28
## Agenda
- SSF Japan meetup
- JSON Schema-based Event Definitions ([#158](https://github.com/openid/sharedsignals/issues/158))

## Attendees
- Tim Cappalli (Okta)
- Shayne Miel (Cisco)
- Atul Tulshibagwale (SGNL)
- Apoorva Deshpande (Okta)
- Nancy Cam Winget (Cisco)
- Joseph Heenan (Authlete)
- Naohiro (OIDF Japan)
- Travis Spencer (Curity)
- Jen Schreiber (Workday)
- Nafis Zebarjadi (Google)
- Domingos (OpenID Foundation)

## Notes
### SSF Japan
- Tom joined over zoom
- Quite a special opportunity
- First SSF meetup in Japan
- Meetup was mainly for SSF
- 300 participants!
- 100 in-person
- 200 over zoom
- Tom explained from the beginning
- Lots of questions and feedback
- How to use SSF with Fido
- Many IDPs are currently implementing Fido authentication
- Tom explained the use case to indicate the assurance level
- Logging out was another question
- No one has implemented the signle-logout endpoint
- Was there any discussion about interop / the London event?
- Tom introduced it but no implementations in Japan so far.
- What would be the best way to kick-start implementations in Japan?
- Some implementers are interested in doing implementations in their IDP
- Many companies use WebEx in Japan, so if WebEx suppors SSF, then they will.
- In order to kick-start Japan, hosting an interop in Tokyo will be very good
- There is enough interest, and there is a set of tools like caep.dev, so there is an opportunity for them to work
- A number of particpants just need to understand how to implement the standard, so hearing from someone who has done it already will help
- Scheduling an interop in Japan will help.
- There are the largest banks and telcos who are interested

### Issue [#158](https://github.com/openid/sharedsignals/issues/158)
- We've talked about how to add events more easily
- It's more formal in a spec, because it was the only available option at the time
- Could we just have JSON schema files? The biggest benefit is we could version each even separately
- Explored JSON schema approach
- We can use descriptions in place of the language in the spec
- We would still need a landing page
- The event URI could refernce the schema file
- Process around adding events, which is lighter than a spec update
- We need to discuss this process with the OIDF
- The example shows how "session revoked" can be expressed as a schema
- JSON is very expressive, and accurate so developers can easily convert it to code
- (Shayne) Would the uri deference a GitHub source?
- We would need to map the path to the final schema and somehow reference the source
- (Atul) How to organize all these events?
- Have a landing page that is possibly machine readable
- (Atul) Versioning not in schema
- (Tim) We could add that to the path
- (Jen) How long would we host old schemas?
- (Tim) They would be in the GitHub repo, so they'll always be there.
- (Apoorva) Does this create a backward compatibility?
- (Tim) It actually helps because each event is versioned separately
- (Jen) Do we do semantic versioning for this?
- (Jen) This would be great
- (Jen) What about defining non-SSF schemas?
- (Tim) This is one of the benefits of doing this, that it becomes easier for others to add events
- (Atul) Normative / non-normative text?
- (Tim) The structure provides the syntactic normative information
- (Jen) We can do a lot in JSON schema
- (Apoorva) Does this mean that the SSF spec has to change everytime we change an event?
- (Shayne) No, because you could always include the spec version in the "events supported", etc. fields
- (Tim) We need to define a short spec that describes how the JSON-based events process works
- (Tim) Is there precedent to adding process in a OIDF spec?
- (Tim) But we should mainly provide language to indicate how to interpret the JSON schema
- (Tim) The event URI would resolve to the schema doc
- <more notes here></more>
- (Apoorva) We need to update the interop spec to include URNs for the events.

## Action Items from Last Meeting
- (Jen) Where is the interop spec:
- https://github.com/openid/sharedsignals/blob/main/openid-caep-interoperability-profile-1_0.md

## Certification
- (Joseph) I'm also with the OIDF Certification team
- (Joseph) We had some discussion at the end of last year about certification, but we discussed having an interop profile in order to do certification
- The certification team is waiting on the SSWG to have the profile in order to build the certification tests
- (Shayne) Do we have a timeline for the interop spec?
- (Atul) We can go to vote with ID3
- (Mike) What is the timeline for all this
- (Atul) Best case Q4 2024, worst case Q1 2025
- (Joseph) We will need more guidance than just an interop profile
- (Nancy) The SSWG will need to guide what to test
- (Shayhe) So what is the process with developing the tests?
- (Mike L) Anytime we rollout a new conformance test suite, we have offered the first 3-6 organizations a no-fee certiciations in order to solidify the tests
- Joseph will discuss with the board a time-period based "no-fee" system instead of the "first few"
- (Apoorva) Are we thinking of certifyings Transmitters and Receivers separately?
- (Joseph) SSF is different from previous certifications
- So we may have to create separate "roles" for certification
- We don't want certification tests just to have them, but they should be useful in increasing adoption
- (Apoorva) Is the certification for the product or the entity?
- (Joesph) We have two types of certifications. What does certiffying a product mean? In FAPI, Authlete, Ping, Curity have certified their products, and banks using those products are automatically certified.
- (Travis) Although there is no online certification service, you could use the certification tools in your CI/CD pipeline to constantly certify your product
- (Joseph) OpenBanking requires annual certification
-

## Action Items
- (Tim) Add a RISC example
- (Apoorva and Jen) Create a spec to describe the JSON schema and process
- (Atul) Follow up on the Txn claim addition to SSF spec with Sean
-