Subject: [Id-event] Fwd: Wednesday Session 3 - Room A - Security Event Distribution

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Oct 2016 09:31:12 -0700

These are some notes from a follow-up presentation that Marius and I gave on SET Distribution. In particular there was another discussion on batching based on some new cases that Any brought from the security analytics/shared signals perspective.

Thanks,

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> Begin forwarded message:
> 
> From: Marius Scurtescu <[email-masked]>
> Subject: Wednesday Session 3 - Room A - Security Event Distribution
> Date: October 26, 2016 at 2:41:02 PM PDT
> To: [email-masked]
> Cc: Phillip Hunt <[email-masked]>
> 
> Presentation link:
> https://github.com/independentid/Identity-Events/raw/master/SET-Distribution-IIW23.pdf <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
>