Subject: [scim] Follow-up from IETF97 - XMPP Grid

From: Phil Hunt <[email-masked]>
Date: Fri, 18 Nov 2016 15:25:42 +0900

Note: cross-posted to IdEvents, SCIM, and OpenID RISC mailing lists.

At the end of the Sec Events meeting, Nancy Cam-Winget mentioned the XMPP-Grid draft which is about to go WGLC. See:
  https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ <https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/>

I have taken a look and my initial impression is we should look at it:

1. Bi-directional signalling.  A few use-cases (e.g. RISC) have indicated a need to enable bi-directional flow. While HTTP post is simple, it would involve managing two separate connections. It may be possible XMPP-Grid turns out to be logistically simpler?

2. Firewall issues (e.g. cloud-to-enterprise). XMPP could be a good way to avoid needing “polling” solutions such as HTTP GET when it is inconvenient to open access for an HTTP POST.  This may be of great interest to the SCIM Synchronization work that some are considering.

3. Fan-out distribution: It could potentially handle publishing to multiple receivers simultaneously. This is particularly useful in cases where multiple data centers or server clusters need to receive the events.  For example, in OpenID Connect logout, the ability to notify all members of a Single-sign-on audience for ID Tokens.

4. It supports multiple data formats (e.g. not just JWTs)

5. There is a control-plane in XMPP-grid that may also prove useful for some or all of our requirements.

6. While it seems more complex, it can provide simplification overall. Thought over-kill for one-way pub-sub, XMPP-Grid might be more of a universal solution for all cases. Recalling Kathleen’s comments about TAXII, this could be one way to avoid connection-itus and brokering.

While this may seem like a very positive review on my part, I do suspect that many will find this over-kill. 

ACTION REQUESTED:
I’d like to get a feel from the Sec Events community about this idea. Would you like to see this idea explored further on the list?

A.  Does this look like something we should consider?  What additional capabilities do you see XMPP Grid bringing?

B.  If you see this as unnecessary, what would be your concerns?

ps. I’m working on the other action items and hope to post a new SEC Token draft early next week.

Thanks for a great kick-off meeting!

Phil

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

---

From: Leif Johansson <[email-masked]>
Date: Sun, 20 Nov 2016 23:00:47 +0100

On 2016-11-18 07:25, Phil Hunt wrote:
> At the end of the Sec Events meeting, Nancy Cam-Winget mentioned the
> XMPP-Grid draft which is about to go WGLC. See:
>   https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/
> 
> 1. Bi-directional signalling.  A few use-cases (e.g. RISC) have
> indicated a need to enable bi-directional flow. While HTTP post is
> simple, it would involve managing two separate connections. It may be
> possible XMPP-Grid turns out to be logistically simpler?
> 
> 2. Firewall issues (e.g. cloud-to-enterprise). XMPP could be a good way
> to avoid needing “polling” solutions such as HTTP GET when it is
> inconvenient to open access for an HTTP POST.  This may be of great
> interest to the SCIM Synchronization work that some are considering.
> 
> 3. Fan-out distribution: It could potentially handle publishing to
> multiple receivers simultaneously. This is particularly useful in cases
> where multiple data centers or server clusters need to receive the
> events.  For example, in OpenID Connect logout, the ability to notify
> all members of a Single-sign-on audience for ID Tokens.
> 
> 6. While it seems more complex, it can provide simplification overall.
> Thought over-kill for one-way pub-sub, XMPP-Grid might be more of a
> universal solution for all cases. Recalling Kathleen’s comments about
> TAXII, this could be one way to avoid connection-itus and brokering.
> 
> I’d like to get a feel from the Sec Events community about this idea.
> Would you like to see this idea explored further on the list?
> 
> A.  Does this look like something we should consider?  What additional
> capabilities do you see XMPP Grid bringing?
> 
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
> 

In an earlier life (about 10 years ago) I built and deployed
(what is now called) "chat ops" based on XMPP pubsub - very
similar in requirements to what we're talking about here.

XMPP is quite nice once you get it deployed but building and
maintaining scalable xmpp pubsub infrastructure can be a bit
more than many organizations is able to deal with.

I guess that part will be up to Dick :-)

	Cheers Leif