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

The related syntax is needlessly complex and if this mysterious ambiguity exists, the alt draft does nothing to address it. 

The example Annabelle gave isn't even a valid example. We are proposing a major format change for a non-existent problem. 

Mike has commented extensively how jwt has similar practice. If the ambiguity problem existed JWT would be a failure. 

How much hard fact do we need Marius?

Phil

> On Dec 15, 2017, at 8:50 AM, Marius Scurtescu <mscurtescu@google.com> wrote:
> 
> Simpler? Yes.
> 
> Working? For some use cases, yes.
> 
> Mike, it would be useful if you actually spelled out the reasons why we should hold on to it. Two minor reasons are above, what are the great ones?
> 
> Also, if you disagree with the reasons presented for the new syntax, it would be constructive to hear why.
> 
> Marius
> 
>> On Fri, Dec 15, 2017 at 8:12 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> The current syntax is demonstrably working and substantially simpler than the proposed alternative.  Those are great reasons to hold onto it.
>> 
>>  
>> 
>> From: Justin Richer [mailto:jricher@mit.edu] 
>> Sent: Friday, December 15, 2017 7:09 AM
>> To: Marius Scurtescu <mscurtescu@google.com>
>> Cc: Richard Backman, Annabelle <richanna@amazon.com>; Phil Hunt <phil.hunt@oracle.com>; Mike Jones <Michael.Jones@microsoft.com>; Benjamin Kaduk <bkaduk@akamai.com>; id-event@ietf.org
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> +1 to Annabelle and Marius. The current syntax is demonstrably broken for the purposes that people are claiming it’s needed for. Why are we hanging on to it?
>> 
>>  
>> 
>> On Dec 14, 2017, at 6:22 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
>> 
>>  
>> 
>> On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>> 
>> You can’t conceive of any combination of event statements that could be ambiguous?
>> 
>>  
>> 
>> Here’s one possible example:
>> 
>> {
>> 
>> // ...other SET claims...
>> 
>>  "events": {
>> 
>>     "account_updated": { },
>> 
>>    "shipping_address_added": { /* ... */ },
>> 
>>     "billing_address_added": { /* ... */ },
>> 
>>     "address_verified": { "is_verified": true }
>> 
>>  }
>> 
>> }
>> 
>>  
>> 
>> Does the “address_verified” event statement apply to the shipping address or the billing address? Or both? How would the transmitter indicate that one is verified but the other isn’t?
>> 
>>  
>> 
>> The current draft’s syntax allows for implementers to fall into traps like this. Leaving this as a problem for profiling specifications to solve means giving up on general interoperability between SET profiles.
>> 
>>  
>> 
>> +1
>> 
>>  
>> 
>> To add to that, we can go back to the original reasons why multiple events are needed. At IIW we looked at this and we came up with:
>> 
>> - extensions
>> 
>> - aliases
>> 
>> - convenience packaging of related events
>> 
>>  
>> 
>> The current format does not provide any means to convey the above. That is ambiguity.
>> 
>>  
>> 
>> Phil, you are well aware of this, you acknowledged this at the IIW meetings. You could argue that the ambiguity is not important in your opinion, but saying that you do not see any ambiguity is very surprising.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> -- 
>> 
>> Annabelle Richard Backman
>> 
>> Amazon – Identity Services
>> 
>>  
>> 
>>  
>> 
>> From: Phil Hunt <phil.hunt@oracle.com>
>> Date: Thursday, December 14, 2017 at 1:14 PM
>> To: "Richard Backman, Annabelle" <richanna@amazon.com>
>> Cc: Mike Jones <Michael.Jones@microsoft.com>, Benjamin Kaduk <bkaduk@akamai.com>, "id-event@ietf.org" <id-event@ietf.org>, Justin Richer <jricher@mit.edu>
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> I don't see any ambiguity. 
>> 
>> Phil
>> 
>> 
>> On Dec 14, 2017, at 12:37 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
>> 
>> RFC 7519 is very clear about the semantics of the claims that it defines. Where do you see a degree of ambiguity similar to what exists for the “events” claim in the current draft?
>> 
>>  
>> 
>> --
>> 
>> Annabelle Richard Backman
>> 
>> Amazon – Identity Services
>> 
>>  
>> 
>>  
>> 
>> From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
>> Date: Thursday, December 14, 2017 at 11:04 AM
>> To: Phil Hunt <phil.hunt@oracle.com>, "Richard Backman, Annabelle" <richanna@amazon.com>
>> Cc: Benjamin Kaduk <bkaduk@akamai.com>, "id-event@ietf.org" <id-event@ietf.org>, Justin Richer <jricher@mit.edu>
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> By your logic, JWT should be even worse of an "interoperability disaster", but that doesn't seem to be the case in practice.
>> 
>> From: Richard Backman, Annabelle
>> 
>> Sent: Thursday, December 14, 10:49 AM
>> 
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>> To: Phil Hunt, Mike Jones
>> 
>> Cc: Benjamin Kaduk, Justin Richer, id-event@ietf.org
>> 
>> 
>> Mike,
>> 
>>  
>> 
>> What do you mean by “application”? A profiling specification? A transmitter using a particular profiling specification? A transmitter/receiver pair using a profiling application? Something else?
>> 
>>  
>> 
>> I’m not sure why you and Phil are bringing up single vs. multi-aspect in your responses – the point I’m making is that while you claim the current draft supports multi-aspect SETs, its syntax implies limitations on that support that have not been acknowledged:
>> 
>> By using a JSON object as a map with event types as keys, it prohibits transmitters from including two instances of the same event type in a single SET. This reduces the scope of the events claim from “aspects of a single logical event” to “singleton aspects of a single logical event.”By placing all event statements in a single layer without hierarchy or any other indicator of relationships, the syntax requires that receivers be able to infer the correct relationships between event statements. Consequently, either event statements have to be entirely independent of one another, define their own mechanism for disambiguation, or transmitters have to take special care to not produce SETs with ambiguous combinations of event statements. 
>> 
>>  
>> 
>> It’s easy to dismiss interpretation of the events claim as up to the profile/receiver/”application”/etc., but if we do not actually think through how profiles might use the claim, and how someone would implement code to interpret the claim, then we’re setting ourselves up for an interoperability disaster.
>> 
>>  
>> 
>> -- 
>> 
>> Annabelle Richard Backman
>> 
>> Amazon – Identity Services
>> 
>>  
>> 
>>  
>> 
>> From: Id-event <id-event-bounces@ietf.org> on behalf of Phil Hunt <phil.hunt@oracle.com>
>> 
>> Date: Thursday, December 14, 2017 at 9:32 AM
>> 
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> 
>> Cc: Benjamin Kaduk <bkaduk@akamai.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, Justin Richer <jricher@mit.edu>, "id-event@ietf.org" <id-event@ietf.org>
>> 
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> +1
>> 
>> Phil
>> 
>> On Dec 14, 2017, at 8:33 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>> I agree with Phil.  If an application uses multi-aspect SETs, it would be unsurprising for them to generate or receive them.  In other applications, single-aspect SETS can be specified, and in fact unexpected multi-aspect SETs received can be rejected if appropriate for the application.  Both are possible – by design.  Both of Annabelle’s proposed statements seem to be intruding into application and profile design.  The core SET spec shouldn’t take a position on them either way (just like the core JWT spec allows any claims to be used by applications).
>> 
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Benjamin Kaduk
>> 
>> Sent: Thursday, December 14, 2017 7:50 AM
>> 
>> To: Phil Hunt <phil.hunt@oracle.com>; Richard Backman, Annabelle <richanna@amazon.com>
>> 
>> Cc: id-event@ietf.org; Justin Richer <jricher@mit.edu>
>> 
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> 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
>> 
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle <richanna@amazon.com> 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 <phil.hunt@oracle.com>
>> 
>> Date: Wednesday, December 13, 2017 at 5:53 PM
>> 
>> To: "Richard Backman, Annabelle" <richanna@amazon.com>
>> 
>> Cc: Justin Richer <jricher@mit.edu>, "id-event@ietf.org" <id-event@ietf.org>
>> 
>> 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
>> 
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> 
>> On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle <richanna@amazon.com> 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" <richanna@amazon.com>
>> 
>> Date: Monday, December 11, 2017 at 10:09 AM
>> 
>> To: Justin Richer <jricher@mit.edu>, "id-event@ietf.org" <id-event@ietf.org>
>> 
>> Subject: Re: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> The current syntax doesn’t even work for the professed use case, without two unstated constraints:
>> 
>> Two instances of a single type of event statement cannot be related to the same logical event. 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 <id-event-bounces@ietf.org> on behalf of Justin Richer <jricher@mit.edu>
>> 
>> Date: Saturday, December 9, 2017 at 6:04 AM
>> 
>> To: "id-event@ietf.org" <id-event@ietf.org>
>> 
>> 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:richanna@amazon.com] 
>> 
>> Sent: Tuesday, December 5, 2017 2:06 PM
>> 
>> To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt <phil.hunt@oracle.com>
>> 
>> Cc: William Denniss <wdenniss@google.com>; M.Lizar@OCG <m.lizar@openconsentgroup.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Dick Hardt <dick.hardt@gmail.com>; SecEvent <id-event@ietf.org>
>> 
>> 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 <Michael.Jones@microsoft.com>
>> 
>> Date: Tuesday, December 5, 2017 at 1:30 PM
>> 
>> To: Phil Hunt <phil.hunt@oracle.com>, "Richard Backman, Annabelle" <richanna@amazon.com>
>> 
>> Cc: William Denniss <wdenniss@google.com>, "M.Lizar@OCG" <m.lizar@openconsentgroup.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Dick Hardt <dick.hardt@gmail.com>, SecEvent <id-event@ietf.org>
>> 
>> 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:phil.hunt@oracle.com] 
>> 
>> Sent: Tuesday, December 5, 2017 1:22 PM
>> 
>> To: Richard Backman, Annabelle <richanna@amazon.com>
>> 
>> Cc: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com>; M.Lizar@OCG <m.lizar@openconsentgroup.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Dick Hardt <dick.hardt@gmail.com>; SecEvent <id-event@ietf.org>
>> 
>> 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
>> 
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <richanna@amazon.com> 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 <Michael.Jones@microsoft.com>
>> 
>> Date: Tuesday, December 5, 2017 at 12:22 PM
>> 
>> To: "Richard Backman, Annabelle" <richanna@amazon.com>, William Denniss <wdenniss@google.com>, "M.Lizar@OCG" <m.lizar@openconsentgroup.com>
>> 
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, SecEvent <id-event@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
>> 
>> Subject: RE: [Id-event] Consensus :: Single Event Syntax
>> 
>>  
>> 
>> Morteza already pointed out a simple solution to enabling SETs to contain only a single event description for profiles that want that – a solution proposed by Yaron 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:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
>> 
>> Sent: Tuesday, December 5, 2017 11:40 AM
>> 
>> To: William Denniss <wdenniss@google.com>; M.Lizar@OCG <m.lizar@openconsentgroup.com>
>> 
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Phil Hunt <phil.hunt@oracle.com>; SecEvent <id-event@ietf.org>; Dick Hardt <dick.hardt@gmail.com>
>> 
>> 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 <id-event-bounces@ietf.org> on behalf of William Denniss <wdenniss@google.com>
>> 
>> Date: Monday, December 4, 2017 at 7:20 PM
>> 
>> To: "M.Lizar@OCG" <m.lizar@openconsentgroup.com>
>> 
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Dick Hardt <dick.hardt@gmail.com>, SecEvent <id-event@ietf.org>, Phil Hunt <phil.hunt@oracle.com>
>> 
>> 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 <m.lizar@openconsentgroup.com> 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 <m.lizar@openconsentgroup.com> 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 <phil.hunt@oracle.com> 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).  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
>> 
>> [2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html
>> 
>> [3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html
>> 
>> [4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html
>> 
>> [5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html
>> 
>> [6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html
>> 
>> [7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html
>> 
>>  
>> 
>> Phil
>> 
>>  
>> 
>> Oracle Corporation, Identity Cloud Services Architect
>> 
>> @independentid
>> 
>> www.independentid.com
>> 
>> phil.hunt@oracle.com
>> 
>>  
>> 
>> On Dec 1, 2017, at 8:50 AM, Dick Hardt <dick.hardt@gmail.com> 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 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
>> 
>>  
>> 
>> Discussion to be on the mail list as usual, not in the issue tracker!
>> 
>>  
>> 
>> /Dick
>> 
>> _______________________________________________
>> 
>> Id-event mailing list
>> 
>> Id-event@ietf.org
>> 
>> 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
>> 
>> Id-event@ietf.org
>> 
>> https://www.ietf.org/mailman/listinfo/id-event
>> 
>>  
>> 
>> _______________________________________________
>> 
>> Id-event mailing list
>> 
>> Id-event@ietf.org
>> 
>> https://www.ietf.org/mailman/listinfo/id-event
>> 
>>  
>> 
>> _______________________________________________
>> 
>> Id-event mailing list
>> 
>> Id-event@ietf.org
>> 
>> https://www.ietf.org/mailman/listinfo/id-event
>> 
>>  
>> 
>> _______________________________________________
>> 
>> Id-event mailing list
>> 
>> Id-event@ietf.org
>> 
>> 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 Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 
>> Id-event mailing list
>> 
>> Id-event@ietf.org
>> 
>> 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 Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event
>> 
>>  
>> 
>>  
>> 
>> 
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
>> 
>>  
>> 
> 
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=