Subject: [Id-event] ID Event Token Simplification

From: Mike Jones <[email-masked]>
Date: Wed, 24 Aug 2016 20:32:35 +0000

A number of the ID Event Token contributors were discussing the ID Event Token format yesterday and we came up with what seems like rough consensus on a way to keep the ID Event Token spec simple enough that it's likely to be accepted by the security ADs and IESG as an individual submission.  The background on the agreement is this:

*       JWTs containing events will contain only one or more related events in a family of events, and not be a container of sets of unrelated events.

*       The primary event will be the first event in the "events" list and the related events will be 2nd, 3rd, etc.

*       Claims pertaining to the family events should be top-level claims.  These should be registered in the JWT Claims Registry unless they are private claim names or public claim names (as defined in JWT sections 4.2 and 4.3).

*       Claims pertaining only to an individual event should be values within a claim using the same name as the event.  These values need only be defined within the event definition and need not be registered as top-level claim names.

*       It is up to each event family and individual event what claims are included with the event family and event.

This works well because event listeners are listening for a defined family of events and those only.  Any events that the listeners doesn't recognize will be either ignored or generate errors, depending upon the application context.  Likewise, receiving a JWT without an "events" claim at an events listener should likely generate an error as well.

We are explicitly steering clear of the SOAP pattern, in which a general-purpose message dispatcher was the listener.  Developers have voted with their feet in avoiding this pattern.  We will be wise to do the same.

The set of rules above is straightforward and doesn't raise any complicated questions.  It should enable us to get the spec approved soon.

I believe that Phil is working on changes for -04 along these lines.  Phil can follow up from here.

                                                       Thanks all,
                                                       -- Mike

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Aug 2016 13:48:40 -0700

Yes. This is close to option A. 

I wanted to make sure the group could see all the options. 

Thanks

Phil

> On Aug 24, 2016, at 1:32 PM, Mike Jones <[email-masked]> wrote:
> 
> A number of the ID Event Token contributors were discussing the ID Event Token format yesterday and we came up with what seems like rough consensus on a way to keep the ID Event Token spec simple enough that it’s likely to be accepted by the security ADs and IESG as an individual submission.  The background on the agreement is this:
>  
> ·       JWTs containing events will contain only one or more related events in a family of events, and not be a container of sets of unrelated events.
> ·       The primary event will be the first event in the “events” list and the related events will be 2nd, 3rd, etc.
> ·       Claims pertaining to the family events should be top-level claims.  These should be registered in the JWT Claims Registry unless they are private claim names or public claim names (as defined in JWT sections 4.2 and 4.3).
> ·       Claims pertaining only to an individual event should be values within a claim using the same name as the event.  These values need only be defined within the event definition and need not be registered as top-level claim names.
> ·       It is up to each event family and individual event what claims are included with the event family and event.
>  
> This works well because event listeners are listening for a defined family of events and those only.  Any events that the listeners doesn’t recognize will be either ignored or generate errors, depending upon the application context.  Likewise,  receiving a JWT without an “events” claim at an events listener should likely generate an error as well.
>  
> The set of rules above is straightforward and doesn’t raise any complicated questions.  It should enable us to get the spec approved soon.
>  
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Aug 2016 17:12:57 -0700

Mike,

Apologies, I just re-read and I missed something that might be a mistake in your text.  If you disagree we need to keep discussing.

See inline.

Phil

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

> ·       JWTs containing events will contain only one or more related events in a family of events, and not be a container of sets of unrelated events.
I believe the consensus is one and only one event plus extensions.  An extension might be from a different family entirely but related to the primary event.  For example, some might have context specific needs to extend between partners.  Or, some might want to add catergorization information to the event (e.g. for multi-event threat analysis) such as Cybox Threat categories.

> ·       The primary event will be the first event in the “events” list and the related events will be 2nd, 3rd, etc.
So the 2nd, 3rd etc are “extensions” to the primary event.  They are not dual events.

When we originally discussed “multi-events” the case was when two different families had overlapping event definitions. So the hypothetical scenarios was:  Both SCIM and RISC might have an “account reset event”.  Should those be two separate events (for the same actual event), OR should they be expressed together in a single JWT?

The consensus so far has been that such a scenario that has subscribers for SCIM and RISC would generate two separate SETs.

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Aug 2016 00:43:16 +0000

A “family” in my mind, realistically, was a group of events that have compatible claims usage – probably a result of them either being defined together, or possibly because they all belong to the same events framework, that defines the claims usage for the framework.  (Feel free to use text like the above in the spec’s description of event families, by the say.)

I don’t personally see any difference between a primary event and an extension event, other than one is the first array element.  If there’s not an enforceable semantic difference that matters, I don’t think that the text should try too hard to distinguish between them either.  Making artificial distinctions would likely only make things unnecessarily brittle, because we can’t anticipate the nature of every use case.

Does that make sense?  Thanks for asking.

                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 5:13 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] ID Event Token Simplification

Mike,

See inline.

Phil

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

On Aug 24, 2016, at 1:32 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

•       JWTs containing events will contain only one or more related events in a family of events, and not be a container of sets of unrelated events.
I believe the consensus is one and only one event plus extensions.  An extension might be from a different family entirely but related to the primary event.  For example, some might have context specific needs to extend between partners.  Or, some might want to add catergorization information to the event (e.g. for multi-event threat analysis) such as Cybox Threat categories.

•       The primary event will be the first event in the “events” list and the related events will be 2nd, 3rd, etc.
So the 2nd, 3rd etc are “extensions” to the primary event.  They are not dual events.

•       Claims pertaining to the family events should be top-level claims.  These should be registered in the JWT Claims Registry unless they are private claim names or public claim names (as defined in JWT sections 4.2 and 4.3).
•       Claims pertaining only to an individual event should be values within a claim using the same name as the event.  These values need only be defined within the event definition and need not be registered as top-level claim names.
•       It is up to each event family and individual event what claims are included with the event family and event.

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