Skip to content

WG Meeting 2025‐11‐04

Jump to bottom
Atul Tulshibagwale edited this page Nov 4, 2025 · 1 revision

WG Meeting: 2025-11-04

Agenda

Attendees

  • Atul Tulshibagwale (SGNL)
  • Yair Sarig (Omnissa)
  • Thomas Darimont (OIDF)
  • Kenn Chong (RSA)
  • Tushar Raibhandare (Google)
  • Sean O'Dell (Disney)
  • John Marchesini (Jamf)
  • Ashish Kedia (Google)

Notes

JWKS based Auth

  • (Tushar) Receivers calling Transmitter APIs has OAuth as a standard, which has complexities. Client IDs, scopes, admin roles, etc. Lot of setup required
    • Because OAuth is flexible, it might be implemented differently by each entity
    • When a Transmitter is calling the Receiver, we already use the idea of a JWKS specified in the Transmitter Configuration Metadata, which can be used to verify the signature.
    • What if we were to have something complementary going the other way.
    • No configuration other than specifying the Receiver URL is required. Each API call is signed using the Receiver's private key
  • (Atul) I like the idea, and it is complementary to Phil Hunt's earlier proposal that would allow Transmitters to create streams with Receivers
  • (Thomas) Would there be a well-known URL for the receiver?
  • (Tushar) Yes, we need to work out the details though
  • (Yair) This is one more authentication option. Is the proposal to replace that flexibility, or just propose it as one option
    • In the current spec, if you support polling, you never need to call the receiver. This works in the on-premise use cases where the receiver may not be reachable
    • If we do this, we will require the receiver to be available to the transmitter over the internet
  • (Sean) In some instances this abstracts it to where we can use JWT assertion grants or SPIFFE SVID JWTs
    • People are moving toward this way of doing things.
    • We need to generalize it so that these possibilities are also allowed
  • (Ashish) I see two gaps. If the spec leaves the authz / authn optional, then each receiver and transmitter will have to know something about the other party in advance. Without a stronger standard, we cannot achieve more interoperability
    • Also, there is no good way for a Transmitter to discover all receivers it can connect to.
    • We see these as blockers to future adoption.
  • (Thomas) Do receivers need to be discoverable?
    • (Ashish) Why can't transmitters discover receivers and open streams with them? A receiver can disallow a transmitter if required
      • When the identity federation is established, it can be established in either way, so why is this different
  • (Yair) We will always have a discoverability issue, because we are sending customer information
    • I agree that the handshake should be bidirectional and simpler
    • (Ashish) The handshake should be initiated on either end.
  • (Atul) 3 different concerns: Discoverability, handshake and method of authorization
    • (Tushar) we need a mechanism to discover events that receivers support

Roadmap

  • (Ashish) Perhaps we can have smaller work streams where some parties are more interested than others in specific areas
  • (Tushar) +1 to Ashish

Multi-SET Push

Conformance test update

  • (Thomas) Current conformance tests allow the configuration of an empty push authorization header

    • The implementers can get away without sending an authorization header.
    • This is wrong, because the spec requires the authorization header to be replayed
    • We have updated the test to conform better to the spec. We always generate a random push authorization header in the API to set up the stream, and we expect the header back in the push delivery. Also for "empty" (i.e. missing header)
    • This simplifies the configuration a bit and it matches the spec better
    • This uncovers an issue with the spec:
    • It says a Transmitter "must" use the header value from the stream configuration, but it does not say what to do if the header is missing.

  • (Yair) If the receiver did not ask for a header, should it not receive a header?

    • (Thomas) This is not clear in the spec. It should specify the behavior when the authorization header is not specified in the stream configuration.

  • (Atul) If the receiver doesn't specify the header, then it could still allow specific values that are agreed offline.

    • (Thomas) We could ignore it, but it might indicate a configuration error.

  • (Sean) This is less about security but more about testing. Should a receiver fail conformace testing if it accepts a non-empty authorization header when none was specified in the stream configuration?

    • (Thomas) To me and Joseph, it made sense to only accept values that we had specified, accepting random values could indicate an issue with the receiver.
    • (Thomas) It could be a warning and not an error
    • (Sean) Warning sounds right.
    • (Thomas) Created Issue 301

Steady state

  • (Ashish) Events indicate state change, once a stream is established, all future change will be transmitted. What about state that was established before the stream was created (e.g. a device was non-compliant, and never changed its state)
    • This is non-intuitive. There should be a way to synchronize the state.
  • (Atul) We need to address this, let's consider it in the roadmap discussion.
    • (Yair) This is going to be pretty complex. The receiver could be allowed to query state
    • (Atul) There could be a new API to request state of the subject (subject could be as broad as needed)
    • (Sean) Are you asking for a chronological history?
    • (Ashish) No, but its interesting to know current state for all subjects (e.g. devices)
      • This came up in credentials change as well. The receiver would like to know if an existing user has MFA setup or not.
    • (Yair) This can be a huge number of subjects / state data. This spec is about security, whereas this is a different domain.
    • (Ashish) I agree it is a different domain, but its related to making these specs effective. What you want to do based on change is dependent on the current state at the time of stream creation. E.g. if a device is non-compliant when the stream is created, then I want to immediately stop accepting it.
    • (Kenn) This should be done out of band. The change event will have information about what the event is. Then there can be another API through which we can get more information. This might not be a shared signals concern. This could be something like JIT provisioning.
    • (Kenn) It depends on the use-case.
    • (Yair) I agree, usually there is a login flow and the current state is established at the time of login. Trying to establish state at the time of stream creation would be a huge amount of data.
    • (Ashish) We do check compliance at the time of login, but at the time the stream is established, there would be a bunch of devices that are already not compliant. Future changes in compliance will generate events, but those that went out of compliance between login an stream establishment.
    • (Ashish) SCIM is a very good standard that a lot of parties have implemented, but there's nothing like that in devices. Doing it out of band makes it implementation specific.
  • (Atul) Has this been discussed in SCIM?
    • (Ashish) The SCIM folks don't see much demand for it from participating organizations, but they agree this could be a future version. It might take time though.

Action Items

Roadmap for SSF:

  • Discoverability

  • Handshake

  • AuthZ Method

  • Reconciling / "steady state" or what is the state of things whith no change events. What is the current value of this identity or device with this context? On Demand Signals vs just change.

  • Thomas to create an issue with the spec for empty authorization header value: Issue 301

Home

Meetings

Clone this wiki locally