WG Meeting: 2025-02-04

# WG Meeting: 2025-02-04 ## Agenda - What goes into v1 final? - Conformance testing update - Interoperability event update ## Attendees - Atul (SGNL) - Thomas Darimont (OIDF) - Mike Kiser (SailPoint) - Stan Bounev(VeriClouds) - Martin Gallo (Individual) - Shayne Miel (Cisco) - Aaron Parecki (Okta) - Jen Schreiber (Workday) ## Notes ### What goes into v1 Final? - (Shayne) When through the issues, and marked a few that should be in v1 - A couple of new issues have come in since then. Should we discuss whether those should be in v1 - Timeline: There was a flurry of activity before v3 was proposed for vote, so in order to keep this meeting focused, we would like that until v1 final is released, any thoughts about ths spec should be done in the issues or pull requests themselves. - Ideally your thoughts should be in the issues before we discuss them here. - (Mike) GitHub issues / PR related discussions are preferrable to posting to the mailing list, right? - (Shayne) Do we have a target date for v1 - (Atul) We will have to work backward from the target v1 date to have a target date when we propose the v1 for vote - (Shayne) A number of the issues add behaviors that weren't specified previously, should those be considered backward incompatible changes? - (Atul) We could say these are recommended, not required - (Shayne) But we specify error codes right now in the spec, but we do not say whether they are required or not. Adding another section that says "Should" would be gross - (Atul) How much should we worry about backward compatibility (I have made commitments to people to that effect) - (Mike) there are two things here: - If the language is ambiguous (e.g. the error codes in 7.1.1.1) - (Atul) Where the language exists, we could interpret it as a "must", because that is the common interpretation. - (Mike) Unless we find exceptions, we should clarify that that language is a "must" - (Shayne) The last time we did a backward incompatible change was painful. But changes at this level (adding an unspecified error code to be what people would normally do) should be allowed - (Atul) We could go either way - (Mike) The easiest way to do that could be in the conformance tests. It's also an easy way to let people in the interop know. - (Shayne) Do we have a way to mark things as deprecated? - e.g. there's a way to specify events_supported in the stream config, but now we want it in the TCM - (Thomas) One point: It'll be worthwile to have events_supported in both (metadata, and stream) because ... - (Thomas) I found another issue while working on the tests? What about inconsistencies in the spec? For example, the OpenID RISC events v1 and OpenID RISC profile use different formats. - (Mike) Is it worth flagging the issues that could require backward incompatible changes - (Shayne) I'm a little concerned that we are in a spot where the spec can never change. Could we setup something that allows us to say that this could change in the future. (i.e. deprecated, like in Python versions) - (Jen) We could have a minor version update after this - (Shayne) I think of the IDs are minor versions, and v1 etc. are major versions - (Atul) Unfortunately the stuff we specify won't be easy to change, but we can define a new version (e.g. 1.1) that has the desired qualities ### Conformance Tests Update - (Thomas) Quick update on the Conformance Tests: - The issues found during the conformance testing workshop were resolved, well plan to rollout the changes by the end of the week - New (more stable) environment available at: https://staging.certification.openid.net (requires google / gitlab.com account) - Need some additional clarification on how audience configuration should work: do we need to provide the audience during stream creation as a parameter, -> might require spec extension, see aud configuration on stream: https://github.com/openid/sharedsignals/issues/230 and related regarding aud validation: https://github.com/openid/sharedsignals/issues/207, - (Shayne) The consensus in the interop seeemd to be that the Transmitter should come up with the "aud" value. - (Thomas) But some implementations require the audience to be defined before we can create a stream - (Thomas) Then I would need to make changes to the conformance tests to allow for both possibilities - (Shayne) It cannot be defined by the receiver at the time of stream creation, this would be problematic from a security point of view - I'm currently implementing a SSF Receiver support to the Keycloak OSS Project to get a better understanding of the Receiver parts of the spec. ### Interoperability Testing Event at Gartner IAM - (Atul) Rules are linked to from the [OpenID Blog post](https://openid.net/shared-signal-wg-returns-to-gartner-iam-for-interoperability/). The rules are [here (in Word format)](https://openid.net/wp-content/uploads/2025/01/Program-Rules-London-2025-CAEP-Interop-at-Gartner-IAM-Summit-1-1.docx). - (Atul) Weekly calls begin on Thursday at 8 AM PT. Please let me know if you would like to participate. ## Action Items