Subject: [Id-event] Draft adoption

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Dec 2016 23:37:25 +0200

Hi everyone,

The chairs would like to poll the WG regarding adoption of 
draft-hunt-idevent-token-07, however we both feel that one more revision 
would be useful before we do that. We ask the editors to focus this 
revision on the syntax of the "events" (or "event") JSON structure and 
how it reflects an event and its extensions. This is to ensure we have a 
more solid baseline proposal before we start the consensus process.

Happy New Year 2017!

     Dick and Yaron

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 28 Dec 2016 14:03:22 -0800

I propose we have two attributes along the lines of:

"evt" a required string URI describing the primary event

"ext" an optional multi valued string containing one or more extensions URIs to the primary event. 

If agreeable, I will propose some final wording. 

Note that this is a breaking change and will mean that it will no longer possible to express multiple events about the same state change or observation in one JWT unless one is an extension of the other. 

Because of the dependence issue do we need to also revert back to the IANA event registry proposed in the original drafts?

Phil

> On Dec 28, 2016, at 1:37 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi everyone,
> 
> The chairs would like to poll the WG regarding adoption of draft-hunt-idevent-token-07, however we both feel that one more revision would be useful before we do that. We ask the editors to focus this revision on the syntax of the "events" (or "event") JSON structure and how it reflects an event and its extensions. This is to ensure we have a more solid baseline proposal before we start the consensus process.
> 
> Happy New Year 2017!
> 
>     Dick and Yaron
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Dec 2016 00:31:51 +0000

I’m not happy with this proposed change.  It seems to be overly complicating what was formerly a simple structure.

I believe “events” remains the right syntax.  It allows multiple related events to be cleanly expressed.

Rather than trying to differentiate between “primary” and “secondary” events, I would counter-propose that we drop the distinction entirely.  All the related events listed in the “events” struct occurred.  Whether one is “primary” is arguably unimportant, since the communicating parties will process all the information sent for all the related events.  Let’s simplify things by removing the primary/secondary distinction, rather than complicating things by having two related syntaxes.

I’m also going to raise a process point.  I know that I haven’t read or responded to Yaron’s comments yet because they came in during the holidays.  I suspect this is true of many others as well.  Before making any breaking changes, I’d ask that we have a least a week’s discussion period after January 2nd.

                                                       Thanks,
                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, December 28, 2016 2:03 PM
To: Yaron Sheffer <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Draft adoption

Phil

On Dec 28, 2016, at 1:37 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Hi everyone,

Happy New Year 2017!

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Dec 2016 21:49:36 -0500

-1 to this proposed new syntax. I rather like the simplified structure of:

“events": {
 “event1:foo:bar”: {“eventstuff”:”goes here”}
 “event2:foo:bar”: {“other event stuff”: “goes here too”, “right?”: true}
 “event3:this:one:is:empty”: {}
}

I don’t like the idea of core events and extensions and all that — I think it makes things more complicated than necessary. Each thing inside the “events” object should be about itself. If you want to extend it, then it’s up to you whether to use the sub-object (since JSON is schema-by-fiat you can usually get away with it in the real world) or have a parallel data structure as another “event” next to it. But it’s up to your application as to how that works. So we should drop the notion of primary and secondary and core and extension entirely — you’ve just got a list of event objects, each lives in its own namespace. 

What we can do here is say that everything in the “events” object is related to each other in some fashion, and that fashion should be discoverable by looking at the envelope information in the root claims. We can *also* provide guidance for what kinds of things go inside those so that people aren’t constantly making up new terms to mean the same thing across different events. For example, all the core JWT claims should have a similar meaning inside an event object, which itself is nestled inside the “events” collection in the JWT.

That said, I’m not against shortening “events” to “evt” to fit with other JWT tln's. And as much as Mike loves the explicit plural, I dislike “evs” or “ets” or something like that if we’re doing three letters. If we keep it long, “events” is fine with me.

 — Justin

> On Dec 28, 2016, at 5:03 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> On Dec 28, 2016, at 1:37 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi everyone,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 29 Dec 2016 18:39:13 +0200

Hi Mike,

(chair hat on): I'm absolutely OK with your process proposal.

(hat off): Excuse for for being pedantic about JSON syntax. If we want 
to support multiple events, this should be an array, not an object. This 
indicates an ordering between events, and also allows clean handling of 
multiple events of the same type.

I will let others decide whether we need a single event per SET or multiple.

Thanks,
	Yaron

On 29/12/16 02:31, Mike Jones wrote:
> I’m not happy with this proposed change.  It seems to be overly
> complicating what was formerly a simple structure.
>
>
>
> Rather than trying to differentiate between “primary” and “secondary”
> events, I would counter-propose that we drop the distinction entirely.
> All the related events listed in the “events” struct occurred.  Whether
> one is “primary” is arguably unimportant, since the communicating
> parties will process all the information sent for all the related
> events.  Let’s simplify things by removing the primary/secondary
> distinction, rather than complicating things by having two related syntaxes.
>
>
>
> I’m also going to raise a process point.  I know that I haven’t read or
> responded to Yaron’s comments yet because they came in during the
> holidays.  I suspect this is true of many others as well.  Before making
> any breaking changes, I’d ask that we have a least a week’s discussion
> period after January 2^nd .
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *Phil
> Hunt (IDM)
> *Sent:* Wednesday, December 28, 2016 2:03 PM
> *To:* Yaron Sheffer <[email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Draft adoption
>
>
>
> Note that this is a breaking change and will mean that it will no longer
> possible to express multiple events about the same state change or
> observation in one JWT unless one is an extension of the other.
>
>
>
> Because of the dependence issue do we need to also revert back to the
> IANA event registry proposed in the original drafts?
>
>
>
> Phil
>
>
>     draft-hunt-idevent-token-07, however we both feel that one more
>     revision would be useful before we do that. We ask the editors to
>     focus this revision on the syntax of the "events" (or "event") JSON
>     structure and how it reflects an event and its extensions. This is
>     to ensure we have a more solid baseline proposal before we start the
>     consensus process.
>
>     Happy New Year 2017!
>
>         Dick and Yaron
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Dec 2016 19:51:49 +0000

I agree with you that we want to use JSON syntax in a natural way, Yaron.  In fact, it was those considerations that led us to the current syntax, having moved away from the previous array syntax.

The current "events" claim syntax cleanly and concisely represents a set of related events.  They are unordered by design, with no "primary" event.  I agree that the editors (myself included) have work to do to finish removing the vestiges of the old syntax, in which events were ordered.  I think that the spec will be much less confusing after that.  I agree with your decision for us to produce a new, cleaner individual draft before adoption as a working group document.  Thanks for urging us to get it right!

				Cheers,
				-- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Thursday, December 29, 2016 8:39 AM
To: Mike Jones <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Draft adoption

Hi Mike,

(hat off): Excuse for for being pedantic about JSON syntax. If we want to support multiple events, this should be an array, not an object. This indicates an ordering between events, and also allows clean handling of multiple events of the same type.

Thanks,
	Yaron

On 29/12/16 02:31, Mike Jones wrote:
> All the related events listed in the “events” struct occurred.  
> Whether one is “primary” is arguably unimportant, since the 
> communicating parties will process all the information sent for all 
> the related events.  Let’s simplify things by removing the 
> primary/secondary distinction, rather than complicating things by having two related syntaxes.
>
>
>
> I’m also going to raise a process point.  I know that I haven’t read 
> or responded to Yaron’s comments yet because they came in during the 
> holidays.  I suspect this is true of many others as well.  Before 
> making any breaking changes, I’d ask that we have a least a week’s 
> discussion period after January 2^nd .
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of 
> *Phil Hunt (IDM)
> Note that this is a breaking change and will mean that it will no 
> longer possible to express multiple events about the same state change 
> or observation in one JWT unless one is an extension of the other.
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Dec 2016 12:00:18 -0800

+1

Phil

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

> On Dec 29, 2016, at 11:51 AM, Mike Jones <[email-masked]> wrote:
>