---
# System prepended metadata

title: 'WG Meeting: 2022-'

---

# 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
- 