Security Events Distribution

Security Event Distribution

Wednesday 3A

Convener: Phil Hunt

Notes-taker(s): Marius Scurtescu

Tags for the session - technology discussed/ideas considered

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Presentation link: https://github.com/independentid/Identity-Events/raw/master/SET-Distribution-IIW23.pdf

• how does this relate to OpenID RISC?
  • OpenID RISC can use this, same for SCIM, each can profile SETs for their own use cases
• email header deliver was also proposed, this presentation focuses on HTTP POST
• what does an accepted message mean?
  • that it was parsed
  • provisioning needs guaranteed delivery, for example
  • acceptance also means the right message was delivered to the right endpoint
• who is the publisher and the subcriber? IdP to RP?
  • depends on the context and profile, could flow both ways
  • abuse signals may go from RP to IdP
  • logout signals mostly from IdP to RP, but depends, up to OpenID Connect to define
  • 80% IdP to RP, 20% RP to IdP
• event specifies a state change, which can come later than the user action that triggered the state change
• no event specific error messages
  • "no account for this user" might be an example of event specific error code
    • a SET message going the opposite direction (if both channels are set up) could convey the same information
• how to show interest in a spcific user account (register to receive events for that user)?
• error handling difficuly with batching
• we should keep distribution simple, no batching, unless there is a real need for it, can be revisited in next version
• can this be extended to other use case, like sending a logout event to an IdP based on hardware proximity?
  • CISCO had a similar use case for WebEx, feed definition is complex in this case
• should we anticipate both way communication
  • well known endpoints would help automate this, there could be different well known URLs for RISC and SCIM
• some notifications, related to registrations, may work only with a query interface and not pub/sub
• don't accept email address without verifying it, as an RP