[Openid-specs-risc] Call notes - 06/24/25

[Shayne Miel (smiel)]

Hi all,

Here are the call notes for today's meeting. Most decisions were captured in the related Github issues or PRs themselves. As always, notes can be found online here<https://hackmd.io/@oidf-wg-sse/wg-meeting-20250624>.

WG Meeting: 2025-06-24
Agenda

  *   Feedback received during review period:
     *   Uniqueness of stream id<https://github.com/openid/sharedsignals/issues/272>
     *   Txn value should be a string<https://github.com/openid/sharedsignals/issues/273>. Pull request created<https://github.com/openid/sharedsignals/pull/277>
     *   Editorial issues in SSF<https://github.com/openid/sharedsignals/issues/274>, CAEP<https://github.com/openid/sharedsignals/issues/275>, and RISC<https://github.com/openid/sharedsignals/issues/276> specs
     *   Documetation / clarity update for Session Established and Session Presented CAEP Events<https://github.com/openid/sharedsignals/issues/281>

Attendees

  *   Sean O'Dell (Disney)
  *   Yair Sarig (Omnissa)
  *   John Marchesini (Jamf)
  *   Tushar Raibhandare (Google)
  *   Shayne Miel (Cisco)
  *   Vatsal Gupta (Apple)
  *   Jen Schreiber (Workday)

Notes
< Stream ID >

  *   (Atul - from Email)
  *   The issue about uniqueness of stream id is important, but might require a normative change if we have to add the clarification as suggested by Tushar. We have three choices here:
-Make a normative change, and restart the review process.
-We can take the position that practically IdPs will determine uniqueness with some limitations and not add any text.
-Or we could add something to the non-normative security considerations section.
I'm slightly in favor of doing nothing (option 2 above). I think restarting the review period for this would be disruptive and probably not worth it.
-(Shayne) Agreed with Joseph on the PR that they do not need to be globally unique, but rather unique to a Tx / Rx pair.
(Shayne) Could be confusing if a stream is deleted by either party.
-(Yair) Maybe with an "existing" stream id not being re-used but deleted, not so much.
  *   (Yair) UUID might be used, so it might not be problematic.
  *   (Yair) Does not need it to be globally unique but saying it the spec would remove confusion.
  *   (Sean) re-iterated Atul's point via email (is the normative change worth it?)
  *   (George) Why not add it in Security Considerations?
  *   9.4 "Stream Identifiers" its important to realize that ID's can be re-used but should not to ensure there are no unintended conflicts.
  *   (Yair) It might put more burdent on Tx's
  *   (George) - Highlight the spec does not highlight the non-reuse of ID's for streams.
  *   If there is not a super pressing need to get to final and it is a significant security problem..start over for v1
  *   Security Considerations brings it to the implementer to be more "aware". (of the re-use…so a caveat emptor)
  *   (Sean) Agreed
  *   (Shayne) Agreed
  *   (Tushar) Agreed

< TXN as string >

  *   (Group) Makes sense

< Editorial Issues >

  *   (Shayne & Group) Pick "A SSF" or "An SSF"
  *   (Shayne) In the spec, we should only say "SSF Event" if it is a verification or status updated event
  *   (Jen) Maybe the linter caught these?
  *   (Jen) Linter looks fine

< Editorial Issues - CAEP >
(Shayne) - formatting issues
(Sean) - Make the event examples match, remove the wrapping in RISC and make them match
< Session Presented and Established wording >
(Shayne) - no new sub section needed for use cases, just add bullet points and minor verbiage tweaking.
Action Items
(Sean & Shanye) - Remove the wrapping in RISC and remove the NOTE.



[cid:d2208c2a-771e-4a9f-921e-714d4c983f38]
[https://duo.com/assets/img/email/spacer.gif]
Shayne Miel  / Principal Engineer (he, him, his)
smiel at cisco.com<mailto:smiel at cisco.com>
(919) 923-6230
cisco.com<https://www.cisco.com/site/us/en/products/security/index.html>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250624/277b783f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-2hhjsysf.png
Type: image/png
Size: 13713 bytes
Desc: Outlook-2hhjsysf.png
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250624/277b783f/attachment-0001.png>