[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Thanks for attending today's meeting. Here are the notes. They are also
stored here <https://hackmd.io/@oidf-wg-sse/wg-meeting-20240514/edit>.

WG Meeting: 2024-05-14
Agenda
SSF spec timeline
Attendees
Atul Tulshibagwale (SGNL)
Shayne Miel (Cisco)
Chelsea Munk ()
Alex Ilie (VeridiumID)
Jay Leslie ()
Jen Schreiber (Workday)
Mohammad ()
Sean O'Dell (Disney)
Steve Venema ()
Todd Meyer ()
Yair Sarig (VMWare)
Notes
SSF Spec Timeline
(Shayne) Try to get a v1 spec by the end of the year

In order to do that we need to get to a release draft by ?
We did not want to make changes, but there are a few security issues
pointed out by the Stutgart researchers
Because these are normative changes, we will make a few outstanding changes
Not going too wild with the changes
None of the changes are unlikely to break existing implementations, but
after digesting all the security issues, something might come up
Try to get to a draft 3 by June 15.
(Todd) Shayne, could you please outline the security issues raised?

(Shayne) One issue is that we did not make certain parts mandatory, some
usage could create some security gaps, so we need to specify that

E.g. when a stream is created, we do not mandate authorization
In general it does not appear to be threatening
(Sean) If you allow anonymous add subject…
(Yair) There's a topic Issue #163, that would be a breaking change from
draft 2.
(Atul) If we added something to the Transmitter metadata to indicate their
default behavior, then it won't be a breaking change
(Yair) agreed
(Sean) Not allowing a transmitter to send upon a receiver being configured
might break bacwards compatibility.
(Shayne) There's nothing in the spec that says only the receiver should
call the stream "add subject" endpoint.
(Yair) Likes Atul's suggestion for the default behavior of the transmitter
with subjects.
(Atul) Not sure what is to be gained by adding a subject in the stream
creation call
(Sean) We have also had a conversation about wildcards in subject Ids
(Yair) We should add an example in the spec for the default behavior of
various transmitters.
(Atul) Adding a txn claim

(Sean) The txn claim is needed when you want to prevent multiple events
about the same initial event
(Sean) We can close the loop with certain events, e.g. Tx A went to Rx B,
and then Tx B went to something else in relation to the same event
(Sean) It should not be required, it should be optional
(Sean) It's already in RFC…
(Shayne) If it's already optional in the SET spec, do we need to say
anything? Just include it in the examples?
(Sean) I was just going to include it in the examples
(Atul)
(Sean) Session revoked might need to specify it as a mandatory
(Shayne) This shouldn't be in the events, it should be in the top-level spec
(Shayne) We can't say it is mandatory only for "session revoked"
(Steve) Sean's example of the ledgering is applicable to all types of
transactions or is it just one-way?
(Sean) The ledger is interesting and you can use it to close the loop.
(E.g. session revoked back and forth)
(Jen) Would you want to specify "jti" per transaction?
(Atul) It would need to be unique per event
(Jen) We should keep in mind when we are adding the language to specify how
it is different from jti
(Sean) The complex subject definition in the SSF spec doesn't specify that
the subject is "AND" of all complex subject members, it should specify that
more clearly (language in section 3.3.1 needs to be improved)

(Shayne) When we update this language, we should also clarify the wildcard
nature of the complex subject members
(Jen) Does SSF specify that a SET must include only one event? (10.1.7)

(Shayne) Section 10.1.7 seems to say that
(Jen) When would you want different URIs for the same event?
(Sean) Let's say internally you use a different URI, and externally you
have another event?
(Jen) The language is confusing
(Atul) Agree
(Atul) The language also seems to allow multiple different event
definitions when using different URIs, we should not allow that
(Yair) One might have more information than the other, but they may be the
same event
(Shayne) If we really want to restrict it, we should ideally change the
data model.
(Yair) We could start supporting "event"
(Jen) That would be a big change
(Atul) I won't want to do that because it is a big change
(Atul) We should update the language to permit only one event in an "events
claim"
(Atul) Should we move to a weekly cadence until we have 1.3

(Steve) STan had brought up the timeline for the RISC spec as well.

(Sean) We can talk about it in the beginning of the next call.

(Atul) Should we discuss the time for the in-person meeting on email /
slack?

Action Items
Possibly add a metadata configuration parameter with default behavior?
Jen to draft the PR for making the language change to only allow one event.
Sean to draft the PR for the txn changes
Sean to update the language in section 3.3.1 for clarity
Atul to follow up with Mike L for the new meeting invites
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240514/7b5c7daa/attachment.html>