<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
openid/sharedsignals event <br>
<br>
Issue Comment created on issue 298 <br>
Issue Title: Well Known Configuration for Receivers <br>
https://github.com/openid/sharedsignals/issues/298 <br>
<br>
Comment: As discussed in the WS 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
</body>
</html>