[Openid-specs-risc] Call notes
Atul Tulshibagwale
atul at sgnl.ai
Tue Nov 4 19:06:28 UTC 2025
Hi all,
The notes from today's SSWG call are here:
https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004
They are pasted below for convenience.
Thanks to all those who participated,
Atul
--
Atul Tulshibagwale
CTO
<https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
--
WG Meeting: 2025-11-04
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#wg-meeting-2025-11-04>
Agenda
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#agenda>
- JWKS based Auth instead of / in addition to OAuth
<https://github.com/openid/sharedsignals/issues/299>
- Multi-SET Push
- Conformance Tests Changes (Auth header for Push)
- Signals signify change. What about steady state
Attendees
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#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
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#notes>
JWKS based Auth
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#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
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#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
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#multi-set-push>
- Multi SET Push Draft
<https://www.ietf.org/archive/id/draft-deshpande-secevent-http-multi-set-push-00.html>
- Please review and email: saag at ietf.org with your comments / usefulness
of the draft
Conformance test update
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#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
<https://github.com/openid/sharedsignals/issues/301>
Steady state
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#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
<https://github.com/openid/sharedsignals/wiki/WG-Meeting-2025%E2%80%9011%E2%80%9004#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 <https://github.com/openid/sharedsignals/issues/301>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20251104/b6c42cf3/attachment-0001.htm>
More information about the Openid-specs-risc
mailing list