Subject: [Id-event] How to Distribute Tokens

From: Phil Hunt <[email-masked]>
Date: Fri, 25 Mar 2016 14:01:50 -0700

Hoping some of you all had a chance to look at the two id-token drafts published earlier this week on the id-event list [1][2].

For the next piece of the events puzzle, I had been thinking about a subscription mgmt draft that defines how events are distributed, how clients can look for Feeds, and how they can subscribe (loosely building on the old scim notify draft).

The trouble with subscription management, is that we end up having to pick a RESTful API standard of some kind (e.g. SCIM). This might not be desirable to some.  Also some may want to administer subscriptions through web pages and not through automated interfaces.   So it is not clear to me(yet) that we need an automated way for clients to subscribe.

Observations:
* For many we’re not talking scale in the number of subscriptions but rather scale in the number of events.  Most of these subscriptions will likely be set up administratively as many of these streams are privileged.
* For mobile cases (thinking of per-app events with one subscriber and few events), it might be that these apps get provisioned through some other automated way then a generic subscription API.  Not sure.

I propose the following:

1.  Have a idevent-distribution draft that defines HTTP GET and POST as distribution methods and establishes a an event distribution methods registry so that other approaches like WebPUSH, GMS, APNS etc can be registered.

This would likely be the minimum we need to establish a methodology for transferring tokens and allow others to define other distribution methods as needed. 

2.  The SCIM WG could pursue a SCIM based subscription draft if desired.  It would define 2 new resource types:   Feeds and Subscriptions.

Concern:  The one challenge I envision is recovery scenarios. What happens when a subscriber goes offline? The mgmt interfaces are handy because they would potentially allow a client to re-start or reset a feed.  At that point we come back to needing a RESTful mgmt API.  Automated recovery seems an important piece here.

Does starting with an idevent-distribution draft seem like a preferable way to go?

[1] https://mailarchive.ietf.org/arch/msg/id-event/vdASC0oxP0DppyO6fN-G8vimpJ0 <https://mailarchive.ietf.org/arch/msg/id-event/vdASC0oxP0DppyO6fN-G8vimpJ0>
[2] https://mailarchive.ietf.org/arch/msg/id-event/3yyYIkRQsCv9iJWZ_plMZlE45-k <https://mailarchive.ietf.org/arch/msg/id-event/3yyYIkRQsCv9iJWZ_plMZlE45-k>

Thanks in advance.  Looking forward to a good discussion during the SCIM session at IETF95!

Phil

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