Subject: [Id-event] Getting going some new drafts...

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Nov 2015 11:08:23 +0900

I propose we initially plan to write 2 individual contribution drafts:

* ID Event Protocol
  - based on a set of RESTful Publish and Subscribe and event pickup/delivery endpoints as well as defining Feeds
* ID Event Token
  - based on JWT and JOSE upon which different areas can build domain specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, and so on)

There is a fair amount of text that can be re-used from https://tools.ietf.org/html/draft-hunt-scim-notify-00 <https://tools.ietf.org/html/draft-hunt-scim-notify-00>. However the architecture described in the document will likely be different. The publisher to hub portion isn’t needed, however much of the functionality described in the hub is needed (e.g. how a client registers for subscription and how a client receives events).

I’m happy to get started on the protocol stuff. Would anyone like to volunteer on starting the Event Token spec?

Note:  Please don’t stop discussing. As a writer, I don’t mind adjusting as we go. In particular what do you like or hate about the notify mechanisms for delivery?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2015 03:16:43 +0100

On 2015-11-05 03:08, Phil Hunt wrote:
>   - based on a set of RESTful Publish and Subscribe and event
> pickup/delivery endpoints as well as defining Feeds

My standard question: where does webpush go?

> * ID Event Token
>   - based on JWT and JOSE upon which different areas can build domain
> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC,
> and so on)
> 
> There is a fair amount of text that can be re-used
> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However the
> architecture described in the document will likely be different. The
> publisher to hub portion isn’t needed, however much of the functionality
> described in the hub is needed (e.g. how a client registers for
> subscription and how a client receives events).
> 
> I’m happy to get started on the protocol stuff. Would anyone like to
> volunteer on starting the Event Token spec?
> 
> Note:  Please don’t stop discussing. As a writer, I don’t mind adjusting
> as we go. In particular what do you like or hate about the notify
> mechanisms for delivery?
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Nov 2015 11:23:24 +0900

WebPUSH really has a completely differnt objective.  They seem to want assured delivery for mobile.

They don’t have a subscription concept and thus have indicated they will not consider cases beyond 1:1.

Phil

@independentid
www.independentid.com
[email-masked]

> On Nov 5, 2015, at 11:16 AM, Leif Johansson <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Nov 2015 11:27:19 +0900

Sorry. More importantly, webpush  does not have a publish and subscribe concept around feeds.

I did however include webpush in the notify spec to show how it might tie in.  

Phil

> On Nov 5, 2015, at 11:23, Phil Hunt <[email-masked]> wrote:
>

---

From: William Denniss <[email-masked]>
Date: Thu, 5 Nov 2015 11:29:41 +0900

Sounds good to me.

I'm happy to volunteer to write the Event Token spec.

On Thu, Nov 5, 2015 at 11:08 AM, Phil Hunt <[email-masked]> wrote:

> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, and
> so on)
>
> There is a fair amount of text that can be re-used from
> https://tools.ietf.org/html/draft-hunt-scim-notify-00. However the

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2015 06:18:05 +0100

> Sorry. More importantly, webpush  does not have a publish and subscribe concept around feeds.

but isn't that just a management layer for a bunch of webpush 1-1's?

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Nov 2015 14:25:05 +0900

Most of this is server to server communication.   I don’t know that webpush adds that much for servers.  If we are trying to push to native apps or browsers then I could see webpush making more sense.

John B.
> On Nov 5, 2015, at 2:18 PM, Leif Johansson <[email-masked]> wrote:
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2015 06:47:31 +0100

> Most of this is server to server communication.   I don’t know that webpush adds that much for servers.  If we are trying to push to native apps or browsers then I could see webpush making more sen…

hmm ..

I guess I'm wondering how many ways you can skin a cat^H^H^Hnotification
protocol

If we wind up spec:ing something that is semantically
equivalent to something that already exists I'm gona
blame you guys :-)

	Cheers Leif

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Nov 2015 14:57:01 +0900

In Connect, we were considering a simple rest API for delivering tokens using post.  

Phil has indicated a need for the client to also poll to catch up on messages.    

It may be that the transport will wind up being different for the different use cases. 

I don’t think we have come to a conclusion on that.

> On Nov 5, 2015, at 2:47 PM, Leif Johansson <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Nov 2015 15:10:01 +0900

Of course, I think this is something the ADs should monitor.

The reluctance does not come from me. I tried to open that door with the WebPUSH WG twice now. They want to keep their scope focused on messaging to mobile clients. They don’t want anything dealing with 1 to many subscriptions.

FWIW, I think we care less about the delivery protocol and more about the management aspects such as how to define a feed and how a client subscribes, not to mention what an event looks like.  I don’t think web push is looking at formalize specific messages either.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2015 07:42:38 +0100

> FWIW, I think we care less about the delivery protocol and more about the management aspects such as how to define a feed and how a client subscribes, not to mention what an event looks like.  I do…

ok

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 5 Nov 2015 07:08:17 +0000

I think there are many cases where clients might also want to subscribe to
the notifications so we can¹t rule that use case out. I don¹t know if
webpush is going to be appropriate or not yet, but I think it is worth
thinking through the use cases and applicability of webpush for them.

On 11/4/15, 9:25 PM, "Id-event on behalf of John Bradley"
<[email-masked] on behalf of [email-masked]> wrote:

>Most of this is server to server communication.   I don¹t know that
>webpush adds that much for servers.  If we are trying to push to native
>apps or browsers then I could see webpush making more sense.
>
>John B.
>>>> They don¹t have a subscription concept and thus have indicated they
>>>>will not consider cases beyond 1:1.
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> [email-masked]
>>>> 
>>>>>> publisher to hub portion isn¹t needed, however much of the
>>>>>>functionality
>>>>>> I¹m happy to get started on the protocol stuff. Would anyone like to
>>>>>> Note:  Please don¹t stop discussing. As a writer, I don¹t mind
>>>>>>adjusting

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2015 08:18:41 +0100

> thinking through the use cases and applicability of webpush for them.

My point (which I will stop wining about) is this: subscription/feeds
etc is just a REST api and what is left is a channel to each subscriber
and how much difference is there really between a "mobile client" and
a "server". Its all HTTP.

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Nov 2015 16:27:57 +0900

The difference is that the mobile client doesn’t have a permanent web address for the AS to send https posts to.

As I understand it web-push has several methods to open a channel to the AS that it then leaves open for the server to push messages on.

I am not philosophically  opposed to web push, but it will be more resource intensive, and will require the client authenticate itself to the AS to get the correct messages.
That is a larger problem.  Not impossible but larger.    My question is for SSO is there really a demand to send a push to the client to log out the user. 

I think web-push to apps on the device from the AS should be looked at but we do need to decide if it is a real use-case.

John B.
> On Nov 5, 2015, at 4:18 PM, Leif Johansson <[email-masked]> wrote:
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Nov 2015 08:53:15 +0100

> The difference is that the mobile client doesn’t have a permanent web address for the AS to send https posts to.

point