<div dir="ltr"><div>Attended: Marius Scurtescu and Stan Bounev</div><div><br></div><div>Notes:</div><ul><li>we looked at different use cases for clearing houses</li><ul><li>the use cases document touches on a couple of related use cases, but uses different terminology</li><ul><li><a href="https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases">https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases</a><br></li><li>see the two implicit and the pseudo implicit use cases (3.3, 3.4 & 3.5)</li><li>see identity as a service use case (3.6)</li><li>see security as a service use case (3.7)</li></ul><li>there was discussion in the past on allowing delegation through the control plane, this would open up other use case</li><ul><li>Receiver1 through the control plane could specify a list of events together with the identifier of another Receiver2</li><li>the Transmitter will then route events events meant for Receiver1 to Receiver2 (as well)</li><li>Receiver2 will have to use the control plane to configure its endpoint</li></ul><li>Receivers always have the option to receive all events and then route them to third parties</li></ul><li>on specific use case was brought up by Stan:</li><ul><li>a clearing house is specialized in tracking compromised credentials</li><li>a service provider would like notifications when one of the accounts they manage has a known compromised credential</li><li>possible solution that we came up with during the call:</li><ul><li>service provider acts as Receiver and uses implicit flow to subscribe for events from clearing house which acts as Transmitter, this would be the pseudo implicit case (3.5)</li><li>the Transmitter has to have a way to signal that a particular credential was compromised without disclosing the actual credential</li><ul><li>the Receiver normally is storing only credential hashes</li><li>Receiver could store a compromised credential hash (as calculated by the Transmitter) and the next time the user logs in it could compare</li><li>Stan has another proposal here that he will present in a separate email thread</li><li>a new event type would be needed, something like "credential-compromised", I will start a separate thread for that</li></ul></ul></ul></ul><div><br></div><div>Stan, please let me know if I forgot anything of if anything above needs corrections.</div><div><br></div><div>Happy Holidays!</div></div>