Security Events Distribution

From IIW
Jump to: navigation, search
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:

  • 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