Well Known Configuration for Receivers

[ashish1294]

We have well-defined configuration metadata for transmitters :

https://openid.net/specs/openid-sharedsignals-framework-1_0.html#name-obtaining-transmitter-confi

But nothing equivalent exist for receivers. There are few usecases for this :

1. Non-existence of such config somewhat forces integration to begin on receiving partner. In a truly interoperable world, transmitting partners could also "discover" new receiver and metadata about it and configure a stream on behalf of receiver.
2. Even when integration starts on receiving partner end, transmitter may want to use some public data about the receiver (e.g, public part of cryptographic key) to verify that the stream creation API was truly invoked by the well known receiver.

Some useful things that we might want to put in receiver data :

1. Auth protocols (potentially public keys ?)
2. Endpoint URL to where transmitters can send new stream configs to in case they create a stream on-behalf-of receiver.
3. Data transmitter can use to create credentials on behalf of receiver for future pulls or stream management

[appsdesh]

Linking my comment from the past issue related to this ask

[traib-google]

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)

[ashish1294]

As discussed in the WG sync, here are the use-cases from Google to do this :

[Adoption Blocking Use-cases]

1. Currently in order to configure a stream, a customer has to operate portals for both receiving and transmitting partner. This is a major adoption blocker - as multiple UX studies conducted by Google has revealed that many of our customers who want to enable SSF don't have working knowledge of both partner portals. We would like a one-click experience for onboarding and as part of that we would like to provide all data necessary to create a stream in well-known receiver configuration so that customers don't have to manually enter this in transmitter portal and transmitters can instead read those data from well-known configuration. We want the experience to be very similar to OIDC federation.

2. Google has a RISC Transmitter - which service providers can subscribe to : https://developers.google.com/identity/protocols/risc and is completely opt-in by apps. As we work towards a CAEP transmitter - we want to read receiver configuration, create stream, notify receiving partner about a new stream and verify receiver before we allow access by a supporting partner. We want to build a "safer by default" eco system - where only service providers who receive and handle SSF signals will get access to user data. We want to be to able to do this "just-in-time" so as to not bother user about "missing stream". Currently since the spec doesn't allow for well-known configuration for receivers, it's not possible for transmitter to configure a stream and communicate with receiver to establish it.

Our goal is to create new streams continuously as soon as we discover more eligible receivers (I am leaving discovery ideas out of scope). We could create a mechanism to indicate to a receiver that it should start a stream - but I think it's just easier to create stream in the first place and start

3. Not all partners are equal. Some receiving partner may be allowed to receive signals without the overhead of stream management. We have heard from our own customers, that they would like their own customer-owned system to receive signals about their users. We do not want to force customers to use our stream management APIs as interacting with stream management API is complex - instead it would be simpler for us to build UI controls which just creates stream and notify the customer's receiver.

[SSF Evolution Usecases]

4. Currently events supported are part of stream config. However, signals supported by both transmitter and receiver will evolve in future. Existing transmitter may start supporting transmission of new signals and if we have a well-known configuration for receivers - it should be possible for transmitter to iterate through existing streams, read well-known configs of a receiver and if the receiver supports the new event type then notify receiver programmatically so that receiver can do immediate update of stream or can queue this for user approval. How update will work is implementation detail but genralizing this, transmitter and receiver may need to talk to each other out-of-band to take actions on streams and I think well-known configuration for receiver is needed for that.

5. Additional Auth options for stream management like https://github.com/openid/sharedsignals/issues/298 requires well known receiver configuration for receiver as well