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

From: Mike Jones <[email-masked]>
Date: Wed, 7 Sep 2016 00:01:22 +0000

An updated and simplified charter is attached.  This draft has been reviewed by Phil Hunt, William Denniss, Marius Scurtescu.

Input from Alexey Melnikov is that we should probably charter a working group, rather than try to go the AD-sponsored route.  Therefore, please review this draft charter and let us know if you think it’s ready to go.

                                                       Thanks,
                                                       -- Mike

From: Sarah Squire [mailto:[email-masked]]
Sent: Thursday, July 14, 2016 10:59 PM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Mike Jones <[email-masked]>; Alan Karp <[email-masked]>; Vivek Biswas <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Straw man text for proposed charter

Just submitting my two cents in writing before we hopefully have a chance to meet about this next week...

Looking at this charter from the perspective of the OIDF HEART working group, I think it's going down a good path. In terms of the data format, this is less structured than what I was envisioning, but we could easily do a healthcare-specific profile of whatever data format comes out in the end, so it's better to be too broad than too narrow as far as our interests are concerned.

The transport layer however, has some added complexity. In our context, we're shooting for interoperability, so we'd prefer something constrained. I appreciate Mike's input that these are application layer decisions. However, if we're talking about cloud provider-to-cloud provider communication, that certainly is facilitated by a well-defined transport layer. Again, we're willing to profile whatever the group comes up with for our own ends, but I don't really see the benefit of having a loosely defined transport layer - it just seems like more work for all the implementers to actually agree on endpoints on a case-by-case basis.

Looking forward to discussing further in Berlin!

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com<http://engageidentity.com/>

On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>> wrote:
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

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]<mailto:[email-masked]>> wrote:
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.

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]<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

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,

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

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

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

---

From: William Denniss <[email-masked]>
Date: Tue, 6 Sep 2016 17:04:02 -0700

Thank you Mike for revising the charter.

I support it, and hope we can form a WG with this charter to continue our
work.

On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones <[email-masked]>
wrote:

> An updated and simplified charter is attached.  This draft has been
> reviewed by Phil Hunt, William Denniss, Marius Scurtescu.
>
>
>
> Input from Alexey Melnikov is that we should probably charter a working
> group, rather than try to go the AD-sponsored route.  Therefore, please
> review this draft charter and let us know if you think it’s ready to go.
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Sarah Squire [mailto:[email-masked]]
> *Sent:* Thursday, July 14, 2016 10:59 PM
> *To:* Phil Hunt (IDM) <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Alan Karp <
> [email-masked]>; Vivek Biswas <[email-masked]>; Morteza
> Ansari (moransar) <[email-masked]>; [email-masked]
>
> *Subject:* Re: [Id-event] Straw man text for proposed charter
>
>
>
> Looking at this charter from the perspective of the OIDF HEART working
> group, I think it's going down a good path. In terms of the data format,
> this is less structured than what I was envisioning, but we could easily do
> a healthcare-specific profile of whatever data format comes out in the end,
> so it's better to be too broad than too narrow as far as our interests are
> concerned.
>
>
>
> The transport layer however, has some added complexity. In our context,
> we're shooting for interoperability, so we'd prefer something constrained.
> I appreciate Mike's input that these are application layer decisions.
> However, if we're talking about cloud provider-to-cloud provider
> communication, that certainly is facilitated by a well-defined transport
> layer. Again, we're willing to profile whatever the group comes up with for
> our own ends, but I don't really see the benefit of having a loosely
> defined transport layer - it just seems like more work for all the
> implementers to actually agree on endpoints on a case-by-case basis.
>
>
>
> http://engageidentity.com
>
>
>
> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) <[email-masked]>
> wrote:
>
> 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 <[email-masked]>
> *Sent: *Saturday, May 7, 2016 1:24 PM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Alan Karp <[email-masked]>; Morteza Ansari (moransar)
> <[email-masked]>; [email-masked]
> *Subject: *Re: [Id-event] Straw man text for proposed charter
>
>
>
> 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.
>
>
>
> On May 7, 2016, at 1:04 PM, Mike Jones <[email-masked]>
> wrote:
>
> 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 <[email-masked]>
> *Sent: *Saturday, May 7, 2016 10:23 AM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Morteza Ansari (moransar) <[email-masked]>; [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]>
> 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]>
> *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]> 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]
> [email-masked]
> [email-masked]
> [email-masked]

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 6 Sep 2016 17:11:11 -0700

+1 

Thanks Mike. 

Phil

> On Sep 6, 2016, at 5:04 PM, William Denniss <[email-masked]> wrote:
> 
> I support it, and hope we can form a WG with this charter to continue our work.
> 
>> On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones <[email-masked]> wrote:
>> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) <[email-masked]> wrote:
>> 
>> From: Vivek Biswas
>> To: Mike Jones
>> Cc: Alan Karp; Morteza Ansari (moransar); [email-masked]
>> 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: Id-event [mailto:[email-masked]] On Behalf Of Alan Karp
>> To: Morteza Ansari (moransar) <[email-masked]>
>> Cc: [email-masked]
>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <[email-masked]> wrote:
>> 
>> Hi folks,
>> 
>>  
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Sep 2016 17:40:57 -0700

Thanks Mike, it looks good.

Marius

On Tue, Sep 6, 2016 at 5:11 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

>> 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.
>>
>>
>>
>> Yes, I agree that the claims can be application specific, however there
>> is a possibility to define claims which are domain specific. Thereby claims
>> 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
>>
>>
>>
>> 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
>> 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.
>>
>>
>>

---

From: Vivek Biswas <[email-masked]>
Date: Wed, 7 Sep 2016 16:32:56 +0000 (UTC)

Hi Mike,
I believe there is one more item that MAY be added.
After the line "Methods for validating event feed subscriptions""Obligation that may be needed to be fulfilled upon validating an event feed".
RegardsVivek BiswasConsulting Member @SecurityOracle.

      From: Mike Jones <[email-masked]>
 To: "[email-masked]" <[email-masked]> 
Cc: Marius Scurtescu <[email-masked]>; Alexey Melnikov <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; William Denniss <[email-masked]>; Leif Johansson <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
 Sent: Tuesday, September 6, 2016 5:01 PM
 Subject: Re: [Id-event] Straw man text for proposed charter
   
#yiv8143991987 #yiv8143991987 -- _filtered #yiv8143991987 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8143991987 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8143991987 #yiv8143991987 p.yiv8143991987MsoNormal, #yiv8143991987 li.yiv8143991987MsoNormal, #yiv8143991987 div.yiv8143991987MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8143991987 a:link, #yiv8143991987 span.yiv8143991987MsoHyperlink {color:blue;text-decoration:underline;}#yiv8143991987 a:visited, #yiv8143991987 span.yiv8143991987MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8143991987 p.yiv8143991987msonormal0, #yiv8143991987 li.yiv8143991987msonormal0, #yiv8143991987 div.yiv8143991987msonormal0 {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8143991987 span.yiv8143991987hoenzb {}#yiv8143991987 span.yiv8143991987EmailStyle19 {color:#002060;}#yiv8143991987 .yiv8143991987MsoChpDefault {} _filtered #yiv8143991987 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8143991987 div.yiv8143991987WordSection1 {}#yiv8143991987 An updated and simplified charter is attached.  This draft has been reviewed by Phil Hunt, William Denniss, Marius Scurtescu.    Input from Alexey Melnikov is that we should probably charter a working group, rather than try to go the AD-sponsored route.  Therefore, please review this draft charter and let us know if you think it’s ready to go.                                                           Thanks,                                                        -- Mike    From: Sarah Squire [mailto:[email-masked]]
Sent: Thursday, July 14, 2016 10:59 PM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Mike Jones <[email-masked]>; Alan Karp <[email-masked]>; Vivek Biswas <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Straw man text for proposed charter    Just submitting my two cents in writing before we hopefully have a chance to meet about this next week...    Looking at this charter from the perspective of the OIDF HEART working group, I think it's going down a good path. In terms of the data format, this is less structured than what I was envisioning, but we could easily do a healthcare-specific profile of whatever data format comes out in the end, so it's better to be too broad than too narrow as far as our interests are concerned.    The transport layer however, has some added complexity. In our context, we're shooting for interoperability, so we'd prefer something constrained. I appreciate Mike's input that these are application layer decisions. However, if we're talking about cloud provider-to-cloud provider communication, that certainly is facilitated by a well-defined transport layer. Again, we're willing to profile whatever the group comes up with for our own ends, but I don't really see the benefit of having a loosely defined transport layer - it just seems like more work for all the implementers to actually agree on endpoints on a case-by-case basis.    Looking forward to discussing further in Berlin!    Sarah 
 Sarah Squire Engage Identity http://engageidentity.com    On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) <[email-masked]> wrote: 
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: 
Indeed, that’s why there’s a claims registry – so common claims can be defined once and then reused.   From:Vivek Biswas
Sent: Saturday, May 7, 2016 1:24 PM
To: Mike Jones
Cc: Alan Karp; Morteza Ansari (moransar); [email-masked]
Subject: Re: [Id-event] Straw man text for proposed charter   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,   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
Sent: Saturday, May 7, 2016 10:23 AM
To: Mike Jones
Cc: Morteza Ansari (moransar);[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]> 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 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]> 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: Phil Hunt <[email-masked]>
Date: Wed, 7 Sep 2016 09:50:04 -0700

Vivek,

Can you elaborate?

The validation just ensures that the endpoints actually work.  It also serves to block DoS issues where someone accidentally or intentionally tries to send SETs to an unwilling subscriber.

Phil

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

> On Sep 7, 2016, at 9:32 AM, Vivek Biswas <[email-masked]> wrote:
> 
> Hi Mike,
> 
> After the line "Methods for validating event feed subscriptions"
> "Obligation that may be needed to be fulfilled upon validating an event feed".
> 
> Regards
> Vivek Biswas
> Consulting Member @Security
> Oracle.
> 
> 
> 
> 
>   <applewebdata://F9C8DFD9-CBDA-4D7F-8D01-83EC3A9A6D5A>
> http://engageidentity.com <http://engageidentity.com/>
>  
> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> On May 7, 2016, at 13:31, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> From: Vivek Biswas <mailto:[email-masked]>
> To: Mike Jones <mailto:[email-masked]>
> Cc: Alan Karp <mailto:[email-masked]>; Morteza Ansari (moransar) <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On May 7, 2016, at 1:04 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Alan,
>  
> From: Alan Karp <mailto:[email-masked]>
> To: Mike Jones <mailto:[email-masked]>
> Cc: Morteza Ansari (moransar) <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Thu, May 5, 2016 at 10:00 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>   <applewebdata://F9C8DFD9-CBDA-4D7F-8D01-83EC3A9A6D5A>
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Alan Karp
> To: Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi folks,
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Vivek Biswas <[email-masked]>
Date: Wed, 7 Sep 2016 17:03:56 +0000 (UTC)

Hi Phil,
 Thanks for asking the question and also adding more description to the "validation" task.
The Obligation here means "Do we need to take any actions if the endpoints don't work"
Do we need to send any alert in case of someone is trying to do DoS attacks"
This obligation is an optional feature which can/may be fulfilled upon the validation task.
RegardsVivek BiswasConsulting Member @SecurityOracle

      From: Phil Hunt <[email-masked]>
 To: Vivek Biswas <[email-masked]> 
Cc: Mike Jones <[email-masked]>; "[email-masked]" <[email-masked]>; Marius Scurtescu <[email-masked]>; Alexey Melnikov <[email-masked]>; Morteza Ansari <[email-masked]>; William Denniss <[email-masked]>; Leif Johansson <[email-masked]>
 Sent: Wednesday, September 7, 2016 9:50 AM
 Subject: Re: [Id-event] Straw man text for proposed charter
   
Vivek,
Can you elaborate?
The validation just ensures that the endpoints actually work.  It also serves to block DoS issues where someone accidentally or intentionally tries to send SETs to an unwilling subscriber.
Phil
@[email-masked]

An updated and simplified charter is attached.  This draft has been reviewed by Phil Hunt, William Denniss, Marius Scurtescu. Input from Alexey Melnikov is that we should probably charter a working group, rather than try to go the AD-sponsored route.  Therefore, please review this draft charter and let us know if you think it’s ready to go.                                                        Thanks,                                                       -- Mike From: Sarah Squire [mailto:[email-masked]] 
Sent: Thursday, July 14, 2016 10:59 PM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Mike Jones <[email-masked]>; Alan Karp <[email-masked]>; Vivek Biswas <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Straw man text for proposed charter Just submitting my two cents in writing before we hopefully have a chance to meet about this next week... Looking at this charter from the perspective of the OIDF HEART working group, I think it's going down a good path. In terms of the data format, this is less structured than what I was envisioning, but we could easily do a healthcare-specific profile of whatever data format comes out in the end, so it's better to be too broad than too narrow as far as our interests are concerned. The transport layer however, has some added complexity. In our context, we're shooting for interoperability, so we'd prefer something constrained. I appreciate Mike's input that these are application layer decisions. However, if we're talking about cloud provider-to-cloud provider communication, that certainly is facilitated by a well-defined transport layer. Again, we're willing to profile whatever the group comes up with for our own ends, but I don't really see the benefit of having a loosely defined transport layer - it just seems like more work for all the implementers to actually agree on endpoints on a case-by-case basis. Looking forward to discussing further in Berlin! Sarah
Sarah SquireEngage Identityhttp://engageidentity.com On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) <[email-masked]> wrote:
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
Indeed, that’s why there’s a claims registry – so common claims can be defined once and then reused. From: Vivek Biswas

Sent from my iPhone
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

--------------
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

--------------
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: Phil Hunt <[email-masked]>
Date: Wed, 7 Sep 2016 10:13:49 -0700

Agreed. Though I don’t think we need to call it out specifically in the charter as the kind of detail required in almost every aspect.  For example, what should a receiver of a SET do before signalling an HTTP response should be assumed to be part of the draft.

Phil

@independentid

> On Sep 7, 2016, at 10:03 AM, Vivek Biswas <[email-masked]> wrote:
> 
> Hi Phil,
> 
> Oracle
>> On Sep 7, 2016, at 9:32 AM, Vivek Biswas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Mike,
>> 
>> From: Mike Jones <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> 
>> Cc: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>; Alexey Melnikov <[email-masked] <mailto:[email-masked]>>; Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>>; William Denniss <[email-masked] <mailto:[email-masked]>>; Leif Johansson <[email-masked] <mailto:[email-masked]>>; Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>
>>   <applewebdata://BEADDEE2-A293-4672-9C12-B7BE68FB55FE>
>> From: Sarah Squire [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>
>> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; Alan Karp <[email-masked] <mailto:[email-masked]>>; Vivek Biswas <[email-masked] <mailto:[email-masked]>>; Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>   <applewebdata://BEADDEE2-A293-4672-9C12-B7BE68FB55FE>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Sep 2016 12:04:33 +0100

Hi,
Just to let everyone know: I started chartering of the WG. The WG will
be in the Security Area (it was a borderline between ART and Security)
and your responsible AD is going to be Kathleen Moriarty.

Best Regards,
Alexey

P.S. I picked "SECEVENT" as the short WG name, but if you have better
     suggestions, please let me know.

On Wed, Sep 7, 2016, at 01:04 AM, William Denniss wrote:
>> reviewed by Phil Hunt, William Denniss, Marius Scurtescu.____
>> __ __
>> Input from Alexey Melnikov is that we should probably charter a
>> working group, rather than try to go the AD-sponsored route.
>> Therefore, please review this draft charter and let us know if you
>> think it’s ready to go.____
>> __ __
>>                                                        Thanks,____
>>                                                        -- Mike____
>> __ __
>>
>> *From:* Sarah Squire [mailto:[email-masked]] *Sent:*
>> Thursday, July 14, 2016 10:59 PM *To:* Phil Hunt (IDM)
>> <[email-masked]> *Cc:* Mike Jones
>> <[email-masked]>; Alan Karp <[email-masked]>; Vivek
>> Biswas <[email-masked]>; Morteza Ansari (moransar)
>> *Subject:* Re: [Id-event] Straw man text for proposed charter____
>>
>> __ __
>> Just submitting my two cents in writing before we hopefully have a
>> chance to meet about this next week...____
>> __ __
>> Looking at this charter from the perspective of the OIDF HEART
>> working group, I think it's going down a good path. In terms of the
>> data format, this is less structured than what I was envisioning, but
>> we could easily do a healthcare-specific profile of whatever data
>> format comes out in the end, so it's better to be too broad than too
>> narrow as far as our interests are concerned.____
>> __ __
>> The transport layer however, has some added complexity. In our
>> context, we're shooting for interoperability, so we'd prefer
>> something constrained. I appreciate Mike's input that these are
>> application layer decisions. However, if we're talking about cloud
>> provider-to-cloud provider communication, that certainly is
>> facilitated by a well-defined transport layer. Again, we're willing
>> to profile whatever the group comes up with for our own ends, but I
>> don't really see the benefit of having a loosely defined transport
>> layer - it just seems like more work for all the implementers to
>> actually agree on endpoints on a case-by-case basis.____
>> __ __
>> Looking forward to discussing further in Berlin!____
>> __ __
>> Sarah____
>> ____
>> Sarah Squire____
>> Engage Identity____
>> http://engageidentity.com[1]____
>> __ __
>> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM)
>> <[email-masked]> wrote:____
>>> We also set things up so even a domain specific event can be
>>> extended. ____
>>> __ __
>>> security domain specific attributes. The spec lets them do that
>>> while avoiding interop issues. ____
>>> __ __
>>> Phil____
>>> On May 7, 2016, at 13:31, Mike Jones <[email-masked]>
>>> wrote:____
>>>> Indeed, that’s why there’s a claims registry – so common claims can
>>>> be defined once and then reused.____
>>>>  ____
>>>> *From: *Vivek Biswas[2]
>>>> *To: *Mike Jones[3]
>>>> *Cc: *Alan Karp[4];  Morteza Ansari (moransar)[5];  id-
>>>> [email-masked]
>>>> *Subject: *Re: [Id-event] Straw man text for proposed charter____
>>>>  ____
>>>> 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____
>>>>  Sent from my iPhone____
>>>> On May 7, 2016, at 1:04 PM, Mike Jones
>>>> <[email-masked]> wrote:____
>>>>> Thanks Alan,____
>>>>>  ____
>>>>> interoperability.  The claims needed in an identity event are application-
>>>>> specific, just like claims are for JWTs.  This is the same
>>>>> interoperability, even if I do say so myself.____
>>>>>  ____
>>>>>                                                           Best wi-
>>>>>                                                           shes,__-
>>>>>                                                           __
>>>>>                                                           -- Mike-
>>>>>                                                           ____
>>>>>  ____
>>>>>  ____
>>>>>  ____
>>>>>  ____
>>>>> *From: *Alan Karp[6]
>>>>> *To: *Mike Jones[7]
>>>>> *Cc: *Morteza Ansari (moransar)[8]; [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]> 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 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.____
>>>>>>  ____
>>>>>>                                                           Sincer-
>>>>>>                                                           ely,__-
>>>>>>                                                           __
>>>>>>                                                           -- Mik-
>>>>>>                                                           e____
>>>>>>  ____
>>>>>> *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]> 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____
>>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/id-event____
>>>>>>  ____
>>>>> __ __
>>>>> https://www.ietf.org/mailman/listinfo/id-event____
>>>> https://www.ietf.org/mailman/listinfo/id-event____
>>>
>>> https://www.ietf.org/mailman/listinfo/id-event____
>> __ __

Links:

  1. http://engageidentity.com/
  2. mailto:[email-masked]
  3. mailto:[email-masked]
  4. mailto:[email-masked]
  5. mailto:[email-masked]
  6. mailto:[email-masked]
  7. mailto:[email-masked]
  8. mailto:[email-masked]

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Sat, 24 Sep 2016 11:27:10 +0000

This is great, thanks for helping speed up the process! Name is a name, so no comment on naming.

Cheers,
Morteza

On Sep 24, 2016, at 4:04 AM, Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
Just to let everyone know: I started chartering of the WG. The WG will be in the Security Area (it was a borderline between ART and Security) and your responsible AD is going to be Kathleen Moriarty.

Best Regards,
Alexey

P.S. I picked "SECEVENT" as the short WG name, but if you have better suggestions, please let me know.

On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       Thanks,

                                                       -- Mike

From: Sarah Squire [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, July 14, 2016 10:59 PM
To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Alan Karp <[email-masked]<mailto:[email-masked]>>; Vivek Biswas <[email-masked]<mailto:[email-masked]>>; Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Sarah

Sarah Squire

Engage Identity

Phil

-Vivek Biswas

Sent from my iPhone

Thanks Alan,

                                                          Best wishes,

                                                          -- Mike

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

                                                          Sincerely,

                                                          -- Mike

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

Hi folks,

Cheers,

Morteza

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Sep 2016 12:56:27 +0100

This also reminded me: how much time does this group want to request for
face-to-face meeting in Seoul?

On Sat, Sep 24, 2016, at 12:27 PM, Morteza Ansari (moransar) wrote:
> On Sep 24, 2016, at 4:04 AM, Alexey Melnikov
> <[email-masked]> wrote:
>
>> Hi,
>> Just to let everyone know: I started chartering of the WG. The WG
>> will be in the Security Area (it was a borderline between ART and
>> Security) and your responsible AD is going to be Kathleen Moriarty.
>>
>> Best Regards,
>> Alexey
>>
>>>> <[email-masked]>; Alan Karp <[email-masked]>;
>>>> Vivek Biswas <[email-masked]>; Morteza Ansari (moransar)
>>>> data format, this is less structured than what I was envisioning,
>>>> but we could easily do a healthcare-specific profile of whatever
>>>> data format comes out in the end, so it's better to be too broad
>>>> than too narrow as far as our interests are concerned.____
>>>> __ __
>>>>> I believe in the spec we had the example of an account reset and
>>>>> the publisher adds reset count as an extension.
>>>>>
>>>>> Phil____
>>>>>
>>>>>
>>>>>> Indeed, that’s why there’s a claims registry – so common claims
>>>>>> can be defined once and then reused.____
>>>>>>  ____
>>>>>>
>>>>>> *From: *Vivek Biswas[2]
>>>>>> 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.____
>>>>>> __ __
>>>>>>> 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
>>>>>>>                                                           wishe-
>>>>>>>                                                           s,____
>>>>>>>                                                           -- Mi-
>>>>>>>                                                           ke____
>>>>>>>  ____
>>>>>>>  ____
>>>>>>>  ____
>>>>>>>  ____
>>>>>>>
>>>>>>> *From: *Alan Karp[6]
>>>>>>> valid.  My only question is whether or not that will be enough
>>>>>>> for interoperability.____
>>>>>>> ____
>>>>>>>
>>>>>>>
>>>>>>> --------------
>>>>>>> Alan Karp____
>>>>>>>
>>>>>>> __ __
>>>>>>>> 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 events be unicast, multicast, or broadcast?  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.____
>>>>>>>> applications have different event delivery requirements.  We
>>>>>>>> MUST explicitly rule all delivery mechanisms as being out of
>>>>>>>> scope.____
>>>>>>>>  ____
>>>>>>>> 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.____
>>>>>>>>  ____
>>>>>>>>                                                           Sinc-
>>>>>>>>                                                           erel-
>>>>>>>>                                                           y,__-
>>>>>>>>                                                           __
>>>>>>>>                                                           --
>>>>>>>>                                                           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:* id-
>>>>>>>> [email-masked] *Subject:* Re: [Id-event] Straw man text for
>>>>>>>> proposed 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____
>>>>>>>>>
>>>>>>>>>

Links:

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sat, 24 Sep 2016 08:56:34 -0700

Alexy,

Thanks for helping this forwards. 

The name is fine. 

Phil

> On Sep 24, 2016, at 4:56 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> This also reminded me: how much time does this group want to request for face-to-face meeting in Seoul?
> 
>> On Sep 24, 2016, at 4:04 AM, Alexey Melnikov <[email-masked]> wrote:
>> 
>>> Hi,

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 26 Sep 2016 09:44:07 -0400

Hi,

It would be good to get a mail message to the SAAG list to announce
this, that it crosses areas and that I'll be the AD along with the
charter and other information.  Is there any other information that
should be in such an announcement?

Thanks,
Kathleen

On Sat, Sep 24, 2016 at 11:56 AM, Phil Hunt (IDM) <[email-masked]> wrote:
> Just to let everyone know: I started chartering of the WG. The WG will be in
> the Security Area (it was a borderline between ART and Security) and your
> responsible AD is going to be Kathleen Moriarty.
>
> Best Regards,
> Alexey
>
> An updated and simplified charter is attached.  This draft has been reviewed
> by Phil Hunt, William Denniss, Marius Scurtescu.
>
>
>
> Cc: Mike Jones <[email-masked]>; Alan Karp
> <[email-masked]>; Vivek Biswas <[email-masked]>; Morteza Ansari
> (moransar) <[email-masked]>; [email-masked]
>
>
> we're shooting for interoperability, so we'd prefer something constrained. I
> appreciate Mike's input that these are application layer decisions. However,
> if we're talking about cloud provider-to-cloud provider communication, that
> certainly is facilitated by a well-defined transport layer. Again, we're
> willing to profile whatever the group comes up with for our own ends, but I
> don't really see the benefit of having a loosely defined transport layer -
> it just seems like more work for all the implementers to actually agree on
> endpoints on a case-by-case basis.
>
>
>
> Yes, I agree that the claims can be application specific, however there is a
> possibility to define claims which are domain specific. Thereby claims
> specify a particular event delivery mechanism will take something that could
> be simple and quick to approve and bog it down in necessarily
> picking favorites and limiting applicability of the specification.  That way
> is a slow, painful descent into standards quicksand – something we must
> <[email-masked]> wrote:
>
> Hi folks,
>
>
>

-- 

Best regards,
Kathleen

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 26 Sep 2016 20:21:09 +0000

Hi Kathleen,

Great idea and hopefully it will get us some fresh blood in the WG for
contribution and reviews. I can¹t think of anything else to include beyond
what you suggested. We can do a complete review of the drafts in the works
in Seoul to catch up any new folks interested in participating (I won¹t be
there in person, but will join the meeting remotely).

I assume you or Alexey will send the note, but if you want one of us to
send it just let us know.

Cheers,
Morteza

On 9/26/16, 6:44 AM, "Kathleen Moriarty"
<[email-masked]> wrote:

>> This is great, thanks for helping speed up the process! Name is a name,
>>so
>> no comment on naming.
>>
>>
>>
>> Cheers,
>> Morteza
>>
>>be in
>>reviewed
>> review this draft charter and let us know if you think it¹s ready to go.
>>
>>
>>
>>                                                        Thanks,
>>
>>                                                        -- Mike
>>
>>
>>
>>
>>chance to
>> meet about this next week...
>>
>>
>>
>>layer -
>>security
>> Indeed, that¹s why there¹s a claims registry  so common claims can be
>> defined once and then reused.
>>
>>
>>
>>
>> From: Vivek Biswas
>>is a
>> standards posture and JWTs are a huge success  including for
>>My
>><[email-masked]>
>> wrote:
>>
>>could
>> 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
>> Should events have categories with category-specific subscriptions?
>>That¹s
>> an application-specific decision.
>>
>>events
>> or should multiple parties be able to request delivery?  That¹s an
>> I could continue with this list, but I think you all get the pointŠ
>>
>>
>>
>>we¹ll
>> 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
>> is a slow, painful descent into standards quicksand  something we must

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 26 Sep 2016 21:20:57 -0400

Hi Morteza,

> send it just let us know.

I don't mind sending it, but will wait to chat with Alexey first so we
are all coordinated.  Hopefully it will bring some new interest.

Thanks,
Kathleen

-- 

Best regards,
Kathleen