Subject: [Id-event] Straw man text for proposed charter

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 5 May 2016 18:18:52 +0000

Hi folks,

At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put together the attached as a straw man charter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if you think its necessary.

Cheers,
Morteza

---

From: Alan Karp <[email-masked]>
Date: Thu, 5 May 2016 21:42:34 -0700

I don't see anything about access control for publishing events and
subscribing to them.  I also think the spec should allow filters on
subscriptions.

--------------
Alan Karp

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <
[email-masked]> wrote:

> Hi folks,
>
> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put
> together the attached as a straw man charter proposal to start the
> discussion. Please send your comments and suggestions for any changes or
> propose a new one if you think its necessary.
>
>
> Cheers,
> Morteza
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 6 May 2016 05:00:36 +0000

Thanks guys, for writing the initial charter text.  Reading it now, I am extremely worried by the scope creep evident in the proposal.

I strongly support a working group to define an ID Events data format.  I just as strongly believe that specific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being out of scope in the working group charter.  Attempting to specify a particular event delivery mechanism will take something that could be simple and quick to approve and bog it down in necessarily application-specific debates.

Should event delivery be reliable?  That’s an application-specific decision.
Should events be idempotent?  That’s an application-specific decision.
Should events be unicast, multicast, or broadcast?  That’s an application-specific decision.
Should events have categories with category-specific subscriptions?  That’s an application-specific decision.
Should only one party at a time be able to register for delivery of events or should multiple parties be able to request delivery?  That’s an application-specific decision.
I could continue with this list, but I think you all get the point…

If we start debating application-specific event delivery mechanisms, we’ll please almost no one, since nearly all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as being out of scope.

If we define only a data format, we can quickly produce a very useful specification.  If we don’t, we’ll get bogged down in the mud of debating which applications we’re catering to and which we aren’t – an exercise of picking favorites and limiting applicability of the specification.  That way is a slow, painful descent into standards quicksand – something we must avoid.  Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.

                                                          Sincerely,
                                                          -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] Straw man text for proposed charter

I don't see anything about access control for publishing events and subscribing to them.  I also think the spec should allow filters on subscriptions.

--------------
Alan Karp

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

Cheers,
Morteza

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

---

From: "Leif Johansson" <[email-masked]>
Date: Sat, 7 May 2016 10:34:53 +0200

Skickat från min iPhone

> 6 maj 2016 kl. 07:00 skrev Mike Jones <[email-masked]>:
> 

+1

> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <[email-masked]> wrote:
> Hi folks,
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sat, 7 May 2016 07:19:36 -0700

Mike

A number of people have indicated they need a transport. The commonalities are 90-99% the same. It would seem wise to sort out what is truly contextual. 

I think things like feed definitions and filters are highly contextual in particular. 

Putting that aside i do not see much difference between RISC, logout, revocation, and SCIM other than event meaning.  

Why would we want multiple solutions here?

Your colleague Craig has a very different case, but the watermarking in his polling proposal serves to address all your concerns and can be used in push system as well. 

Phil

> On May 5, 2016, at 22:00, Mike Jones <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 7 May 2016 10:50:31 -0400

Importantly, I think the concerns are separable. We can quickly define 
the format and content, as Mike suggests, and define an API (or set of 
APIs) around its transport later. We don't have to hold up the first 
work for the latter, nor should things be so tightly coupled that we'd 
need to do that anyway.

  -- Justin

On 5/7/2016 10:19 AM, Phil Hunt (IDM) wrote:
> Mike
>
> A number of people have indicated they need a transport. The 
> commonalities are 90-99% the same. It would seem wise to sort out what 
> is truly contextual.
>
> Putting that aside i do not see much difference between RISC, logout, 
> revocation, and SCIM other than event meaning.
>
> Your colleague Craig has a very different case, but the watermarking 
> in his polling proposal serves to address all your concerns and can be 
> used in push system as well.
>
> Phil
>
> On May 5, 2016, at 22:00, Mike Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Thanks guys, for writing the initial charter text.  Reading it now, I 
>> am extremely worried by the scope creep evident in the proposal.
>>
>> I strongly support a working group to define an ID Events data 
>> format.  I just as strongly believe that specific event delivery 
>> mechanisms will necessarily be application-specific and therefore 
>> MUST be explicitly be stated as being out of scope in the working 
>> group charter.  Attempting to specify a particular event delivery 
>> mechanism will take something that could be simple and quick to 
>> approve and bog it down in necessarily application-specific debates.
>>
>> Should only one party at a time be able to register for delivery of 
>> events or should multiple parties be able to request delivery? 
>>  That’s an application-specific decision.
>>
>> If we start debating application-specific event delivery mechanisms, 
>> we’ll please almost no one, since nearly all applications have 
>> different event delivery requirements.  We MUST explicitly rule all 
>> delivery mechanisms as being out of scope.
>>
>> If we define only a data format, we can quickly produce a very useful 
>> specification.  If we don’t, we’ll get bogged down in the mud of 
>> debating which applications we’re catering to and which we aren’t – 
>> an exercise of picking favorites and limiting applicability of the 
>> specification.  That way is a slow, painful descent into standards 
>> quicksand – something we must avoid.  Having a standard ID events 
>> representation is far too important to tie to a particular limited 
>> event delivery mechanism.
>>
>> Sincerely,
>>
>> -- Mike
>>
>> *From:*Id-event [mailto:[email-masked]] *On Behalf Of 
>> *Alan Karp
>> *Sent:* Thursday, May 5, 2016 9:43 PM
>> *To:* Morteza Ansari (moransar) <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [Id-event] Straw man text for proposed charter
>>
>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi folks,
>>
>>     At IIW a few of us (Phil, William, Adam, and I) huddled for a bit
>>     and put together the attached as a straw man charter proposal to
>>     start the discussion. Please send your comments and suggestions
>>     for any changes or propose a new one if you think its necessary.
>>
>>     Cheers,
>>
>>     Morteza
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sat, 7 May 2016 08:03:12 -0700

In the charter proposal we have the event format on fast track. (A meeting or so)

Phil

> On May 7, 2016, at 07:50, Justin Richer <[email-masked]> wrote:
> 
> Importantly, I think the concerns are separable. We can quickly define the format and content, as Mike suggests, and define an API (or set of APIs) around its transport later. We don't have to hold up the first work for the latter, nor should things be so tightly coupled that we'd need to do that anyway.
> 
>  -- Justin
>

---

From: Alan Karp <[email-masked]>
Date: Sat, 7 May 2016 10:23:10 -0700

As one who proposed doing more, I believe that your position is valid.  My
only question is whether or not that will be enough for interoperability.

--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <[email-masked]>
wrote:

> Thanks guys, for writing the initial charter text.  Reading it now, I am
> extremely worried by the scope creep evident in the proposal.
>
>
>
> I strongly support a working group to define an ID Events data format.  I
> just as strongly believe that specific event delivery mechanisms will
> necessarily be application-specific and therefore MUST be explicitly be
> stated as being out of scope in the working group charter.  Attempting to
> specify a particular event delivery mechanism will take something that
> could be simple and quick to approve and bog it down in necessarily
> application-specific debates.
>
>
>
> Should only one party at a time be able to register for delivery of events
> or should multiple parties be able to request delivery?  That’s an
> application-specific decision.
>
> If we start debating application-specific event delivery mechanisms, we’ll
> please almost no one, since nearly all applications have different event
> delivery requirements.  We MUST explicitly rule all delivery mechanisms as
> being out of scope.
>
>
>
> specification.  If we don’t, we’ll get bogged down in the mud of debating
> which applications we’re catering to and which we aren’t – an exercise of
> picking favorites and limiting applicability of the specification.  That
> way is a slow, painful descent into standards quicksand – something we must
> avoid.  Having a standard ID events representation is far too important to
> tie to a particular limited event delivery mechanism.
>
>
>
>                                                           Sincerely,
>
>                                                           -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Alan
> Karp
> *To:* Morteza Ansari (moransar) <[email-masked]>
> *Cc:* [email-masked]

---

From: John Bradley <[email-masked]>
Date: Sat, 7 May 2016 15:22:41 -0300

+1

> On May 6, 2016, at 2:00 AM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi folks,
>  
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 7 May 2016 20:04:30 +0000

Thanks Alan,

Interoperability will be on a per-application basis, just like JWT interoperability.  The claims needed in an identity event are application-specific, just like claims are for JWTs.  This is the same standards posture and JWTs are a huge success – including for interoperability, even if I do say so myself.

                                                          Best wishes,
                                                          -- Mike

From: Alan Karp<mailto:[email-masked]>
Sent: Saturday, May 7, 2016 10:23 AM
To: Mike Jones<mailto:[email-masked]>
Cc: Morteza Ansari (moransar)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Straw man text for proposed charter

As one who proposed doing more, I believe that your position is valid.  My only question is whether or not that will be enough for interoperability.

--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks guys, for writing the initial charter text.  Reading it now, I am extremely worried by the scope creep evident in the proposal.

                                                          Sincerely,
                                                          -- Mike

From: Id-event [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Straw man text for proposed charter

--------------
Alan Karp

Cheers,
Morteza

---

From: Vivek Biswas <[email-masked]>
Date: Sat, 7 May 2016 13:24:39 -0700

Yes, I agree that the claims can be application specific, however there is a possibility to define claims which are domain specific. Thereby claims generated in one application could be understood by another  application within the same domain.

With microservices based architecture getting lot of attention, if two different micro services defining different claims for the same claim, it can create confusion.

Nevertheless this well defined claims for a particular domain can be an extension to the core specification.

-Vivek Biswas
  Consulting Member, Oracle

Sent from my iPhone

> On May 7, 2016, at 1:04 PM, Mike Jones <[email-masked]> wrote:
> 
> Thanks Alan,
>  
> From: Alan Karp
> To: Mike Jones
> Cc: Morteza Ansari (moransar); [email-masked]
>> On Thu, May 5, 2016 at 10:00 PM, Mike Jones <[email-masked]> wrote:

---

From: Mike Jones <[email-masked]>
Date: Sat, 7 May 2016 20:31:50 +0000

Indeed, that’s why there’s a claims registry – so common claims can be defined once and then reused.

From: Vivek Biswas<mailto:[email-masked]>
Sent: Saturday, May 7, 2016 1:24 PM
To: Mike Jones<mailto:[email-masked]>
Cc: Alan Karp<mailto:[email-masked]>; Morteza Ansari (moransar)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Straw man text for proposed charter

-Vivek Biswas

Sent from my iPhone

On May 7, 2016, at 1:04 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Alan,

                                                          Best wishes,
                                                          -- Mike

--------------
Alan Karp

                                                          Sincerely,
                                                          -- Mike

--------------
Alan Karp

Cheers,
Morteza

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sat, 7 May 2016 18:53:13 -0700

We also set things up so even a domain specific event can be extended. 

Eg on a password reset event, so event publishers may want to add security domain specific attributes. The spec lets them do that while avoiding interop issues. 

I believe in the spec we had the example of an account reset and the publisher adds reset count as an extension. 

Phil

> On May 7, 2016, at 13:31, Mike Jones <[email-masked]> wrote:
> 
> From: Vivek Biswas
> Cc: Alan Karp; Morteza Ansari (moransar); [email-masked]