[Openid-specs-risc] openid/sharedsignals: New Issue opened

github at oidf.org github at oidf.org
Tue Oct 7 23:53:27 UTC 2025


openid/sharedsignals event

Issue opened
Issue Title: JWKS based Auth for Receivers instead of OAuth
https://github.com/openid/sharedsignals/issues/299

Starting a discussion to focus specifically on simplifying the auth story of Receivers calling Transmitter endpoints. I believe an equivalent story for Receivers, as we have for Transmitters (sending signed events + signature verification using public key), would make interop seamless. From https://github.com/openid/sharedsignals/issues/298#issuecomment-3378688175 > Even just putting a `jwks_uri` in the Receiver's _.well-known_ configuration will be a great benefit - since it trivializes auth completely. > > Today, the recommendation is to use OAuth with scopes like ssf.manage and ssf.read. But that means the Administrator must explicitly grant permissions to access the Transmitter endpoints, and that the Receiver must generate/request appropriate tokens. Which increases friction and interop burden. > > Now imagine if Receivers published a `jwks_uri`: > > 1. Admin configures the Transmitter jwks_uri (via .well-known) in the Receiver Admin Console. > 2. Admin configures the Receiver jwks_uri (via .well-known) in the Transmitter Admin Console. > 3. Trust is thus established. > > * Just like how the Receiver verifies the signature of SETs sent by the Transmitter, > * The Transmitter can verify now that a Stream Management request is coming from an Admin-registered Receiver. > > (Note: Signing details need to be hashed out)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20251007/f611b7cd/attachment.htm>


More information about the Openid-specs-risc mailing list