[Openid-specs-risc] meeting notes for December 10, 2019

[Marius Scurtescu]

Attended: Marius Scurtescu and Stan Bounev

Notes:

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


Stan, please let me know if I forgot anything of if anything above needs
corrections.

Happy Holidays!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20191220/057373b7/attachment.html>