Subject: [Id-event] Breaking out the distribution draft

From: Phil Hunt <[email-masked]>
Date: Mon, 27 Feb 2017 13:35:30 -0800

Please confirm if you agree with the following:

I had previously promised to break up the distribution draft into components. I ran into some difficulty as to how subscribers (receivers) of events find out if the publisher is having problems delivering events. 

After some discussion with the RISC WG folks and Adam Dawes, I would like to propose that I break out a SET Transmission draft that includes the following:

1.  Basic HTTPS POST profile to a specified endpoint.  It is up to the receiver to provide fault tolerance and high-availability that meets its own delivery assurance requirements.
2.  A set of metadata that describes the endpoints, the encryption methods (eg. keys for signing and encrypting JWTs) etc.
3.  A simple control plane API that allows a subscriber (receiver) to perform an HTTPS GET to obtain the current configuration and subscription (stream) status.  While compatible with SCIM, it will NOT require SCIM to be implemented. 
4.  Configuration of subscriptions (streams) is done through out-of-scope administrative processes offered by event publishers.
5.  In the initial profile, subscribers will not be able to “pause” streams automatically unless offered through the administrative interface of the publisher.

If people have a need for automated management, the basic idea is that you implement the POST and PATCH methods of SCIM and you are good to go. We don’t need to spend a lot of time on it as there is nothing special to do once the metadata for streams is defined.

Does this work for everyone?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Adam Dawes <[email-masked]>
Date: Tue, 28 Feb 2017 00:53:44 -0800

I think this is great Phil. Thanks again for the detailed conversation
where we were able to arrive at this.

On Mon, Feb 27, 2017 at 1:35 PM, Phil Hunt <[email-masked]> wrote:

> I had previously promised to break up the distribution draft into
> components. I ran into some difficulty as to how subscribers (receivers) of
> events find out if the publisher is having problems delivering events.
>
> After some discussion with the RISC WG folks and Adam Dawes, I would like
> to propose that I break out a SET Transmission draft that includes the
> following:
>
> 1.  Basic HTTPS POST profile to a specified endpoint.  It is up to the
> receiver to provide fault tolerance and high-availability that meets its
> own delivery assurance requirements.
> 2.  A set of metadata that describes the endpoints, the encryption methods
> (eg. keys for signing and encrypting JWTs) etc.
> 3.  A simple control plane API that allows a subscriber (receiver) to
> perform an HTTPS GET to obtain the current configuration and subscription
> (stream) status.  While compatible with SCIM, it will NOT require SCIM to
> be implemented.
> 4.  Configuration of subscriptions (streams) is done through out-of-scope
> administrative processes offered by event publishers.
> 5.  In the initial profile, subscribers will not be able to “pause”
> streams automatically unless offered through the administrative interface
> of the publisher.
>
> If people have a need for automated management, the basic idea is that you
> implement the POST and PATCH methods of SCIM and you are good to go. We
> don’t need to spend a lot of time on it as there is nothing special to do
> once the metadata for streams is defined.
>
> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: "Hardt, Dick" <[email-masked]>
Date: Tue, 28 Feb 2017 16:32:07 +0000

Perhaps I am missing it, but I don’t see a mechanism for the receiver to add / delete which subjects the receiver is interested in. Is this not included, or am I misunderstanding what is below?

Or is that out of scope? If so, that seems odd as there is a control plane API in (3)

/Dick

On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

I think this is great Phil. Thanks again for the detailed conversation where we were able to arrive at this.

On Mon, Feb 27, 2017 at 1:35 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Please confirm if you agree with the following:

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 28 Feb 2017 09:12:03 -0800

RISC use case is typically bi-directional so events can be used. It also works better because usually a receiver may add only or drop only depending on implicit or explicit federation. 

Adam argued for all other update items to be done OOB.  

That just left error signalling for the receiver to find out why events were not coming. 

We left it that scim can be quickly added for those that want full automated CRUD (oracle does). Buy it would not be required in core. 

Phil

> On Feb 28, 2017, at 8:32 AM, Hardt, Dick <[email-masked]> wrote:
> 
> On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked] on behalf of [email-masked]> wrote:
>

---

From: "Hardt, Dick" <[email-masked]>
Date: Tue, 28 Feb 2017 19:40:57 +0000

On 2/28/17, 9:12 AM, someone claiming to be "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>> wrote:

This sentence does not make sense to me.

Adam: would you elaborate? As I understand it, you are saying you don’t want to standardize how Amazon and Google / Microsoft will coordinate, and this also leaves out how PayPal and Identity Analytics would signal. We should standardize how we subscribe to subjects.

The ping?

“SCIM quickly added” sounds like an oxymoron. ☺

Phil

On Feb 28, 2017, at 8:32 AM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps I am missing it, but I don’t see a mechanism for the receiver to add / delete which subjects the receiver is interested in. Is this not included, or am I misunderstanding what is below?

/Dick

Phil

---

From: Adam Dawes <[email-masked]>
Date: Tue, 28 Feb 2017 22:24:52 -0800

Thanks for bringing this up Dick. I think you're worried about, when
[email-masked] signs up for an account at Amazon, how would Amazon
register to get events from Google. I think we can deal with this if Amazon
sends a SET token to google with an "account created" event which would
then create a registration at google for Amazon to receive events about
alice@.

I think it is totally reasonable to think of account creation as a
notifiable event. And in typical RISC fashion, it is up to the recipient to
do what it will with the events. From Google's perspective, we would white
list a set of partners where we have contracts to enable implicit
registration. I think we should work out some response codes to make it
clear to the sender whether the registration succeeded.

We didn't talk a lot about this in the F2F but is an idea that I had in my
deck and I think it came up in Phil and my conversation last week. Phil,
does the above give you any concerns?

On Tue, Feb 28, 2017 at 9:12 AM, Phil Hunt (IDM) <[email-masked]>
wrote:

> RISC use case is typically bi-directional so events can be used. It also
> works better because usually a receiver may add only or drop only depending
> on implicit or explicit federation.
>
> We left it that scim can be quickly added for those that want full
> automated CRUD (oracle does). Buy it would not be required in core.
>
> Phil
>
> Perhaps I am missing it, but I don’t see a mechanism for the receiver to
> add / delete which subjects the receiver is interested in. Is this not
> included, or am I misunderstanding what is below?
>
>
>
> On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf
> of Adam Dawes" <[email-masked] on behalf of
> [email-masked]> wrote:
>
>
>
> <(650)%20214-2410>