Subject: [Id-event] Informal working meeting

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 14 Nov 2016 08:59:54 +0900

I have booked Studio 7 from 1 till 3 this afternoon (in Seoul) for those who would like to discuss use cases and draft details. 

Note the official wg meeting is still Wednesday. 

Phil

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Nov 2016 09:52:29 +0900

Thanks, Phil

[with chair hat on]

To clarify, this is not an official working group meeting. This is more like a side meeting or a design team meeting. IOW the proponents of a draft are meeting to work on their draft. 

As always, decisions are made on the mailing list - not in side meetings and not even in regularly scheduled meetings.

That said, any activity that advances the work of the group is welcome, especially if that happens in IETF week. So anyone who wants to join in, more power to you. I’ll have to miss it personally.

Thanks

Yoav

> On 14 Nov 2016, at 8:59, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Mon, 14 Nov 2016 15:40:53 +0900

Just a quick summary of today’s meeting highlights from my perspective.  I think we made some good progress and it will shape/organize thoughts for Wednesday.

There is interest in having further informal discussion tomorrow morning at 9AM-10AM in Studio 7.  This meeting will likely focus on talking more about event control plane and the need for feeds and subscriptions (see below).

The following is a summary of some of the conclusions I took away from the meeting. Apologies I did not take minutes so this doesn’t really include who said what etc.

Subscription Management.
In today’s meeting we spent a lot of time discussing the use case for the management portion of the distribution spec.  At first there was wide disagreement on the need but we eventually all realized that any eventing system needs a control plane.

So, in the current specification, the subscription metadata is accessible and updatable using SCIM as the control plane.  A subscriber can interrogate the control plan by calling to the publisher’s SCIM endpoint.

Meanwhile, the pubsub relationship is the data plane and it flows in the reverse direction towards the subscriber.

We discussed how a subscriber can interrogate SCIM to find out the current subscription status and to do functions like pause a subscription, initiate a verification ping, or shut a subscription off.

There was less agreement that subscribers would use SCIM CREATE and DELETE to create and cancel subscriptions over time. Many felt this would be handled out of band.

Type of Subscriptions to Manage

There was interest in expanding scope of event subscriptions beyond SET (JWT) tokens to include things like SAML events, or STIX/TAXII events. The feeling was why not.  While the distribution spec will use SETs as examples, we can soften the language to allow for any event message which would be dictated by mime-type (e.g. application/jwt).

Sequencing

There seemed to be consensus that sequencing does not need to be in the core spec, but that we should include considerations to inform profiling specs that using timestamps for sequencing is not advisable.

Feeds vs. Subscriptions

There is some interest (but no informal conclusions) in merging Feeds and Subscriptions as a single object. There is currently not much interest in having a feed catalogue to help subscribers discover available Feeds.  If we were to merge this stuff, it would mean adding the events attribute to the subscription metadata.

Other Delivery Methods

Some are interested in defining a polling method. It’s not clear whether this should go in the initial spec.  Version 00 of the distribution draft had it but it was pulled to align with the charter.

SET JSON Optimization

We discussed Justin’s optimization. The issue is what format is best for events that have no “payload” attributes. There were 3 possible alternatives that could be used.

Version 1 (null):

“events”:[“some:event:uri”:null]

We don’t like because it suggests that “some:event:uri” is NOT being asserted.

Version 2: (true):

“events”:[“some:event:uri”:true]

Might be confusing because it is a boolean value instead of a json object.  Parsers have to check what data type is present in thev value.

Version 3 (empty object):

“events”:[“some:event:uri”:{}]

This seems to be the informal favourite.  It is also less characters than null or true.  It also means that the event value always has a json object attached.

Justin also pointed out that we should forbid repeated event values within the events attribute as they may not be valid JSON or might cause confusion. 

Drafts Plan
We discussed how adoption might work going forward. The SET spec seems straight forward and can go ahead as planned in the charter.

Given the above, we probably want to keep talking about distribution and management/control plane. Should these be separate specifications?  As editor, my comment was that the delivery methods might depend on a lot of metadata.  I agreed I would take a look at whether we can pull this apart fairly easily.

Thanks everyone for the great discussion!

Phil

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

> On Nov 14, 2016, at 9:52 AM, Yoav Nir <[email-masked]> wrote:
> 
> Thanks, Phil
> 
> [with chair hat on]
>