[Openid-specs-risc] openid/sharedsignals: Comment created on issue 298

[github at oidf.org]

openid/sharedsignals event

Issue Comment created on issue 298
Issue Title: Well Known Configuration for Receivers
https://github.com/openid/sharedsignals/issues/298

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20251119/1fd0de7b/attachment-0001.htm>