Re: [Id-event] Consensus :: Single Event Syntax

[Benjamin Kaduk <[e-mail]>]

Sure, they're not your assertions; they're Annabelle's assertions.  But
the question at hand is whether you believe or disbelieve that the
assertions are true of the current draft (and, if so, whether they
should move from implicit to explicit assumptions).

It sounds like you are saying that you do not believe the two assertions
are true of the current draft, but could you please be explicit about
your personal beliefs (as opposed to Mike's)?

Thanks,

Ben

On 12/13/2017 08:39 PM, Phil Hunt wrote:
> Those aren’t my assertions.
>
> The draft is written based on group input. So no, not everything is
> backed directly by case. It is backed by consensus.  
>
> Mike’s comments that just like JWT’s can have different content per
> audience, so can a stream of SET per receiver.  So single event only
> SETs and multi-aspect SETs are possible.  
>
> If the receiver wants multi-aspect SETs, I doubt they would find them
> ambiguous.
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=85cyhAYmmz380nKWOgwzhl0dZmKMtiFnEEge6fiK1rA&s=iccVyyTJcw_ZwESlqJw6m2HkrrnU0xd4xZjIbfavofA&e=>
> [e-mail] <mailto:[e-mail]>
>
>> On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> The ones in my previous email (quoted below):
>>  
>> The current syntax doesn’t even work for the professed use case,
>> without two unstated constraints:
>> 1.       Two instances of a single type of event statement cannot be
>> related to the same logical event.
>> 2.       The combination of event statements cannot be ambiguous.
>>  
>> If the current draft intends to impose these limits, they need to be
>> stated in the text. But more importantly, what is the basis for
>> imposing these limitations on SET in the first place?
>>  
>> -- 
>> Annabelle Richard Backman
>> Amazon – Identity Services
>>  
>>  
>> *From: *Phil Hunt <[e-mail] <mailto:[e-mail]>>
>> *Date: *Wednesday, December 13, 2017 at 5:53 PM
>> *To: *"Richard Backman, Annabelle" <[e-mail]
>> <mailto:[e-mail]>>
>> *Cc: *Justin Richer <[e-mail] <mailto:[e-mail]>>,
>> "[e-mail] <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>
>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>  
>> What restrictions are you referring to? 
>>  
>> Phil
>>  
>> Oracle Corporation, Identity Cloud Services Architect
>> @independentid
>> www.independentid.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=HKiKUZgXDLuGHjfG_wYgXCVNOctJXueCEh63hvF_ixc&s=nvU8oqF7Izoh-0sBdFy3FOwGW-pNlwpynSj4aet5atE&e=>
>> [e-mail] <mailto:[e-mail]>
>>
>>
>>> On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>  
>>> Phil,
>>>  
>>> As the author of the current draft, can you clarify whether these
>>> restrictions are intentional, and if so why the use cases for SET
>>> are being restricted in this way?
>>>  
>>> -- 
>>> Annabelle Richard Backman
>>> Amazon – Identity Services
>>>  
>>>  
>>> *From: *"Richard Backman, Annabelle" <[e-mail]
>>> <mailto:[e-mail]>>
>>> *Date: *Monday, December 11, 2017 at 10:09 AM
>>> *To: *Justin Richer <[e-mail] <mailto:[e-mail]>>,
>>> "[e-mail] <mailto:[e-mail]>" <[e-mail]
>>> <mailto:[e-mail]>>
>>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>>  
>>> The current syntax doesn’t even work for the professed use case,
>>> without two unstated constraints:
>>>
>>>  1. Two instances of a single type of event statement cannot be
>>>     related to the same logical event.
>>>  2. The combination of event statements cannot be ambiguous.
>>>
>>>  
>>> If the current draft intends to impose these limits, they need to be
>>> stated in the text. But more importantly, what is the basis for
>>> imposing these limitations on SET in the first place?
>>>  
>>> -- 
>>> Annabelle Richard Backman
>>> Amazon – Identity Services
>>>  
>>>  
>>> *From: *Id-event <[e-mail]
>>> <mailto:[e-mail]>> on behalf of Justin Richer
>>> <[e-mail] <mailto:[e-mail]>>
>>> *Date: *Saturday, December 9, 2017 at 6:04 AM
>>> *To: *"[e-mail] <mailto:[e-mail]>"
>>> <[e-mail] <mailto:[e-mail]>>
>>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>>  
>>> So the current syntax doesn't work for Tony's stated use case of
>>> even bundles while the new syntax does, then.
>>>  
>>> On 12/5/2017 5:50 PM, Mike Jones wrote:
>>>> The “events” claim definition is already clear that the “events”
>>>> values convey multiple aspects of a single logical event - not
>>>> independent events.  Section 2.1 (Core Set Claims) says:
>>>>    events
>>>>       The semantics of this claim is to define a set of event
>>>> statements
>>>>       that each MAY add additional claims to fully describe a single
>>>>       logical event that has occurred (e.g. a state change to a
>>>>       subject). … The "events" claim SHOULD NOT be used to express
>>>>       multiple logical events.
>>>>  
>>>> You’re describing a theoretical problem that’s not actually present
>>>> in the working group spec.
>>>>  
>>>>                                                                 -- Mike
>>>>  
>>>> *From:* Richard Backman, Annabelle [mailto:[e-mail]] 
>>>> *Sent:* Tuesday, December 5, 2017 2:06 PM
>>>> *To:* Mike Jones <[e-mail]>
>>>> <mailto:[e-mail]>; Phil
>>>> Hunt <[e-mail]> <mailto:[e-mail]>
>>>> *Cc:* William Denniss <[e-mail]>
>>>> <mailto:[e-mail]>;
>>>> M.Lizar@OCG <[e-mail]>
>>>> <mailto:[e-mail]>; Yaron
>>>> Sheffer <[e-mail]> <mailto:[e-mail]>;
>>>> Dick Hardt <[e-mail]> <mailto:[e-mail]>;
>>>> SecEvent <[e-mail]> <mailto:[e-mail]>
>>>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>>>  
>>>> Once again, I am not talking about the meaning of a given event
>>>> type or its contents. I’m talking about the meaning of putting an
>>>> event in an “events” claim alongside another event in the same SET.
>>>>  
>>>> Drawing an analogy to programming, I’m talking about defining what
>>>> the syntax “function_x() && function_y()” means. Regardless of what
>>>> “function_x” and “function_y” mean, the language defines the
>>>> meaning of that syntax as “true if the result of function_x is true
>>>> and the result of function_y is true.”
>>>>  
>>>> -- 
>>>> Annabelle Richard Backman
>>>> Amazon – Identity Services
>>>>  
>>>>  
>>>> *From: *Mike Jones <[e-mail]
>>>> <mailto:[e-mail]>>
>>>> *Date: *Tuesday, December 5, 2017 at 1:30 PM
>>>> *To: *Phil Hunt <[e-mail]
>>>> <mailto:[e-mail]>>, "Richard Backman, Annabelle"
>>>> <[e-mail] <mailto:[e-mail]>>
>>>> *Cc: *William Denniss <[e-mail]
>>>> <mailto:[e-mail]>>, "M.Lizar@OCG <mailto:M.Lizar@OCG>"
>>>> <[e-mail]
>>>> <mailto:[e-mail]>>, Yaron Sheffer
>>>> <[e-mail] <mailto:[e-mail]>>, Dick Hardt
>>>> <[e-mail] <mailto:[e-mail]>>, SecEvent
>>>> <[e-mail] <mailto:[e-mail]>>
>>>> *Subject: *RE: [Id-event] Consensus :: Single Event Syntax
>>>>  
>>>> Hi Annabelle,
>>>>  
>>>> The data contained in a SET and the semantics of that data will
>>>> **always** be profile-specific.  That’s a feature – not a bug. 
>>>> It’s what makes SETs general-purpose, rather than being suited only
>>>> for a narrow set of use cases.
>>>>  
>>>> An analogy with JWTs is applicable.  JWTs have no required claims,
>>>> so their usage is always profile-specific.  That has enabled them
>>>> to be adopted by numerous diverse applications.  SETs currently
>>>> have that same level of flexibility – by design.
>>>>  
>>>>                                                                 -- Mike
>>>>  
>>>> *From:* Phil Hunt [mailto:[e-mail]] 
>>>> *Sent:* Tuesday, December 5, 2017 1:22 PM
>>>> *To:* Richard Backman, Annabelle <[e-mail]
>>>> <mailto:[e-mail]>>
>>>> *Cc:* Mike Jones <[e-mail]
>>>> <mailto:[e-mail]>>; William Denniss
>>>> <[e-mail] <mailto:[e-mail]>>; M.Lizar@OCG
>>>> <mailto:M.Lizar@OCG> <[e-mail]
>>>> <mailto:[e-mail]>>; Yaron Sheffer
>>>> <[e-mail] <mailto:[e-mail]>>; Dick Hardt
>>>> <[e-mail] <mailto:[e-mail]>>; SecEvent
>>>> <[e-mail] <mailto:[e-mail]>>
>>>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>>>  
>>>> I would disagree strongly with the notion of inter-operability
>>>> requirements on expected outcomes or actions by receivers.
>>>>  
>>>> SETs are statements of changes in state of security objects by
>>>> transmitters. SETs do not indicate any specific actions that should
>>>> be taken by receivers. 
>>>>  
>>>> I believe I’ve covered this issue during the informal BOF (at the
>>>> SCIM WG meeting Argentina) and several times during IETF WG meeting
>>>> presentations. I did so, because within the IETF community many
>>>> people have vastly different notions of what an event is.
>>>>  
>>>> Phil
>>>>  
>>>> Oracle Corporation, Identity Cloud Services Architect
>>>> @independentid
>>>> www.independentid.com
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=tqqw1ywr-k_fQTVlTIQ-V24SRkRzlh5clMJQKLMLANw&e=>
>>>> [e-mail] <mailto:[e-mail]>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle
>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>  
>>>>> Mike,
>>>>>  
>>>>> This isn’t simply an issue of “single vs multiple” – the current
>>>>> draft is fundamentally broken from an interoperability standpoint,
>>>>> because the correct interpretation of the “events” claim is at
>>>>> best profile-specific, at worst implementation-specific.
>>>>>  
>>>>> -- 
>>>>> Annabelle Richard Backman
>>>>> Amazon – Identity Services
>>>>>  
>>>>>  
>>>>> *From: *Mike Jones <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> *Date: *Tuesday, December 5, 2017 at 12:22 PM
>>>>> *To: *"Richard Backman, Annabelle" <[e-mail]
>>>>> <mailto:[e-mail]>>, William Denniss
>>>>> <[e-mail] <mailto:[e-mail]>>, "M.Lizar@OCG
>>>>> <mailto:M.Lizar@OCG>" <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> *Cc: *Yaron Sheffer <[e-mail]
>>>>> <mailto:[e-mail]>>, Phil Hunt <[e-mail]
>>>>> <mailto:[e-mail]>>, SecEvent <[e-mail]
>>>>> <mailto:[e-mail]>>, Dick Hardt <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> *Subject: *RE: [Id-event] Consensus :: Single Event Syntax
>>>>>  
>>>>> Morteza already pointed out
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_KPaK5aN3EeIybWJmQOJiqdHXQzg&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=ZClAgy65x4a1O93YYenj_z_6Bxd_6sMzPOs8PLi06XA&e=> a
>>>>> simple solution to enabling SETs to contain only a single event
>>>>> description for profiles that want that – a solution proposed by
>>>>> Yaron
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=tac2j_cTgyBwnnfHNTPzlRUwOCjxvascShR4JfccwMg&e=> that
>>>>> doesn’t involve making any breaking changes:  Explicitly specify
>>>>> that profiles can restrict the number of elements in the “events”
>>>>> data structure – including limiting them to one element, when
>>>>> desired.  Then profiles that want this can have it and profiles
>>>>> that need to enable multiple aspects of an event to be easily
>>>>> represented can have that too.  Hopefully people can rally around
>>>>> that straightforward solution, enabling us to move on and finish
>>>>> the SET spec in as timely a fashion as possible.
>>>>>  
>>>>>                                                                 --
>>>>> Mike
>>>>>  
>>>>> *From:* Id-event [mailto:[e-mail]] *On Behalf
>>>>> Of *Richard Backman, Annabelle
>>>>> *Sent:* Tuesday, December 5, 2017 11:40 AM
>>>>> *To:* William Denniss <[e-mail]
>>>>> <mailto:[e-mail]>>; M.Lizar@OCG
>>>>> <mailto:M.Lizar@OCG> <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> *Cc:* Yaron Sheffer <[e-mail]
>>>>> <mailto:[e-mail]>>; Phil Hunt <[e-mail]
>>>>> <mailto:[e-mail]>>; SecEvent <[e-mail]
>>>>> <mailto:[e-mail]>>; Dick Hardt <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>>>>>  
>>>>> William’s email analogy demonstrates the problem with the current
>>>>> syntax: imagine if the text part of a multi-part email could be
>>>>> any of the following, with no explicit indication which one it is:
>>>>>
>>>>>   * A plaintext representation of the same content in the HTML part. 
>>>>>   * The CSS to use when rendering the HTML part. 
>>>>>   * Annotations on the contents of the HTML part. 
>>>>>   * A vCard for the sender of the message. 
>>>>>   * A completely separate message with a separate subject line
>>>>>     embedded in the text. 
>>>>>
>>>>>  
>>>>> How would a mail reader know what to do with this? It couldn’t,
>>>>> not in any scalable way. Yet is exactly the situation we will
>>>>> have, given the current draft and the way people are proposing
>>>>> using its multi-part capability:
>>>>>
>>>>>   * William wants to use it to send different independent
>>>>>     representations of the same event.
>>>>>   * Phil wants to use it to send different aspects of the same
>>>>>     event, intended to be processed together.
>>>>>   * Tony wants to use it for directory synchronization. 
>>>>>   * Marius wants to use it to send the same event under both
>>>>>     standard and deprecated names.
>>>>>   * et cetera, et cetera… 
>>>>>
>>>>>  
>>>>> This confusion is going to limit reusability and interoperability,
>>>>> and hinder adoption. If the WG consensus is that all these use
>>>>> cases are in scope for SET, that’s fine, we can support them – but
>>>>> we need to do so in a way that doesn’t create complete chaos.
>>>>>  
>>>>> At risk of repeating myself, maybe we need to have a consensus
>>>>> discussion on which multi-part use cases are in scope for SET
>>>>> before we continue with this discussion?
>>>>>  
>>>>> -- 
>>>>> Annabelle Richard Backman
>>>>> Amazon – Identity Services
>>>>>  
>>>>>  
>>>>> *From: *Id-event <[e-mail]
>>>>> <mailto:[e-mail]>> on behalf of William Denniss
>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>> *Date: *Monday, December 4, 2017 at 7:20 PM
>>>>> *To: *"M.Lizar@OCG <mailto:M.Lizar@OCG>"
>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>> *Cc: *Yaron Sheffer <[e-mail]
>>>>> <mailto:[e-mail]>>, Dick Hardt <[e-mail]
>>>>> <mailto:[e-mail]>>, SecEvent <[e-mail]
>>>>> <mailto:[e-mail]>>, Phil Hunt <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>>>>>  
>>>>> I would prefer to keep the format in the current working group draft.
>>>>>
>>>>> Based on the requirement that events may be represented in
>>>>> multiple ways, I believe having both formats carried in a single
>>>>> SET is superior as it avoids complex linking logic. The best
>>>>> analogy I can think of is email, where MIME allows for text and
>>>>> html versions *of the same content* to be carried in a single
>>>>> email (much like how SET allows for multiple representations *of
>>>>> the same event* in a SET). With email, the recipient's client is
>>>>> then able to display the version it prefers from those available.
>>>>> Imagine the additional logic if every email was sent twice – e.g.
>>>>> what if the plain text version arrives, the HTML one is delayed?
>>>>> How should the client react if the HTML version arrives later,
>>>>> would it replace the version it had? What if you were already
>>>>> viewing and/or replying?
>>>>>
>>>>> Time-wise I'm really concerned if we don't lock this down soon,
>>>>> the people who are waiting on us to profile SET will walk away and
>>>>> do their own thing (I was worried about that a year ago… and I
>>>>> think we've waited long enough). I think we should keep this in
>>>>> mind and choose the path that will have the fastest resolution. 
>>>>> If the decision was to change the format at this late stage, I
>>>>> would like to hear what steps can be done to avoid additional delay.
>>>>>
>>>>> I really respect the work Annabelle has done in leading the
>>>>> alternative representation, and I do think it’s a viable
>>>>> alternative. If we choose to change the spec and go with the
>>>>> singular option, then I think the requirement of multiple
>>>>> representations should be dropped, or at a minimum de-emphasized
>>>>> as this (along with expediency) is the main reason I believe the
>>>>> existing format is better.
>>>>>  
>>>>>  
>>>>> On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG
>>>>> <mailto:M.Lizar@OCG> <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>>> Small typo,  -  should be a  ‘.’ Not a ‘?’ 
>>>>>>  
>>>>>> The spec works well for the consent a privacy syntax use cases we
>>>>>> are aware of (full stop) 
>>>>>>  
>>>>>> - Mark
>>>>>>
>>>>>>  
>>>>>>
>>>>>>> On 4 Dec 2017, at 20:46, M.Lizar@OCG
>>>>>>> <mailto:M.Lizar@OCG> <[e-mail]
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>  
>>>>>>>  
>>>>>>> I concur with Mike and Justin, we had the same issue with
>>>>>>> primary and secondary in the Consent Receipt spec. 
>>>>>>>  
>>>>>>> We are also opposed  to making breaking changes at this late
>>>>>>> date and that the existing working group spec already works well
>>>>>>> for the consent and privacy use cases we are aware of? 
>>>>>>>  
>>>>>>> Mark Lizar | CEO Open Consent | Co-Char CISWG at Kantara
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>> On 1 Dec 2017, at 18:35, Phil Hunt <[e-mail]
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>  
>>>>>>>> For historical purposes, this has been discussed twice before
>>>>>>>> (once at the request of Annabelle).
>>>>>>>>  
>>>>>>>> I think it would be helpful, why, after WGLC, this issue is
>>>>>>>> being brought forward yet again. Dick has stated that
>>>>>>>> Annabelle’s concern that she finds it difficult to implement is
>>>>>>>> sufficient.  Yet, I’m not sure we are entertaining a new
>>>>>>>> concern here. No new information was provided. 
>>>>>>>>  
>>>>>>>> I note that at the time, the chairs did not feel there was a
>>>>>>>> lack of consensus in order to call for one in the past.
>>>>>>>>  
>>>>>>>> On some of these matters, the choice may be arbitrary, and that
>>>>>>>> is why I think keeping track of prior discussion is important
>>>>>>>> so that we can clearly move forward and not repeat discussion
>>>>>>>> of the past further confusing consensus.
>>>>>>>>  
>>>>>>>> While I advocated for singular events as a possibility in the
>>>>>>>> past, I now have much more stronger technical reasons for the
>>>>>>>> WG draft design, which have strengthened rather than weakened
>>>>>>>> in the past week. I will share these later, after the minutes
>>>>>>>> have been published.
>>>>>>>>  
>>>>>>>> On Dec 10, 2016, Yaron while reviewing the ID
>>>>>>>> draft-hunt-idevent-token-07 [1]:
>>>>>>>>>>   * Why "events" and not "event"? We don't really have support for
>>>>>>>>>>     multiple events. Certainly not if they are all of the same type.
>>>>>>>>>>     The current text is confusing: "events" is not the same as "a
>>>>>>>>>>     primary event and its extensions”.
>>>>>>>>> [MIKE] Reflects your earlier comment re: primary vs. extensions.  "events” is
>>>>>>>>> plural to reflect the fact that the attribute is multi-valued. I agree,
>>>>>>>>> given that only one primary event can be included, the naming is misleading.
>>>>>>>>  
>>>>>>>> From later in the thread [2]:
>>>>>>>>>>>>  * 2: "first value" is meaningless. JSON objects are
>>>>>>>>>>>> unordered (4th
>>>>>>>>>>>>    paragraph of RFC 7159). If order /is/ important, we
>>>>>>>>>>>> could make
>>>>>>>>>>>>    "events" into an array.
>>>>>>>>>>> _[Phil] _Yup.   How would the group like to fix this?  We
>>>>>>>>>>> could make “events”
>>>>>>>>>>> singular and have an extensions attribute to hold the
>>>>>>>>>>> extensions.  Or we
>>>>>>>>>>> could go to a more complex JSON structure (not personally a
>>>>>>>>>>> fan).
>>>>>>>>>>
>>>>>>>>>> _[Yaron]_ I'm personally fine with a main "event" object and
>>>>>>>>>> an "extensions" attribute. I can even live with "event" being
>>>>>>>>>> called "events", per Mike's proposal. But the structure needs
>>>>>>>>>> to make sense as a JSON object if we want it implemented.
>>>>>>>>>  
>>>>>>>>> [PH] Thread: Should the primary event be a separate attribute?
>>>>>>>>>  
>>>>>>>>> We had this broken out before. If there is sufficient desire
>>>>>>>>> to break it out again, I have no objection.
>>>>>>>>>
>>>>>>>>  
>>>>>>>> Then following WG adoption, I re-reraised the issue after
>>>>>>>> discussion with Annabelle draft-secevent-token-00 [3]: 
>>>>>>>>> On this topic, following Yaron’s comments Mike Jones raised
>>>>>>>>> some points that there should be no distinction between
>>>>>>>>> primary events and extensions
>>>>>>>>> (https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=8DBZ5hsA4WNFez3mJr2W9TW0WCYTWMbY1Vs5sgcIauQ&e=>). 
>>>>>>>>> Summarizing:
>>>>>>>>> * Processors will run through all of them regardless. It is
>>>>>>>>> not necessarily helpful to understand which is a primary vs.
>>>>>>>>> extension
>>>>>>>>> * Let’s drop distinction between primary vs. extension. You
>>>>>>>>> can simply express one or more sets of event attributes in a
>>>>>>>>> single JWT
>>>>>>>>>  
>>>>>>>>> My proposal is to drop this terminology in the text and keep
>>>>>>>>> the attribute multi-valued. The purpose of the attribute is to
>>>>>>>>> inform the reader what events are being asserted and what
>>>>>>>>> additional data may be present. It is up to the reader to
>>>>>>>>> ultimately infer meaning when one or more URIs are present. 
>>>>>>>>> Further, when multiple URIs are present it must still to make
>>>>>>>>> a combined statement about a single state change about a
>>>>>>>>> subject. It must not be used to convey multiple distinct (e.g.
>>>>>>>>> transactions) events about a subject.
>>>>>>>>>  
>>>>>>>>> Assuming everyone agrees, I will plan to remove these
>>>>>>>>> distinctions in the next update with some new text. Please
>>>>>>>>> comment if you have concerns.
>>>>>>>>  
>>>>>>>> To which Mike Jones responded [4]
>>>>>>>>> I believe we already had consensus to drop the
>>>>>>>>> primary/secondary distinction, which we intentionally did
>>>>>>>>> before adoption of the working group draft.  I believe any
>>>>>>>>> such distinction will both be unhelpful and result in
>>>>>>>>> syntactic complexity.  Please let’s finish stamping out the
>>>>>>>>> notion that any of the events in a SET are somehow different
>>>>>>>>> than the others.
>>>>>>>>  
>>>>>>>> William Denniss wrote [5]: 
>>>>>>>>> I agree with your proposal.
>>>>>>>>>  
>>>>>>>>> They're all just events. Up to implementors to define &
>>>>>>>>> categorize their events how they like.
>>>>>>>>  
>>>>>>>> Marius also agreed (he may have switched positions now) [6]:
>>>>>>>>> I also think it makes sense to remove the primary/secondary
>>>>>>>>> distinction.
>>>>>>>>>
>>>>>>>>> Marius
>>>>>>>>  
>>>>>>>> Justin also agreed (and may have switched positions) [7]
>>>>>>>>> +1, drop "primary" and keep it an object
>>>>>>>>>  -- Justin
>>>>>>>>>
>>>>>>>>  
>>>>>>>> References: 
>>>>>>>> [1]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00298.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=rG_9NWsC86NC5EDI8paY2lIrUkHUirGG3jfmoHhYAw8&e=>
>>>>>>>> [2]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00299.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=wE8wEkrp-0wxrzKFqozLAsjsD2qgA2mCoDZQp5lwqdA&e=>
>>>>>>>> [3]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00345.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=QEGxsGOAn3D6pmmzeLtQ_gkOSgxpq-8ce2CbXfe2Zk8&e=>
>>>>>>>> [4]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00347.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=IcdLUKGzpKm8QwfE2mo-NufvoiWgjsj__BKRvGGod8c&e=>
>>>>>>>> [5]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00349.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=d0uNsjizWSlLYksDHdqZaYC6Ix0OMDltFs2e4QjTJJE&e=>
>>>>>>>> [6]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00365.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=_FtWiNomXopU9A9_k7A1nsjMQfaXZ_ZjxgBxNrhUBIQ&e=>
>>>>>>>> [7]
>>>>>>>> - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=k5JC5HYCfm0BtQJar8_ZAKRUzgUsJYaCbtiLWOkWxJc&e=>
>>>>>>>>  
>>>>>>>> Phil
>>>>>>>>  
>>>>>>>> Oracle Corporation, Identity Cloud Services Architect
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=zQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk&e=>
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> On Dec 1, 2017, at 8:50 AM, Dick Hardt <[e-mail]
>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>> Is it important to syntactically ensure that only one event is
>>>>>>>>> in a SET?
>>>>>>>>> For privacy reasons, some use cases want to ensure that only
>>>>>>>>> one signal is in a SET.
>>>>>>>>> This adds some additional complexity for use cases that want
>>>>>>>>> to include multiple signals in a SET.
>>>>>>>>>
>>>>>>>>> See https://tools.ietf.org/html/draft-backman-secevent-token-02
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=P-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM&e=> for
>>>>>>>>> an proposed syntax that ensures one event per SET, and enables
>>>>>>>>> multiple events per SET when desired
>>>>>>>>>  
>>>>>>>>> We will track results
>>>>>>>>> here: https://github.com/IETF-SecEvent/Drafts/issues/1
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw&e=>
>>>>>>>>>  
>>>>>>>>> Discussion to be on the mail list as usual, not in the issue
>>>>>>>>> tracker!
>>>>>>>>>  
>>>>>>>>> /Dick
>>>>>>>>> _______________________________________________
>>>>>>>>> Id-event mailing list
>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=YnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4&e=
>>>>>>>>  
>>>>>>>> _______________________________________________
>>>>>>>> Id-event mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>>>>>>>  
>>>>>>> _______________________________________________
>>>>>>> Id-event mailing list
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>>>>>>  
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Id-event mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>>>>>>
>>>>>  
>>>>> _______________________________________________
>>>>> Id-event mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=
>>>>  
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Id-event mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=
>>  
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event