[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
The notes for today's call are stored here. They are pasted below for your
convenience.

Thanks to all who participated,
Atul

---

WG Meeting: 2026-06-23 <#Agenda>Agenda

   - Interoperability profile to final:
      - Review open issue: Authorization Code Flow
      <https://github.com/openid/sharedsignals/issues/308>
   - Certification launch updates:
      - Testing updates
      - SCIM Events in tests issue
      <https://github.com/openid/sharedsignals/issues/336>
      - Other updates from Thomas
   - Review proposed changes
   <https://github.com/openid/sharedsignals/pull/329> to the device
   compliance event
   - New device events proposal

<#Attendees>Attendees

   - Atul Tulshibagwale (CrowdStrike)
   - Thomas Darimont (OIDF)
   - Yair Sarig (Omnissa)
   - Sahil Mukhija (CVSHealth)
   - Apoorva Deshpande (Okta)
   - Martin Gallo (Independent | AuthMind)
   - Sean O'Dell (CVS Health)
   - Debayan Basu (Independent)
   - Matt Topper (UberEther)
   - Thi Nuyen Huu (WinMagic)
   - George Fletcher (Independent)

<#Notes>Notes <#Conformance-testing-updates>Conformance testing updates

   - (Thomas) Some vendors were testing SCIM events, which we have now
   added to the tests
      - Added SCIM events as known-SSF events to the SSF Transmitter tests,
      such that we no longer issue a warning on those events as unknown
   - (Thomas) A couple of vendors and caep.dev have tested
   - (Thomas) We added support for the client credentials grant for the SSF
   receiver tests
   - (Thomas) Updated the demo system with latest fixes
   https://demo.certification.openid.net/
   - (Thomas) Tested Transmitter tests and Receiver tests with each other,
   and it works.
   - (Thomas) Some vendors have limitations: E.g. reading the current
   stream status and reading the current stream configuration. Both are
   required by the interop profile
   - (Thomas) Please email me the test results / test plan that you created
   with your implementation, and we can update our records to meet the launch
   criteria of 3 successful Transmitter and 3 successful Receiver
   implementations
      - Please provide feedback with a link to the created testplan to me
      via thomas.darimont at oidf.org
      - I'll then compile a list of the testplan results in a sheet and
      share it with the group
   - Please try the following tests (Version 5.1.45+)
      - OpenID Shared Signals Framework 1.0 Final/CAEP Interop Profile:
      Transmitter test
      - OpenID Shared Signals Framework 1.0 Final/CAEP Interop Profile:
      Receiver test

<#Interop-spec-to-final>Interop spec to final

   - (Atul) Since we have closed the last issue, does anyone have concerns
   with proposing this draft as the final?

<#Updates-to-Device-Compliance-Change-event>Updates to Device Compliance
Change event

   - (Yair) The existing Device Compliance Change event doesn't have a way
   to tell the receiver if a device has come under management.
      - Only devices that are managed can report compliance events
      - The proposal is to make the "current status" and "previous status"
      optional
      - It also adds "managed" and "non-managed" as statuses

<#New-event-proposed-by-WinMagic>New event proposed by WinMagic:

   - (Thi)
   - (Sean) Gary reached out to us about this almost a year ago @zirotrust
   - (Sean) Issue 337 feels more like Session Established
   - (Sean) The endpoint here, is the decentralized IdP and it pushes it
   out to be device specific and saves on one more hop where "session" here is
   very overloaded
   - (Sean) Thanks for contributing. Gary and I spoke about a year ago
   about it.Atul and I discussed this on Slack too.
   - (Sean) This belongs more in the "session established" event, versus
   device compliance change event.
   - (Sean) This is interesting because the IdP is …
   - (Sean) We were missing the session on the endpoint, and this makes a
   lot of sense.
   - (Sean) This puts us in a place where we can look at personal acces
   tokens and don't need to go back to the IdP at all.
   - (Thi) We provide the local identity from the endpoint. It can take
   care of a bunch of things, I propose CAEP as the long-term "rare signal"
   action
   - (Thi) We need CAEP to be more active with this
   - (Yair) Thanks for the presentation. Just wanted to point out the
   volume impact.
   - (Yair) Every device, every day, and lots of events b/w Tx and Rx and
   might prove to be costly in the system. When you talk about this number of
   events it getst complicated.
   - (Atul) CAEP, envisioned, there would be millions of events. If you
   look at both session presented and established it will be super chatty. We
   should not be afraid of catty events b/c of the stream setup and
   negotiation the receiver has the power to say what it wishes to be
   subscribed to.
   - (Atul) This should not impact or affect the protocol..
   - (Thi) The event can go to the hub and the sp can take care of it. Is
   there value in this?
   - (Sean) Yes
   - (Atul) Throws shade at Thi (j/k) wait more have to talk
   - (George) THere is a high amount of trust placed on the device, which
   is unique. This change in modality is important for scenarios and an attack
   vector. Asserting the device is legit and the user is logged in… becomes
   another event from teh security system, but the eventing could have your
   Access Token be static on delivery and you trust the device…then the
   session is established. When locked the device becomes the transmitter to
   inform the server on state change. THis is more about the how you do it and
   orchestrate it. HOW do you actually trust the device.
   - (Thi) Can you trust the endpoint? made a reference to passkeys
   trusting the endpoint based on the TPM. It is based on this and only
   created when a user logs into the endpoint. Becuase it is HW aware you can
   kind of trust it that only the endpoint can do that. So, when it is
   provisioned by the business -> you can trust it because it can only proved
   that/it's key. He strongly believes that the endpoint is the one you should
   entrust.
   - (George) The key thing here is to define the threat model…for the
   device.
   - (Apoorva) This might take us into sharing raw signals. This feels like
   inventory syncing. Users getting a new role, losing a role. Can this be
   solved in device inventory syncing? This probably adds to it. Millions of
   events…we dont take an SLA stance on that, but maybe we should?
   - (Atul) I always imagined this event could come from a device mgmt svc
   acting in conjunction with the device with similar telemetry.
   - (George) If you are going to trust the device its a different way of
   encapsulating it. It might not matter too much.
   - (Atul) We dont know how to scale the trust between the Tx and Rx,
   right now. Maybe its nothing, maybe its something? Re: Apoorva's comment -
   this might be a lower level signal but that is ok and it might affect or
   impact your session properties. So the use cases presented by WinMagic
   feels correct. There are use cases for this. It is a blind spot that
   becomes very interesting in these scenarios. We do not need to worry about
   the scale, if you do not want them do not subscribe to them.
   - (Yair) We do device management. Imagine if someone from a phone and
   done a login session, if they lock the phone for a few minutes, then the
   device will send a signal. There will be some time delay between the device
   getting unlocked and the user doing some action, but in this case it can be
   immediate. This feels like it will require a new level of real time
   response than before (Apoorva agrees)
   - (Yair) Not sure how this discussion relates to the device management
   discussion
   - (Thi) Screen lock is a different use case. This event should not be
   generated as a result of screen lock. The screen lock is less important
   than turning off the device
   - (Sean) Apple TVs issued to a number of users. Session established /
   presented / revoked were used in that scenario and it worked well. The user
   had to login only once. Once you had that and the session established /
   revoked events, they never needed to login again.
   - (Sean) The trick is in the scale. But with AI everyone has to worry
   about scale. This has huge implications on AI
   - (Thi) We tend to do this, and everyone should. The identity is the
   user + the device + the conditions of access. For us, for online access,
   this is important. It also applies to workloads and AI agents. Only the
   actor on the node should be able to perform actions. No one can fake the
   node.
   - (Sahil - in notes) We should also consider device health scenarios,
   especially when a new device is being onboarded, and establish clear
   semantics for missing signals: does no signal indicate a healthy state, an
   unhealthy state, or an unknown state requiring further validation?
   - (Apoorva) I brought up the device managed signal in this, because we
   could combine these signals. If we decide to bring this in, we should
   consider building a device signals dictionary.

<#Action-Items>Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260623/d4f1ec8b/attachment-0001.htm>