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

From: Dick Hardt <[email-masked]>
Date: Fri, 1 Dec 2017 08:50:03 -0800

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

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Dec 2017 10:35:31 -0800

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://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 <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 <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 <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 <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 <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 <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 <https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Dec 1, 2017, at 8:50 AM, Dick Hardt <[email-masked]> wrote:
> 
> 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=>
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> 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=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 1 Dec 2017 21:50:32 +0000

The “primary vs. extension” issue that was previously discussed turns out to be just an example of a broader issue with the current draft: it is completely ambiguous how the various payloads in the “events” claim relate to one another. In the WG session at Singapore, we heard multiple use cases for sending a collection of events in a single SET:

  *   Extensions to a core event
  *   Multiple events representing different aspects of a single real-world event
  *   Batch transmission of unrelated events
  *   Transactional processing of events

Those are the ones I recall off the top of my head, there may have been others. This creates the same SET interpretation problem for the recipient as with “primary vs. extension” but multiplied out by N different use cases. If these use cases are in scope for SET, then the format needs to support them in an unambiguous fashion. If they are not in scope for SET, then we need to consider the ramifications of moving forward with a format that inspires usage that is contrary to the intent of the spec.

Despite being the author, I admit I’m not a big fan of the “Related Events” event in the new draft; it’s just the least bad solution I was able to come up with. During one of the side meetings in Singapore, Justin suggested having a different JWT profile for a “SET Collection”, i.e. a JWT that contains a set of SETs. I thought this was an interesting idea, and I’m curious to hear from those with multi-event SET use cases if a SET Collection would meet your needs.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Friday, December 1, 2017 at 10:36 AM
To: SecEvent <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

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

Marius

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<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Dec 1, 2017, at 8:50 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> 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=>

/Dick
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Dec 2017 16:27:39 -0800

None of what you describe should be in SET unless the intent is to make set a command system. 

A set is somewhat ambiguous in that it is a set of statements by an issuer that a receiver may choose to interpret any way it wants. A SET is only a signal and we must steer away from prescribing how it must be interpreted or used. 

Force one interpretation (implying one action) you are setting off on a different charter objective. 

During the meeting in Argentina we discussed clearly the definition of events as compared to other interpretations in IETF and elsewhere (eg stix). Events neither describe analytical history(such as in virus analysis) and the data behind a decision, nor do they describe what a receiver must do. 

The intend is simple neutral signals that allow transmitters to co-ordinate but remain fiercely independent in how they make security policy and decisions.

If we go to single events then we force complexity:
* as shown in your draft with the related event and extension structures (which people will use inconsistently)
* in delivery as multi-part set signaling would be required if multiple sets are needed to describe a single logical event. 

Phil

> On Dec 1, 2017, at 1:50 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Extensions to a core event
> Multiple events representing different aspects of a single real-world event
> Batch transmission of unrelated events
> Transactional processing of events
> 
> www.independentid.com
> [email-masked]
> 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
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 2 Dec 2017 02:15:38 +0000

[richanna]Replies inline.[/richanna]

From: Phil Hunt <[email-masked]>
Date: Friday, December 1, 2017 at 4:27 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: SecEvent <[email-masked]>, Yaron Sheffer <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

None of what you describe should be in SET unless the intent is to make set a command system.
[richanna]
In that case, we can drop the Related Events event from the new draft entirely, as it only exists to support the grouping together of related events in one SET, which I’ve understood to be a requirement that you had. Is that no longer the case? Or did you mean that some of the use cases I listed should not be in SET? Either way, that’s probably the first thing we need to settle on the list, because everything I listed came from use cases cited in Singapore.
[/richanna]

Force one interpretation (implying one action) you are setting off on a different charter objective.
[richanna]
You’re conflating how the recipient interprets the SET with how they react to it. Person A can tell Person B, “The Seahawks beat the 49ers,” and Person B will understand them because they have a shared understanding of words and syntax. But Person B can cheer or boo or cry or whatever they want in response; Person A doesn’t have any control over that. Similarly, if a transmitter sends a multi-part SET to a recipient, the recipient needs to be able to tell whether or not that multi-part SET contains a collection of different aspects of the same real-world event, a collection of unrelated events sent as a batch for efficiency, or something else entirely. What they do from there is up to them, but they can’t make a decision on how to react if they don’t understand what they’re reacting to. The required shared understanding between Transmitter and Receiver is not there with the current draft, given the way people were talking about using it in Singapore. Tony said he wants to use it for batching and maybe for transactions. You want to use it for different aspects. Others will likely come up with further uses.

If your issue is with things like batching or transactions, note that those are not a part of the new draft. I only mention them because members of the working group (e.g. Tony) have mentioned them as use cases they have for multi-part SETs. Tony went as far as to say that he wants the current draft changed, because it doesn’t fully meet these use cases of his. Maybe we should have a separate call for consensus on which use cases for multi-part SETs are in scope for SET and which are not?
[/richanna]

If we go to single events then we force complexity:
* as shown in your draft with the related event and extension structures (which people will use inconsistently)
[richanna]
How is the new draft more open to inconsistent usage than the current one? Where do you see opportunity for inconsistency?
[/richanna]

Phil

On Dec 1, 2017, at 1:50 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
The “primary vs. extension” issue that was previously discussed turns out to be just an example of a broader issue with the current draft: it is completely ambiguous how the various payloads in the “events” claim relate to one another. In the WG session at Singapore, we heard multiple use cases for sending a collection of events in a single SET:

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 1, 2017 at 10:36 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=IyJfdUv6ZzN5kx0vSU2x158KcrdHUBRbAJ1v52n2XVA&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

Marius

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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=6eWVJkMX-uNhuQsPhWOdVKwWB6s1J1kpA1pYtpHF6Xg&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=-tjpzYrH09jJibsfbHYfe3dVrcDXgmmU7RB5yMZxUqA&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=T3JH8BGNzQRndtNTiBd9V55LKCFVadFuTf4FOVT0xg0&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=4dTHb3MCx6rH5uEJ6LKiSgYj6Ey2YKawTsEVb0EaOyU&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=ThXuhUDu9xzoNUabiKpSGaooQdHKhLx2qoKnPdOTuF4&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=Aqva_1ot1XDu1CtpnwoywEP4-Nln0CozB10yJCA7QV0&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=0aFCLiDBOyXsjetqEq15gZoyHdi7Pz68yzh0eztzHpc&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=amvgd3guNiMruRIWNpWit5nh7el_bbWi-Bk0UhYnz_s&s=tk6bvTQ4qHJGfBzQXc82RfWxOjgEF4T27ajA9PeLfDw&e=>
[email-masked]<mailto:[email-masked]>

/Dick

---

From: Mike Jones <[email-masked]>
Date: Sat, 2 Dec 2017 03:12:45 +0000

I am strongly opposed to making a change to reintroduce a distinction between primary and secondary events.  This topic has been heavily discussed in the working group and people very clearly came down on the side of having no such distinction.  Annabelle’s draft needlessly reintroduces this distinction, with the result being a breaking change and making the structure more complicated, not less.  See the deeply nested “related events” structure in https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3 to understand some of the of the additional complexity being proposed.

The working draft already meets the needs of multiple use cases and is in production use.  There are not sufficient reasons to reintroduce complexity that was previously soundly rejected and to make wholesale design changes after working group last call.

We should stay with what already works and complete the SET spec in a timely fashion.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, December 1, 2017 10:36 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Marius

References:

Phil

/Dick

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 4 Dec 2017 07:40:30 +0000

I have gone through the minutes Dick posted from the main and side meetings and I went back through the mailing list threads on the topic (thanks Phil for the pointers). To be honest I am still at a loss as to why this is such a contentious issue. I feel the current SET spec addresses all the use cases we have identified so far and the complexity of handing events vs. event is very minimal.

Furthermore with some minor additions along what Yaron suggested in https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html or something similar we should be able to handle the case where some profile wants to define additional restriction on the SET.

Given the data and discussion so far, I am with Mike & Phil in the support of SET as defined in the WG document.

Cheers,
Morteza

From: Id-event <[email-masked]> on behalf of Mike Jones <[email-masked]>
Date: Friday, December 1, 2017 at 7:17 PM
To: Phil Hunt <[email-masked]>, SecEvent <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

                                                                -- Mike

Marius

References:

Phil

/Dick

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Dec 2017 10:56:23 -0300

I think Tony’s desire to use SET as a directory synchronization protocol and RISC’s desire to keep events separate are quite different.   

I think that the proposed idea of letting profiles set the maximum number of events may be a way to thread the needle.

It would not be horrible for the two things to share a common structure, if the profile for RISC can limit the events to one.  
I would probably want / need to also limit the events to one in Connect SLO to prevent confusion. Around the subject.

This is taking more time than it is worth, in some respects.

Can we stick to what we have and allow profiles to set the max number.

I agree that I might be more tempted to start with Annabelle’s if starting from scratch, but I would prefer not to do that.

John B.

> On Dec 4, 2017, at 4:40 AM, Morteza Ansari (moransar) <[email-masked]> wrote:
> 
> Furthermore with some minor additions along what Yaron suggested in https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html <https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html> or something similar we should be able to handle the case where some profile wants to define additional restriction on the SET.
>  
> I am strongly opposed to making a change to reintroduce a distinction between primary and secondary events.  This topic has been heavily discussed in the working group and people very clearly came down on the side of having no such distinction.  Annabelle’s draft needlessly reintroduces this distinction, with the result being a breaking change and making the structure more complicated, not less.  See the deeply nested “related events” structure in https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3 <https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3> to understand some of the of the additional complexity being proposed.
>  
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt
> To: SecEvent <[email-masked] <mailto:[email-masked]>>
> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> On Dec 1, 2017, at 8:50 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> [email-masked] <mailto:[email-masked]>
>> 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 <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>=
> 
>  
> https://www.ietf.org/mailman/listinfo/id-event

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Dec 2017 10:57:27 -0300

PS The extension thing is ugly and would not be the way I would want to go.  

> On Dec 4, 2017, at 10:56 AM, John Bradley <[email-masked]> wrote:
> 
>> On Dec 4, 2017, at 4:40 AM, Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Mike Jones <[email-masked] <mailto:[email-masked]>>
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>
>> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 04 Dec 2017 14:21:45 +0000

I feel the same way. I was a bit puzzled at the current situation. As my
earlier review comments said, I think the WG document is good to go once a
few nits that I and others pointed out are fixed.

Best,

Nat

On Mon, Dec 4, 2017 at 4:40 PM Morteza Ansari (moransar) <[email-masked]>
wrote:

> I have gone through the minutes Dick posted from the main and side
> meetings and I went back through the mailing list threads on the topic
> (thanks Phil for the pointers). To be honest I am still at a loss as to why
> this is such a contentious issue. I feel the current SET spec addresses all
> the use cases we have identified so far and the complexity of handing
> events vs. event is very minimal.
>
>
>
> Furthermore with some minor additions along what Yaron suggested in
> https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html or
> something similar we should be able to handle the case where some profile
> wants to define additional restriction on the SET.
>
>
>
> *From: *Id-event <[email-masked]> on behalf of Mike Jones <
> [email-masked]>
> *Date: *Friday, December 1, 2017 at 7:17 PM
> *To: *Phil Hunt <[email-masked]>, SecEvent <[email-masked]>
>
>
> *Cc: *Yaron Sheffer <[email-masked]>, Dick Hardt <
> [email-masked]>
> *Subject: *Re: [Id-event] Consensus :: Single Event Syntax
>
>
>
> I am strongly opposed to making a change to reintroduce a distinction
> between primary and secondary events.  This topic has been heavily
> discussed in the working group and people very clearly came down on the
> side of having no such distinction.  Annabelle’s draft needlessly
> reintroduces this distinction, with the result being a breaking change and
> making the structure more complicated, not less.  See the deeply nested
> “related events” structure in
> https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3 to
> understand some of the of the additional complexity being proposed.
>
>
>
> The working draft already meets the needs of multiple use cases and is in
> production use.  There are not sufficient reasons to reintroduce complexity
> that was previously soundly rejected and to make wholesale design changes
> after working group last call.
>
>
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Phil Hunt
> *Sent:* Friday, December 1, 2017 10:36 AM
> *To:* SecEvent <[email-masked]>
> *Cc:* Yaron Sheffer <[email-masked]>; Dick Hardt <
> [email-masked]>
>
>
> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>
>
>
> 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.
>
>
>
> *[Phil] *Yup.   How would the group like to fix this?  We could make
> “events”
> *[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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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=>
>
>
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: "M.Lizar@OCG" <[email-masked]>
Date: Mon, 4 Dec 2017 20:46:10 +0000

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

---

From: "M.Lizar@OCG" <[email-masked]>
Date: Mon, 4 Dec 2017 21:08:25 +0000

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 <[email-masked]> wrote:
> 
> 
>> On 1 Dec 2017, at 18:35, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: William Denniss <[email-masked]>
Date: Mon, 4 Dec 2017 19:18:57 -0800

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

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 4 Dec 2017 19:01:58 +0000

FWIW, I said drop primary because it was only ever supposed to be one event, so primary vs. secondary makes zero sense to me. I’ve switched positions on the syntax because of how it is (to my view) being misused to represent multiple potentially unrelated things in a single SET.

 — Justin

> On Dec 1, 2017, at 6:35 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 4 Dec 2017 19:03:47 +0000

I strongly disagree that the new draft reintroduces primary/secondary semantics. It instead creates a single object, the only event that the SET is concerned with. The “related events” grouping isn’t creating secondary events, it’s creating a bag for multiple “single” events to be carried together. There’s no primacy involved.

This is highly desirable vs. the current usage. 

 — Justin

> On Dec 2, 2017, at 3:12 AM, Mike Jones <[email-masked]> wrote:
> 
> I am strongly opposed to making a change to reintroduce a distinction between primary and secondary events.  This topic has been heavily discussed in the working group and people very clearly came down on the side of having no such distinction.  Annabelle’s draft needlessly reintroduces this distinction, with the result being a breaking change and making the structure more complicated, not less.  See the deeply nested “related events” structure inhttps://tools.ietf.org/html/draft-backman-secevent-token-03#section-3 <https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3> to understand some of the of the additional complexity being proposed.
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 5 Dec 2017 19:39:35 +0000

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?

From: Id-event <[email-masked]> on behalf of William Denniss <[email-masked]>
Date: Monday, December 4, 2017 at 7:20 PM
To: "M.Lizar@OCG" <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Dick Hardt <[email-masked]>, SecEvent <[email-masked]>, Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

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 <[email-masked]<mailto:[email-masked]>> wrote:
Small typo,  -  should be a  ‘.’ Not a ‘?’

- Mark

On 4 Dec 2017, at 20:46, M.Lizar@OCG <[email-masked]<mailto:[email-masked]>> wrote:

On 1 Dec 2017, at 18:35, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Marius

 -- Justin

References:

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

/Dick

---

From: Mike Jones <[email-masked]>
Date: Tue, 5 Dec 2017 20:21:30 +0000

Morteza already pointed out<https://mailarchive.ietf.org/arch/msg/id-event/KPaK5aN3EeIybWJmQOJiqdHXQzg> a simple solution to enabling SETs to contain only a single event description for profiles that want that – a solution proposed by Yaron<https://www.ietf.org/mail-archive/web/id-event/current/msg00736.html> 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:[email-masked]] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, December 5, 2017 11:40 AM
To: William Denniss <[email-masked]>; M.Lizar@OCG <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Phil Hunt <[email-masked]>; SecEvent <[email-masked]>; Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of William Denniss <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 4, 2017 at 7:20 PM
To: "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>> wrote:
Small typo,  -  should be a  ‘.’ Not a ‘?’

- Mark

On 4 Dec 2017, at 20:46, M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>> wrote:

Marius

 -- Justin

References:

Phil

/Dick

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 5 Dec 2017 20:57:39 +0000

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.

From: Mike Jones <[email-masked]>
Date: Tuesday, December 5, 2017 at 12:22 PM
To: "Richard Backman, Annabelle" <[email-masked]>, William Denniss <[email-masked]>, "M.Lizar@OCG" <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Phil Hunt <[email-masked]>, SecEvent <[email-masked]>, Dick Hardt <[email-masked]>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

                                                                -- Mike

- Mark

Marius

 -- Justin

References:

Phil

/Dick

---

From: Phil Hunt <[email-masked]>
Date: Tue, 5 Dec 2017 13:21:51 -0800

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

> On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Mike,
>  
> From: Mike Jones <[email-masked] <mailto:[email-masked]>>
> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, William Denniss <[email-masked] <mailto:[email-masked]>>, "M.Lizar@OCG" <[email-masked] <mailto:[email-masked]>>
> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Phil Hunt <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>, Dick Hardt <[email-masked] <mailto:[email-masked]>>
> 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:[email-masked] <mailto:[email-masked]>] On Behalf Of Richard Backman, Annabelle
> To: William Denniss <[email-masked] <mailto:[email-masked]>>; M.Lizar@OCG <[email-masked] <mailto:[email-masked]>>
> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Phil Hunt <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>
> 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.
>  
> 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…
>  
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of William Denniss <[email-masked] <mailto:[email-masked]>>
> To: "M.Lizar@OCG <mailto:M.Lizar@OCG>" <[email-masked] <mailto:[email-masked]>>
> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Dick Hardt <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>, Phil Hunt <[email-masked] <mailto:[email-masked]>>
> On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG <mailto:M.Lizar@OCG> <[email-masked] <mailto:[email-masked]>> wrote:
>>> On 4 Dec 2017, at 20:46, M.Lizar@OCG <mailto:M.Lizar@OCG> <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>>  
>>>>> 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:
>>>> [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
>>>>  
>>>> 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=>
>>>> 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=>
>>>  
>>> 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=>
>>  
>> 
>> 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=>
>  
> 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= <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=>

---

From: Mike Jones <[email-masked]>
Date: Tue, 5 Dec 2017 21:30:08 +0000

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:[email-masked]]
Sent: Tuesday, December 5, 2017 1:22 PM
To: Richard Backman, Annabelle <[email-masked]>
Cc: Mike Jones <[email-masked]>; William Denniss <[email-masked]>; M.Lizar@OCG <[email-masked]>; Yaron Sheffer <[email-masked]>; Dick Hardt <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

Mike,

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 5, 2017 at 12:22 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, William Denniss <[email-masked]<mailto:[email-masked]>>, "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>
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:[email-masked]] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, December 5, 2017 11:40 AM
To: William Denniss <[email-masked]<mailto:[email-masked]>>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

- Mark

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

Marius

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

/Dick

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 5 Dec 2017 22:06:29 +0000

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

From: Mike Jones <[email-masked]>
Date: Tuesday, December 5, 2017 at 1:30 PM
To: Phil Hunt <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>
Cc: William Denniss <[email-masked]>, "M.Lizar@OCG" <[email-masked]>, Yaron Sheffer <[email-masked]>, Dick Hardt <[email-masked]>, SecEvent <[email-masked]>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: Mike Jones <[email-masked]>
Date: Tue, 5 Dec 2017 22:50:33 +0000

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:[email-masked]]
Sent: Tuesday, December 5, 2017 2:06 PM
To: Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>
Cc: William Denniss <[email-masked]>; M.Lizar@OCG <[email-masked]>; Yaron Sheffer <[email-masked]>; Dick Hardt <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 5, 2017 at 1:30 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: William Denniss <[email-masked]<mailto:[email-masked]>>, "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

Hi Annabelle,

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, December 5, 2017 1:22 PM
To: Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; William Denniss <[email-masked]<mailto:[email-masked]>>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 6 Dec 2017 18:50:35 +0000

Mike,

Multiple members of the working group have expressed desire or intent to use SETs in a way that is contrary to that text. Clearly it is insufficient. But event setting those use cases aside, the current language doesn’t address the fundamental problem that there is no way for a recipient to decompose the “events” claim into independent meaningful components. Given event payloads A, B, and C that all relate to the same logical event, a recipient cannot know whether A extends B, or B extends C, etc. This leaves the recipient with no choice but to expose the entire SET to any system that processes any event type in the SET, creating opportunities for identifier correlation and information leakage.

We’ve already seen examples of this in Phil’s desire to combine SCIM and RISC events, and an earlier suggestion within RISC to put an event containing a subject’s phone number and an event containing their email address in the same SET. And this is not just a problem for RISC: correlation across event payloads could easily result in the de-anonymization of health or finance-related information, for instance, if consent receipts or audit events get bundled with events containing PII. We are asking profiling specifications and transmitters to impose the necessary limits to make the Security Event Token format secure, and we’re providing very little in the way of tools or guidance to help them do that.

From: Mike Jones <[email-masked]>
Date: Tuesday, December 5, 2017 at 2:51 PM
To: "Richard Backman, Annabelle" <[email-masked]>, Phil Hunt <[email-masked]>
Cc: William Denniss <[email-masked]>, "M.Lizar@OCG" <[email-masked]>, Yaron Sheffer <[email-masked]>, Dick Hardt <[email-masked]>, SecEvent <[email-masked]>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: Phil Hunt <[email-masked]>
Date: Wed, 6 Dec 2017 11:12:47 -0800

This is a circular argument 

We have to disagree. 

Bottom line just because i suspect many want to combine payloads for many reasons, none of that obliges you as a receiver to process them as that is a per stream decision. 

Phil

> On Dec 6, 2017, at 10:50 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Mike,
>  
> 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
>  
> On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=XbVrkigNePpcCMeYdXRaVBc5ASACP34mz3GJf9bPEIo&s=3u3xK9gyLZlZ95BPRf469L1Bt_LTdnreprit0RLousg&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 6 Dec 2017 20:20:14 +0000

The recipient doesn’t have an option; they cannot decompose the SET “events” claim without intimate knowledge of the profiles, event types, and extensions involved, so any system interested in any event type in that SET has to be given the entire SET.

From: Phil Hunt <[email-masked]>
Date: Wednesday, December 6, 2017 at 11:13 AM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Mike Jones <[email-masked]>, William Denniss <[email-masked]>, Yaron Sheffer <[email-masked]>, "M.Lizar@OCG" <[email-masked]>, SecEvent <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

We have to disagree.

Phil

On Dec 6, 2017, at 10:50 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 5, 2017 at 2:51 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: William Denniss <[email-masked]<mailto:[email-masked]>>, "M.Lizar@OCG" <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

                                                                -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Tuesday, December 5, 2017 2:06 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: William Denniss <[email-masked]<mailto:[email-masked]>>; M.Lizar@OCG <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Hi Annabelle,

                                                                -- Mike

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=XbVrkigNePpcCMeYdXRaVBc5ASACP34mz3GJf9bPEIo&s=VtbiIcDXsrD4jTx6qZIejkPUIf_ilYVeefsLOkKcdj4&e=>
[email-masked]<mailto:[email-masked]>

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: Phil Hunt <[email-masked]>
Date: Wed, 6 Dec 2017 12:29:59 -0800

Sure it does. That is what the control panel is for.  :-)

Failing that as mike said, as with jwt it is free to ignore what it does not care about. 

Phil

> On Dec 6, 2017, at 12:20 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ptx84x_IFqqro0n_RJRxlKw8xTq1tKLx2ZJYbyvSKMY&s=zhcT3nbqcqAiC2AiE_2mxx42SDmlrmhZTdNI6_XUwjg&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 6 Dec 2017 20:54:51 +0000

Neither control plane proposal provides a mechanism for specifying whether or not events may be grouped, or if they may be grouped. They could, but that’s adding complexity to the control plane.

And GDPR, HIPAA, COPPA, BIPA, etc. mean that the recipient is not free to ignore what they do not care about. Simply receiving information can invoke additional regulations.

From: Phil Hunt <[email-masked]>
Date: Wednesday, December 6, 2017 at 12:30 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, William Denniss <[email-masked]>, "M.Lizar@OCG" <[email-masked]>, SecEvent <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

On Dec 6, 2017, at 12:20 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
The recipient doesn’t have an option; they cannot decompose the SET “events” claim without intimate knowledge of the profiles, event types, and extensions involved, so any system interested in any event type in that SET has to be given the entire SET.

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 6, 2017 at 11:13 AM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, William Denniss <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, "M.Lizar@OCG" <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

We have to disagree.

Phil

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: Phil Hunt <[email-masked]>
Date: Wed, 6 Dec 2017 13:16:16 -0800

We have been discussing specifically that receivers should be able to specify what events may be delivered in a stream.  Both proposals support this. 

What you might be wanting is specification of composites (including not requesting them) that may be delivered. I support more granular config on this point - it isn't that hard. 

I think it is important to point out that a txer that sends data that is not wanted may be causing privacy issues. That is assumed at least by me. 

Phil

> On Dec 6, 2017, at 12:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=YcYrSVviQnjYz1nW9T9e3De2n6jtt5dH5Rtz6kIfVpg&s=dUnNjyGoJ9oC9aZsc_nAxd87Q38EVYZz_S09IJ6PBjU&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 7 Dec 2017 01:54:39 +0000

We have been discussing recipients saying “Send me X and Y but not Z.” What we’re talking about here is more like “Send me X and Y, but not Z. And don’t send X and Y together.” I think RISC would be fine with a blanket “Don’t bundle SETs on the stream” flag, provided that the transmitter is obligated to honor it, but I’m not sure if such an all-or-nothing model would work for others. This is what I mean by adding complexity.

Even if the working group consensus is to stick with the current draft, this issue doesn’t go away. We’re going to end up paying for it somewhere.

Date: Wednesday, December 6, 2017 at 1:16 PM

Phil

On Dec 6, 2017, at 12:54 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Neither control plane proposal provides a mechanism for specifying whether or not events may be grouped, or if they may be grouped. They could, but that’s adding complexity to the control plane.

Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Mike Jones <[email-masked]<mailto:[email-masked]>>, William Denniss <[email-masked]<mailto:[email-masked]>>, "M.Lizar@OCG" <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>

Phil

We have to disagree.

Phil

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 7 Dec 2017 08:25:56 +0000

If the client understands how to handle X & Y (given it subscribed to X & Y) AND the spec clearly says events claim SHOULD NOT be used to express multiple logical events, then why wouldn’t it be able to handle if X & Y are sent together for a related logical event?

I don’t see how this could be ambiguous to the client.

Cheers,
Morteza

From: Id-event <[email-masked]> on behalf of "Richard Backman, Annabelle" <[email-masked]>
Date: Wednesday, December 6, 2017 at 6:12 PM
To: Phil Hunt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, William Denniss <[email-masked]>, "M.Lizar@OCG" <[email-masked]>, SecEvent <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

Phil

We have to disagree.

Phil

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 7 Dec 2017 17:47:49 +0000

Morteza,

Providing the recipient with X & Y together may allow the recipient to correlate information that they could not correlate before, or that they do not want to be correlatable by all the systems that process the SET. As an example from RISC, suppose a customer registers two Amazon accounts, one with their Gmail email address and one with their Google Voice phone number. Suppose also that Amazon asks Google to transmit RISC events for that email address, and that phone number (note that these would be separate enrollment calls). Now suppose the customer adds their Google Voice phone number as a second factor to their Google account. Since Google knows that both the email address and phone number belong to the same subject, they could decide to send us a single SET containing both a second-factor-added event referencing the email address, and an added-as-second-factor event referencing the phone number. However, if they did so it would reveal to us that the email address and phone number belong to the same account, which is information that we did not have and do not want to have unless the customer tells us. It’s not hard to imagine similar scenarios involving anonymized data in event X and identifiers in event Y, such that receiving them together de-anonymizes the content of event X.

Additionally, suppose a recipient expects to receive both X and Y on the same event stream, but routes each event type to separate internal systems (e.g. X-Processor and Y-Processor) for processing. What happens when X and Y are send in a single SET? The router could send the SET to both processors, but that causes each to be exposed to more information than necessary, potentially increasing attack surfaces and the scope of systems that fall under regulation. The alternative is for the router to extract the content for X and send it to X-Processor and likewise for Y and Y-Processor, but in doing so it renders each processor incapable of validating that the event is a legitimate event sent from the transmitter, since they would need the entire SET in order to validate the signature from the transmitter. The processors would have to trust anything they get from the router. Furthermore, in order to decompose the SET into “X content” and “Y content” the router must have some knowledge about the definitions for X and Y (which JWT claims if any are relevant to each event type, for example). It also needs to know whether they actually can be separated at all – Y could be acting as an extension of X, after all. This problem becomes clearer if we have a SET containing X, Y, and Z. Which processor, if any, should receive Z?

It’s easy to dismiss these as hypotheticals, but we need to consider how people are going to implement the spec.

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thursday, December 7, 2017 at 12:26 AM
To: "Richard Backman, Annabelle" <[email-masked]>, Phil Hunt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, William Denniss <[email-masked]>, "M.Lizar@OCG" <[email-masked]>, SecEvent <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Cheers,
Morteza

Phil

Phil

We have to disagree.

Phil

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

---

From: John Wunderlich <[email-masked]>
Date: Thu, 7 Dec 2017 17:59:05 +0000

At this scale, almost all hypotheticals are likely to occur more than 0 times. At that point it becomes risk management. In terms of reputation risk, even a single embarrassing breach can bring the entire system (or company) into disrepute - out of proporation to measurable fiscal or operational risk metric.

In the context of increasing privacy regulation and scrutiny, the incidental or accidental revelation of linkable information is a significant increase in operational risk at scale. Or so it seems to me based on this description.

John Wunderlich,

Sent frum a mobile device,
Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin
_____________________________
From: Richard Backman, Annabelle <[email-masked]>
Sent: Thursday, December 7, 2017 12:48 PM
Subject: Re: [Id-event] Consensus :: Single Event Syntax
To: Morteza Ansari (moransar) <[email-masked]>, Phil Hunt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, William Denniss <[email-masked]>, M.Lizar@OCG <[email-masked]>, SecEvent <[email-masked]>, Dick Hardt <[email-masked]>

Morteza,

Cheers,
Morteza

Phil

Phil

We have to disagree.

Phil

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; William Denniss <[email-masked]<mailto:[email-masked]>>;M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>

Phil

Mike,

                                                                -- Mike

To: William Denniss <[email-masked]<mailto:[email-masked]>>;M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>>

- Mark

Marius

References:

Phil

/Dick

-- 

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 12:29:37 -0800

+1

Marius

On Mon, Dec 4, 2017 at 11:03 AM, Justin Richer <[email-masked]> wrote:

> I strongly disagree that the new draft reintroduces primary/secondary
> semantics. It instead creates a single object, the only event that the SET
> is concerned with. The “related events” grouping isn’t creating secondary
> events, it’s creating a bag for multiple “single” events to be carried
> together. There’s no primacy involved.
>
> “related events” structure inhttps://tools.ietf.org/html/
> draft-backman-secevent-token-03#section-3 to understand some of the of
> the additional complexity being proposed.
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 16:39:18 -0800

On Fri, Dec 1, 2017 at 7:12 PM, Mike Jones <[email-masked]>
wrote:

> “related events” structure in https://tools.ietf.org/html/

It meets the need of some use cases. It does not meet the use case put
forward by Tony Nadalin for example.

Regarding production use. We are getting implementation feedback and we are
wholesale refusing it because there is some minor production usage already?
We should not be reckless breaking existing usage, I totally agree, but we
cannot argue for a weaker spec simply because there is usage of an early
draft.

Again, I am really surprised by this total refusal to address
implementation feedback. Isn't this supposed to be normal part of the
process?

> We should stay with what already works and complete the SET spec in a

How about: we should all collaborate on creating the best speck we can and
consider all implementation feedback?

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 16:48:01 -0800

comments inline...

> events vs. event is very minimal.

Sure, we can live with "events" (except for Tony, his use case is not met).
Why can't we take implementation feedback and improve the spec?

> wants to define additional restriction on the SET.

That helps writing profiles, still leaves room for ambiguity and privacy
issues when implementing a transmitters. Something like "Profiling
specifications SHOULD define the allowed event statements" cannot be
enforced in a parser, this is just a recommendation (easy to miss by an
implementer).

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 16:49:37 -0800

On Mon, Dec 4, 2017 at 5:56 AM, John Bradley <[email-masked]> wrote:

> I think Tony’s desire to use SET as a directory synchronization protocol
> and RISC’s desire to keep events separate are quite different.
>
> I think that the proposed idea of letting profiles set the maximum number
> of events may be a way to thread the needle.
>
> It would not be horrible for the two things to share a common structure,
> if the profile for RISC can limit the events to one.
> I would probably want / need to also limit the events to one in Connect
> SLO to prevent confusion. Around the subject.
>
> I agree that I might be more tempted to start with Annabelle’s if starting
> from scratch, but I would prefer not to do that.
>

I think we should take the good ideas from Annabelle's draft and improve
the existing one.

> “related events” structure in https://tools.ietf.org/
> html/draft-backman-secevent-token-03#section-3 to understand some of the
> of the additional complexity being proposed.
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 9 Dec 2017 09:00:40 -0500

If you can carry multiple profiled payloads together, which profile gets 
to decide the semantics of the combination?

Answering this question in any reasonable fashion is exactly why I favor 
the new format over the current, and it gets at what I was attempting 
with the current format.

  -- Justin

On 12/5/2017 4:30 PM, Mike Jones wrote:
>
> 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:[email-masked]]
> *Sent:* Tuesday, December 5, 2017 1:22 PM
> *To:* Richard Backman, Annabelle <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; William Denniss 
> <[email-masked]>; M.Lizar@OCG <[email-masked]>; 
> Yaron Sheffer <[email-masked]>; Dick Hardt 
> <[email-masked]>; SecEvent <[email-masked]>
> 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
>
> www.independentid.com <http://www.independentid.com>
>
>     On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle
>     <[email-masked] <mailto:[email-masked]>> 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.
>
>     -- 
>
>     *From:*Mike Jones <[email-masked]
>     <mailto:[email-masked]>>
>     *Date:*Tuesday, December 5, 2017 at 12:22 PM
>     *To:*"Richard Backman, Annabelle" <[email-masked]
>     <mailto:[email-masked]>>, William Denniss
>     <[email-masked] <mailto:[email-masked]>>, "M.Lizar@OCG
>     <mailto:M.Lizar@OCG>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:*Yaron Sheffer <[email-masked]
>     <mailto:[email-masked]>>, Phil Hunt <[email-masked]
>     <mailto:[email-masked]>>, SecEvent <[email-masked]
>     <mailto:[email-masked]>>, Dick Hardt <[email-masked]
>     <mailto:[email-masked]>>
>     *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:[email-masked]]*On Behalf
>     Of*Richard Backman, Annabelle
>     *Sent:*Tuesday, December 5, 2017 11:40 AM
>     *To:*William Denniss <[email-masked]
>     <mailto:[email-masked]>>; M.Lizar@OCG <mailto:M.Lizar@OCG>
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:*Yaron Sheffer <[email-masked]
>     <mailto:[email-masked]>>; Phil Hunt <[email-masked]
>     <mailto:[email-masked]>>; SecEvent <[email-masked]
>     <mailto:[email-masked]>>; Dick Hardt <[email-masked]
>     <mailto:[email-masked]>>
>     *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:
>
>     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:
>
>       * Phil wants to use it to send different aspects of the same
>         event, intended to be processed together.
>     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?
>
>     -- 
>
>     *From:*Id-event <[email-masked]
>     <mailto:[email-masked]>> on behalf of William Denniss
>     <[email-masked] <mailto:[email-masked]>>
>     *Date:*Monday, December 4, 2017 at 7:20 PM
>     *To:*"M.Lizar@OCG <mailto:M.Lizar@OCG>"
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:*Yaron Sheffer <[email-masked]
>     <mailto:[email-masked]>>, Dick Hardt <[email-masked]
>     <mailto:[email-masked]>>, SecEvent <[email-masked]
>     <mailto:[email-masked]>>, Phil Hunt <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:*Re: [Id-event] Consensus :: Single Event Syntax
>
>     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><[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>             On 4 Dec 2017, at 20:46,M.Lizar@OCG
>             <mailto:M.Lizar@OCG><[email-masked]
>             <mailto:[email-masked]>> 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?
>
>                 On 1 Dec 2017, at 18:35, Phil Hunt
>                 <[email-masked] <mailto:[email-masked]>>
>                 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.
>
>                             _[Phil] _Yup.   How would the group like
>                             to fix this? We could make “events”
>                         _[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
>                     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.
>
>                     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.
>
>                     They're all just events. Up to implementors to
>                     define & categorize their events how they like.
>
>                 [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
>
>                 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=zQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk&e=>
>
>                     On Dec 1, 2017, at 8:50 AM, Dick Hardt
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                     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
>                     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__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>
>
>             <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=>
>
>
>         <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=>
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 9 Dec 2017 09:02:36 -0500

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
>
> *From:* Richard Backman, Annabelle [mailto:[email-masked]]
> *Sent:* Tuesday, December 5, 2017 2:06 PM
> *To:* Mike Jones <[email-masked]>; Phil Hunt 
> <[email-masked]>
> *Cc:* William Denniss <[email-masked]>; M.Lizar@OCG 
> <[email-masked]>; Yaron Sheffer <[email-masked]>; 
> Dick Hardt <[email-masked]>; SecEvent <[email-masked]>
> 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.”
>
> -- 
>
> *From: *Mike Jones <[email-masked] 
> *Date: *Tuesday, December 5, 2017 at 1:30 PM
> *To: *Phil Hunt <[email-masked] <mailto:[email-masked]>>, 
> "Richard Backman, Annabelle" <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *William Denniss <[email-masked] 
> <mailto:[email-masked]>>, "M.Lizar@OCG <mailto:M.Lizar@OCG>" 
> <[email-masked] <mailto:[email-masked]>>, 
> Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, 
> Dick Hardt <[email-masked] <mailto:[email-masked]>>, 
> SecEvent <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: [Id-event] Consensus :: Single Event Syntax
>
> Hi Annabelle,
>
> *To:* Richard Backman, Annabelle <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Mike Jones <[email-masked] 
> <mailto:[email-masked]>>; William Denniss 
> <[email-masked] <mailto:[email-masked]>>; M.Lizar@OCG 
> <mailto:M.Lizar@OCG> <[email-masked] 
> <mailto:[email-masked]>>; Yaron Sheffer 
> <[email-masked] <mailto:[email-masked]>>; Dick Hardt 
> <[email-masked] <mailto:[email-masked]>>; SecEvent 
> <[email-masked] <mailto:[email-masked]>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 11 Dec 2017 18:09:59 +0000

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?

From: Id-event <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Saturday, December 9, 2017 at 6:04 AM
To: "[email-masked]" <[email-masked]>
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.

                                                                -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Tuesday, December 5, 2017 2:06 PM
To: Mike Jones <[email-masked]><mailto:[email-masked]>; Phil Hunt <[email-masked]><mailto:[email-masked]>
Cc: William Denniss <[email-masked]><mailto:[email-masked]>; M.Lizar@OCG <[email-masked]><mailto:[email-masked]>; Yaron Sheffer <[email-masked]><mailto:[email-masked]>; Dick Hardt <[email-masked]><mailto:[email-masked]>; SecEvent <[email-masked]><mailto:[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

Id-event mailing list

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 14 Dec 2017 00:03:29 +0000

I agree that we should stay with the current syntax as it already works for multiple use cases

From: Id-event [mailto:[email-masked]] On Behalf Of M.Lizar@OCG
Sent: Monday, December 4, 2017 1:08 PM
To: Phil Hunt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>; Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

- Mark

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fid-event%2F0Hhg46ROcidQDLL7OnXUs88TJ9U&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=qfetJaQInRps4jXPio2RVfzx4AXzppo3BdihCLdRVkk%3D&reserved=0>).  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

Marius

References:
[1] - https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00298.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=BSy0S%2BlqOF8qYHnHnjO%2FKyy1%2BwvkYMlQGneTKIbyB9M%3D&reserved=0>
[2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00299.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=d5z8kt%2BbLuc9O0een578pjzpMZ9umGEgKGa8mOeayus%3D&reserved=0>
[3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00345.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=HPm9cDNEidi8SUjZIovbkxBp7hn5%2B5FZfkH355OlppM%3D&reserved=0>
[4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00347.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=idGa57mCSH0WX8sDZUKOVp%2FmWfJ51n2BcOWkiuDQ4wA%3D&reserved=0>
[5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00349.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=Plq59tXa36giN0eTuFrbRkLRCiahveoL4qs5btWrnq8%3D&reserved=0>
[6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00365.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=79K6T4qnNYkHbx4B3I9SLaDk6O%2FeNxZ0unZsmAhb40M%3D&reserved=0>
[7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fid-event%2Fcurrent%2Fmsg00406.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=MSa6OJZSW1EpCY1HEyzA2aRp7oCId%2FiZjwCWHAPReTc%3D&reserved=0>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.independentid.com%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=hZKQP647u5eZZLpmDBoq3og0%2Fhy%2BoW926QlSBBB6VZo%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DP-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=s7IfpAqVt6z5FoTUycG3z01L0yY8f6jwuYoCT8ampu4%3D&reserved=0> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSecEvent_Drafts_issues_1%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3D3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=qPXSf7vwwMKCFHYk0LhlU5aKdfIW%2BQMxLI3xYFgFyGU%3D&reserved=0>

/Dick
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DYnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=rzMzMvQ%2BHuefu7dLtS5uGTw43A97QWZWibNyo38r%2BLE%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=02%7C01%7Ctonynad%40microsoft.com%7Ca7c02e2819cd40b4711308d53b5b7e4c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636480186511212102&sdata=YXn2twY6s7R%2BFoO1RiCu6RwLs%2BiiacV5AFT94sXNTx0%3D&reserved=0>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 14 Dec 2017 01:46:49 +0000

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?

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Monday, December 11, 2017 at 10:09 AM
To: Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

Id-event mailing list

---

From: Phil Hunt <[email-masked]>
Date: Wed, 13 Dec 2017 17:52:43 -0800

What restrictions are you referring to?

Phil

> On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Phil,
>  
> From: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
> To: Justin Richer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 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.
>  
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Justin Richer <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> From: Richard Backman, Annabelle [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Mike Jones <[email-masked]> <mailto:[email-masked]>; Phil Hunt <[email-masked]> <mailto:[email-masked]>
>> Cc: William Denniss <[email-masked]> <mailto:[email-masked]>; M.Lizar@OCG <[email-masked]> <mailto:[email-masked]>; Yaron Sheffer <[email-masked]> <mailto:[email-masked]>; Dick Hardt <[email-masked]> <mailto:[email-masked]>; SecEvent <[email-masked]> <mailto:[email-masked]>
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>> Cc: William Denniss <[email-masked] <mailto:[email-masked]>>, "M.Lizar@OCG <mailto:M.Lizar@OCG>" <[email-masked] <mailto:[email-masked]>>, Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Dick Hardt <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>
>> From: Phil Hunt [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>
>> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; William Denniss <[email-masked] <mailto:[email-masked]>>; M.Lizar@OCG <mailto:M.Lizar@OCG> <[email-masked] <mailto:[email-masked]>>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>> 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=>
>>> On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>> Mike,
>>>  
>>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, William Denniss <[email-masked] <mailto:[email-masked]>>, "M.Lizar@OCG <mailto:M.Lizar@OCG>" <[email-masked] <mailto:[email-masked]>>
>>> To: William Denniss <[email-masked] <mailto:[email-masked]>>; M.Lizar@OCG <mailto:M.Lizar@OCG> <[email-masked] <mailto:[email-masked]>>
>> 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=>
> 
> 
> 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= <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=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 14 Dec 2017 01:54:32 +0000

The ones in my previous email (quoted below):

From: Phil Hunt <[email-masked]>
Date: Wednesday, December 13, 2017 at 5:53 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

Phil,

From: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 11, 2017 at 10:09 AM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Saturday, December 9, 2017 at 6:04 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

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

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

Id-event mailing list

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

---

From: Phil Hunt <[email-masked]>
Date: Wed, 13 Dec 2017 18:39:18 -0800

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

> On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> 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=>
>> On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Phil,
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 14 Dec 2017 09:50:04 -0600

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:
> 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.  
>
> <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=>
>> On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle
>> 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?
>>  
>> -- 
>> *From: *Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> *Date: *Wednesday, December 13, 2017 at 5:53 PM
>> *To: *"Richard Backman, Annabelle" <[email-masked]
>> *Cc: *Justin Richer <[email-masked] <mailto:[email-masked]>>,
>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>> <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=>
>>> On Dec 13, 2017, at 5:46 PM, Richard Backman, Annabelle
>>> 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?
>>>  
>>> -- 
>>> *From: *"Richard Backman, Annabelle" <[email-masked]
>>> *Date: *Monday, December 11, 2017 at 10:09 AM
>>> *To: *Justin Richer <[email-masked] <mailto:[email-masked]>>,
>>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>>> <mailto:[email-masked]>>
>>> 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?
>>>  
>>> -- 
>>> *From: *Id-event <[email-masked]
>>> <mailto:[email-masked]>> on behalf of Justin Richer
>>> <[email-masked] <mailto:[email-masked]>>
>>> *Date: *Saturday, December 9, 2017 at 6:04 AM
>>> *To: *"[email-masked] <mailto:[email-masked]>"
>>> So the current syntax doesn't work for Tony's stated use case of
>>> even bundles while the new syntax does, then.
>>>  
>>>> *To:* Mike Jones <[email-masked]>
>>>> <mailto:[email-masked]>; Phil
>>>> Hunt <[email-masked]> <mailto:[email-masked]>
>>>> *Cc:* William Denniss <[email-masked]>
>>>> <mailto:[email-masked]>;
>>>> M.Lizar@OCG <[email-masked]>
>>>> <mailto:[email-masked]>; Yaron
>>>> Sheffer <[email-masked]> <mailto:[email-masked]>;
>>>> Dick Hardt <[email-masked]> <mailto:[email-masked]>;
>>>> SecEvent <[email-masked]> <mailto:[email-masked]>
>>>> 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.”
>>>>  
>>>> -- 
>>>> *To: *Phil Hunt <[email-masked]
>>>> <mailto:[email-masked]>>, "Richard Backman, Annabelle"
>>>> <[email-masked] <mailto:[email-masked]>>
>>>> <[email-masked]
>>>> <mailto:[email-masked]>>, Yaron Sheffer
>>>> <[email-masked] <mailto:[email-masked]>>, Dick Hardt
>>>> <[email-masked] <mailto:[email-masked]>>, SecEvent
>>>> **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
>>>>  
>>>> 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
>>>>  
>>>> <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=>
>>>>> *Date: *Tuesday, December 5, 2017 at 12:22 PM
>>>>> *To: *"Richard Backman, Annabelle" <[email-masked]
>>>>> *Cc: *Yaron Sheffer <[email-masked]
>>>>> <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
>>>>> 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
>>>>> Mike
>>>>> *From:* Id-event [mailto:[email-masked]] *On Behalf
>>>>> Of *Richard Backman, Annabelle
>>>>> *Sent:* Tuesday, December 5, 2017 11:40 AM
>>>>> *To:* William Denniss <[email-masked]
>>>>> <mailto:[email-masked]>>; M.Lizar@OCG
>>>>> *Cc:* Yaron Sheffer <[email-masked]
>>>>> *From: *Id-event <[email-masked]
>>>>> *Date: *Monday, December 4, 2017 at 7:20 PM
>>>>> *To: *"M.Lizar@OCG <mailto:M.Lizar@OCG>"
>>>>> *Cc: *Yaron Sheffer <[email-masked]
>>>>> On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG
>>>>>>> On 4 Dec 2017, at 20:46, M.Lizar@OCG
>>>>>>> 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? 
>>>>>>>  
>>>>>>>> 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.
>>>>>>>>  
>>>>>>>>>>> _[Phil] _Yup.   How would the group like to fix this?  We
>>>>>>>>>>> could make “events”
>>>>>>>>>> _[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.
>>>>>>>>>  
>>>>>>>>> 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
>>>>>>>>> * 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.
>>>>>>>>> Assuming everyone agrees, I will plan to remove these
>>>>>>>>> distinctions in the next update with some new text. Please
>>>>>>>>> comment if you have concerns.
>>>>>>>>  
>>>>>>>>> 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.
>>>>>>>>  
>>>>>>>> [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
>>>>>>>>> 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__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=>
>>>
>>>
>>>
>>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Dec 2017 16:33:18 +0000

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:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Thursday, December 14, 2017 7:50 AM
To: Phil Hunt <[email-masked]>; Richard Backman, Annabelle <[email-masked]>
Cc: [email-masked]; Justin Richer <[email-masked]>
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

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

On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

Cc: Justin Richer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

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

Phil,

                                                                -- Mike

Cc: William Denniss <[email-masked]><mailto:[email-masked]>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]><mailto:[email-masked]>; Yaron Sheffer <[email-masked]><mailto:[email-masked]>; Dick Hardt <[email-masked]><mailto:[email-masked]>; SecEvent <[email-masked]><mailto:[email-masked]>

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

Id-event mailing list

Id-event mailing list

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Dec 2017 09:31:54 -0800

+1

Phil

> On Dec 14, 2017, at 8:33 AM, Mike Jones <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 14 Dec 2017 18:49:33 +0000

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:

  1.  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.”
  2.  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.

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Thursday, December 14, 2017 at 9:32 AM
To: Mike Jones <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

+1

Phil

On Dec 14, 2017, at 8:33 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Thursday, December 14, 2017 7:50 AM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Thanks,

Ben

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

Marius

References:

Phil

/Dick

Id-event mailing list

Id-event mailing list

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=vfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY&s=oZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8&e=>

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Dec 2017 19:03:30 +0000

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, [email-masked]

Mike,

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.

+1

Phil

                                                       -- Mike

Thanks,

Ben

Phil

Phil

Phil,

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.

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

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…

- Mark

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.

   "events" into an array.

[Phil]

Yup.   How would the group like to fix this?  We could make “events”

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

Marius

 -- Justin

References:

Phil

/Dick

_______________________________________________ Id-event mailing list [email-masked]<mailto:[email-masked]> 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 [email-masked]<mailto:[email-masked]> 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=vfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY&s=oZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8&e=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 14 Dec 2017 20:37:01 +0000

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?

From: Id-event <[email-masked]> on behalf of Mike Jones <[email-masked]>
Date: Thursday, December 14, 2017 at 11:04 AM
To: Phil Hunt <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Mike,

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Dec 2017 13:12:19 -0800

I don't see any ambiguity. 

Phil

> On Dec 14, 2017, at 12:37 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> _______________________________________________ Id-event mailing list [email-masked] https://www.ietf.org/mailman/listinfo/id-event
> 
> 
> 
> 
> 
> 
> _______________________________________________ Id-event mailing list [email-masked] https://www.ietf.org/mailman/listinfo/id-event
>  
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 14 Dec 2017 23:03:45 +0000

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.

From: Phil Hunt <[email-masked]>
Date: Thursday, December 14, 2017 at 1:14 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Mike Jones <[email-masked]>, Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

On Dec 14, 2017, at 12:37 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> 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?

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 14, 2017 at 11:04 AM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Cc: Benjamin Kaduk, Justin Richer, [email-masked]<mailto:[email-masked]>

Mike,

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 14, 2017 at 9:32 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 14 Dec 2017 15:22:22 -0800

On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <
[email-masked]> wrote:

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

> *From: *Phil Hunt <[email-masked]>
> *Date: *Thursday, December 14, 2017 at 1:14 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *Mike Jones <[email-masked]>, Benjamin Kaduk <
> [email-masked]>, "[email-masked]" <[email-masked]>, Justin
> Richer <[email-masked]>
> 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?
>
>
>
> --
>
> *Date: *Thursday, December 14, 2017 at 11:04 AM
> *To: *Phil Hunt <[email-masked]>, "Richard Backman, Annabelle" <
> [email-masked]>
> *Cc: *Benjamin Kaduk <[email-masked]>, "[email-masked]" <
> [email-masked]>, Justin Richer <[email-masked]>
> By your logic, JWT should be even worse of an "interoperability disaster",
> but that doesn't seem to be the case in practice.
>
> 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.
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Phil Hunt <
> [email-masked]>
>
> *Date: *Thursday, December 14, 2017 at 9:32 AM
>
> *To: *Mike Jones <[email-masked]>
>
> *Cc: *Benjamin Kaduk <[email-masked]>, "Richard Backman, Annabelle" <
> [email-masked]>, Justin Richer <[email-masked]>, "[email-masked]"
> <[email-masked]>
>
> 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
>
>
>
> <[email-masked]>] *On Behalf Of *Benjamin Kaduk
>
> *Sent:* Thursday, December 14, 2017 7:50 AM
>
> *To:* Phil Hunt <[email-masked]>; Richard Backman, Annabelle <
> [email-masked]>
>
> *Cc:* [email-masked]; Justin Richer <[email-masked]>
>
> assertions are true of the current draft (and, if so, whether they should
> move from implicit to explicit assumptions).
>
> are true of the current draft, but could you please be explicit about your
> personal beliefs (as opposed to Mike's)?
>
> Thanks,
>
> Ben
>
> The draft is written based on group input. So no, not everything is backed
> directly by case. It is backed by consensus.
>
>
>
> audience, so can a stream of SET per receiver.  So single event only SETs
> and multi-aspect SETs are possible.
>
>
>
> stated in the text. But more importantly, what is the basis for imposing
> these limitations on SET in the first place?
>
>
>
> --
>
> *From: *Phil Hunt <[email-masked]>
>
> *To: *"Richard Backman, Annabelle" <[email-masked]>
>
> *Cc: *Justin Richer <[email-masked]>, "[email-masked]" <
> [email-masked]>
>
> restrictions are intentional, and if so why the use cases for SET are being
> restricted in this way?
>
>
>
> --
>
> *From: *"Richard Backman, Annabelle" <[email-masked]>
>
> *To: *Justin Richer <[email-masked]>, "[email-masked]" <
> [email-masked]>
>
> 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.
>
>
>
> stated in the text. But more importantly, what is the basis for imposing
> these limitations on SET in the first place?
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Justin Richer <
> [email-masked]>
>
> *To: *"[email-masked]" <[email-masked]>
>
> 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
>
> *From:* Richard Backman, Annabelle [mailto:[email-masked]
> <[email-masked]>]
>
> <[email-masked]>; Phil Hunt <[email-masked]>
> <[email-masked]>
>
> *Cc:* William Denniss <[email-masked]> <[email-masked]>;
> M.Lizar@OCG <[email-masked]> <[email-masked]>;
> Yaron Sheffer <[email-masked]> <[email-masked]>; Dick Hardt
> <[email-masked]> <[email-masked]>; SecEvent
> <[email-masked]> <[email-masked]>
>
> 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.
>
>
>
> “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.”
>
>
>
> --
>
> *From: *Mike Jones <[email-masked]>
>
> *To: *Phil Hunt <[email-masked]>, "Richard Backman, Annabelle" <
> [email-masked]>
>
> *Cc: *William Denniss <[email-masked]>, "M.Lizar@OCG" <
> [email-masked]>, Yaron Sheffer <[email-masked]>,
> Dick Hardt <[email-masked]>, SecEvent <[email-masked]>
>
> 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.
>
>
>
> adopted by numerous diverse applications.  SETs currently have that same
> level of flexibility – by design.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
>
> *Cc:* Mike Jones <[email-masked]>; William Denniss <
> [email-masked]>; M.Lizar@OCG <[email-masked]>; Yaron
> Sheffer <[email-masked]>; Dick Hardt <[email-masked]>;
> SecEvent <[email-masked]>
>
> 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
>
>
>
> 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.
>
>
>
> --
>
> *From: *Mike Jones <[email-masked]>
>
> *To: *"Richard Backman, Annabelle" <[email-masked]>, William Denniss
> <[email-masked]>, "M.Lizar@OCG" <[email-masked]>
>
> *Cc: *Yaron Sheffer <[email-masked]>, Phil Hunt <
> [email-masked]>, SecEvent <[email-masked]>, Dick Hardt <
> [email-masked]>
>
> simple solution to enabling SETs to contain only a single event description
> for profiles that want that – a solution proposed by Yaron
> 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
>
>
>
> <[email-masked]>] *On Behalf Of *Richard Backman, Annabelle
>
> *To:* William Denniss <[email-masked]>; M.Lizar@OCG <m.lizar@
> openconsentgroup.com>
>
> *Cc:* Yaron Sheffer <[email-masked]>; Phil Hunt <
> [email-masked]>; SecEvent <[email-masked]>; Dick Hardt <
> [email-masked]>
>
> 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?
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of William Denniss
> <[email-masked]>
>
> *To: *"M.Lizar@OCG" <[email-masked]>
>
> [email-masked]>, SecEvent <[email-masked]>, Phil Hunt <
> [email-masked]>
>
> 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
> 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
> 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,
> *[Phil]  *
> *[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.
>
>
>
>
>
>
>
> https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U
> 64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-
> PmKhkF_tUZSc2sXBw&e=
>
>
>
>
>
>
>
>
>
> _______________________________________________ Id-event mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/id-event
> prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ&s=71lmYUkVWVH_
> HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=
>
>
>
>
>
>
>
>
> _______________________________________________ Id-event mailing list
> [email-masked] 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=vfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY&s=oZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8&e=>
>
>
>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 15 Dec 2017 10:08:56 -0500

+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 <[email-masked]> wrote:
> 
> On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> 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
> 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.
> 
> 
>  
> 
>  
> 
> -- 
> 
> From: Phil Hunt <[email-masked] <mailto:[email-masked]>>
> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>
> On Dec 14, 2017, at 12:37 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Cc: Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>
> Cc: Benjamin Kaduk, Justin Richer, [email-masked] <mailto:[email-masked]>
> 
> 
> Mike,
> 
>  
> 
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked] <mailto:[email-masked]>>
> 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> 
> Cc: Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> On Dec 14, 2017, at 8:33 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Benjamin Kaduk
> 
> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>
> 
> Cc: [email-masked] <mailto:[email-masked]>; Justin Richer <[email-masked] <mailto:[email-masked]>>
> 
> 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=>
> On Dec 13, 2017, at 5:54 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> From: Phil Hunt <[email-masked] <mailto:[email-masked]>>
> 
> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
> 
> Cc: Justin Richer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> Cc: William Denniss <[email-masked]> <mailto:[email-masked]>; M.Lizar@OCG <mailto:M.Lizar@OCG> <[email-masked]> <mailto:[email-masked]>; Yaron Sheffer <[email-masked]> <mailto:[email-masked]>; Dick Hardt <[email-masked]> <mailto:[email-masked]>; SecEvent <[email-masked]> <mailto:[email-masked]>
> _______________________________________________ Id-event mailing list [email-masked] <mailto:[email-masked]> 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 [email-masked] <mailto:[email-masked]> 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=vfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY&s=oZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8&e=>
>  
> 
>  
> 
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Dec 2017 16:12:37 +0000

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:[email-masked]]
Sent: Friday, December 15, 2017 7:09 AM
To: Marius Scurtescu <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; Phil Hunt <[email-masked]>; Mike Jones <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Consensus :: Single Event Syntax

On Dec 14, 2017, at 6:22 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
You can’t conceive of any combination of event statements that could be ambiguous?

+1

Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>

Phil

Mike,

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 15 Dec 2017 08:50:58 -0800

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 <[email-masked]>
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:[email-masked]]
> *Sent:* Friday, December 15, 2017 7:09 AM
> *To:* Marius Scurtescu <[email-masked]>
> *Cc:* Richard Backman, Annabelle <[email-masked]>; Phil Hunt <
> [email-masked]>; Mike Jones <[email-masked]>; Benjamin
> Kaduk <[email-masked]>; [email-masked]
> +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?
>
>
>
> same logical event. The combination of event statements cannot be ambiguous.
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Dec 2017 09:35:27 -0800

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 <[email-masked]> wrote:
> 
> Simpler? 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 <[email-masked]> wrote:
>> On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman, Annabelle <[email-masked]> wrote:
>> 
> 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=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 15 Dec 2017 19:14:48 +0000

> if this mysterious ambiguity exists, the alt draft does nothing to address it.

“Current draft syntax vs. proposed draft syntax” is a false dichotomy. Whether or not people like the proposed draft has no bearing on the fact that the current draft syntax does not work for the use cases that that you say it is intended to meet:

  *   Extensions are ambiguous as it is unclear which event statement an extension applies to.
  *   Representation of “different aspects of a single logical event” is arbitrarily limited by the inability to include multiple instances of a single event type in the same SET.

If SET is trying to meet these use cases, it should fully meet them, not simply offer a half-hearted solution that falls over in the face of non-trivial applications. If SET isn’t actually trying to meet these use cases, then the current syntax is overly complex and invites misuse. At that point, the proposed single event syntax (without the Related Events piece) is much simpler and offers fewer opportunities for out-of-spec usage.

(For the record, the proposed draft addresses this ambiguity by providing guidance for defining extensions that add claims to existing event statements. With that draft, “address_verified” would be a claim – with a Collision Resistant Name – that could be added to the relevant event statement.)

> The example Annabelle gave isn't even a valid example.

How is this example invalid? It contains four event statements that all express aspects of the same “logical” event: an update to an account.

> Mike has commented extensively how jwt has similar practice.

Comparing SET to JWT is inappropriate for the simple reason that there is no expectation that a single JWT will represent multiple profiles of JWT. With SET, there is the expectation that a single SET will contain two or more profiles of SET, which raises the bar on what needs to be defined in the base spec versus what can be deferred to the profiling specs.

From: Phil Hunt <[email-masked]>
Date: Friday, December 15, 2017 at 9:36 AM
To: Marius Scurtescu <[email-masked]>
Cc: Mike Jones <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>, Justin Richer <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Phil

On Dec 15, 2017, at 8:50 AM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
Simpler? Yes.

Marius

On Fri, Dec 15, 2017 at 8:12 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 15, 2017 7:09 AM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

+1

Phil

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Dec 2017 12:52:58 -0800

In line…

Thanks for the discussion. 

Phil

> On Dec 15, 2017, at 11:14 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Extensions are ambiguous as it is unclear which event statement an extension applies to.
<PH> The Event URI defines this. For exmaple in the example, the event uri for password reset identifies that the extension adds reset count (see figure 1). The URI:
https://example.com/scim/event/passwordResetExt

Would be understood and document the purpose for the event payload. In this case an extension to: urn:ietf:params:scim:event:passwordReset

This is not ambiguous at all. That’s why the example is there.

> Representation of “different aspects of a single logical event” is arbitrarily limited by the inability to include multiple instances of a single event type in the same SET.

<PH> At one time, events was an array. At Justin and many other’s urging that was changed to an object so prevent repeat URIs as this was deemed ambiguous.

The format is hardly arbitrary. It is there to prevent repeat URIs which would lead to ambiguity.
> If SET is trying to meet these use cases, it should fully meet them, not simply offer a half-hearted solution that falls over in the face of non-trivial applications. If SET isn’t actually trying t…

<PH> As many many people on the thread have said it does meet there use cases.  Further people are using it for multi-aspect and their cases are met.  

You and Marius say it does not do so for RISC. Yet as a fellow RISC member, I believe strongly that RISC’s cases have been met.  Other RISC members also agree. Please do not represent this as the RISC community is not being listened to. 

Multi-aspect SETs are a decision of a transmitter and receiver, not of the profile.  If they decide it adds meaningful information, then this can hardly be ambiguous.

You and I have agreed that to ensure that your receivers will not get confused. We agreed that adding an option to the Stream Configuration that requires single event payloads for the receiver. I plan to make sure the group discusses this feature of stream configuration so your concern is addressed.

> How is this example invalid? It contains four event statements that all express aspects of the same “logical” event: an update to an account.
<PH> The example you gave is putting “claims” where “event_uris” should be. Of course that is ambiguous because the example SET is not valid.
> Comparing SET to JWT is inappropriate for the simple reason that there is no expectation that a single JWT will represent multiple profiles of JWT. With SET, there is the expectation that a single…

<PH> A SET *is* a JWT.  Just like adding additional claims to a JWT doesn’t break JWT, neither does adding URIs.  In fact, since Event URIs are self-describing, they don’t require a common registry. I strongly believe that because of the use of URIs (rather than simple claim names), SET is substantially less ambiguous.

> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>
> On Dec 15, 2017, at 8:50 AM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Simpler? Yes. 
>>  
>> On Fri, Dec 15, 2017 at 8:12 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>>   <>
>>> From: Justin Richer [mailto:[email-masked] <mailto:[email-masked]>] 
>>> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>>> Cc: Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; Phil Hunt <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>; Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>>> On Dec 14, 2017, at 6:22 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>>>  
>>>>> 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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=>
>>>  
>> 
>>  
>> 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= <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=>_______________________________________________
> Id-event mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=rC7AbAkZFzhUTi9hozWngjkykVYaEiqBlgD1Ew0d-eM&s=mdbES8GMPZhIsAkw3p0N2mWcPdmosQtV48Cdg6stfwQ&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=rC7AbAkZFzhUTi9hozWngjkykVYaEiqBlgD1Ew0d-eM&s=mdbES8GMPZhIsAkw3p0N2mWcPdmosQtV48Cdg6stfwQ&e=>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 15 Dec 2017 14:42:39 -0800

On Fri, Dec 15, 2017 at 9:35 AM, Phil Hunt <[email-masked]> wrote:

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

Phil, this hard core black and white attitude makes it very hard to have a
dialog. Can you make an effort and find some value in the alt proposal?

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

Not sure what your point is regarding JWT and how that is relevant.

> How much hard fact do we need Marius?

You have provided none in this message, only strong statements.

Again, let's find a way to have a real dialog and to respect each other.

>> [email-masked]>; Mike Jones <[email-masked]>;
>> Benjamin Kaduk <[email-masked]>; [email-masked]
>> 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
>>
>> By your logic, JWT should be even worse of an "interoperability
>> disaster", but that doesn't seem to be the case in practice.
>>
>> 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.
>>
>>
>>
>> Yaron Sheffer <[email-masked]> <[email-masked]>; Dick
>> Hardt <[email-masked]> <[email-masked]>; SecEvent
>> *To: *"Richard Backman, Annabelle" <[email-masked]>, William
>> Denniss <[email-masked]>, "M.Lizar@OCG" <
>> [email-masked]>
>>
>> *To:* William Denniss <[email-masked]>; M.Lizar@OCG <
>> [email-masked]>
>>
>> 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:
>>
>> *From: *Id-event <[email-masked]> on behalf of William
>> Denniss <[email-masked]>
>>
>> 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
>> [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.
>>
>>
>>
>> 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
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzw
>> Y&s=YnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4&e=
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcE
>> k&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=
>>
>>
>>
>>
>>
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=prG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0A
>> Q&s=71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc&e=
>>
>>
>>
>>
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=>
>>
>>
>>
>
> kjkQujhpavR4XGW53BfHZi88NpLjkscgoFw3lzEAbCw&s=1UEK06KT-
> BL3cIelkPHxclIVVuDqVTOhx68Ucy0HnRo&e=
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 15 Dec 2017 23:44:42 +0000

Inline.

From: Phil Hunt <[email-masked]>
Date: Friday, December 15, 2017 at 12:58 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>, Benjamin Kaduk <[email-masked]>, Mike Jones <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

In line…

Phil

[richanna]
At a minimum, you have an unstated requirement that event extensions define the fixed set of events to which they may apply. Unless the extension can only apply to a single event type, then you still have the potential for ambiguity, so you have further unstated requirements to deal with that. But restricting extensions to a fixed set of event types (or to a single event type) is not acceptable, as RISC will want people to be able to define extensions that may apply to all RISC events – those defined in the initial spec and those that might come later.

If you defer resolving ambiguous cases to the profiles, then you kill interoperability. Any SET processor has to be intimately familiar with the events and extensions to which it might be exposed in order for it to know how to interpret ambiguous SETs (note: I am NOT talking about how the receiver decides what to do given the information).
[/richanna]

[richanna]
The format is not arbitrary. The decision to block this ambiguity by not other ambiguity is arbitrary. The decision that a collection of related event statements will never need more than one instance of any given event type is arbitrary.
[/richanna]

  *

[richanna]
Those are event names, not claims. For simplicity, I abbreviated the event names in my example; I assumed that would be obvious, but apparently not. Sorry for the confusion. Here is the example SET again, without abbreviated event names:
{
  // ...other SET claims...
  "events": {
    "https://example.com/example_profile/events/account_updated": { },
   "https://example.com/example_profile/events/shipping_address_added": {
      // ...address claims...
    },
    "https://example.com/example_profile/events/billing_address_added": {
      // ...address claims...
    },
    "https://example.com/example_profile/events/address_verified": {
      "is_verified": true
    }
 }
}
[/richanna]

[richanna]
None of this is relevant to the issue; I have no idea why you’re bringing up registries, of all things.

It is incorrect to compare the members of the “events” claim with claims at the JWT level. JWT does not make any statements about the nature of claims not defined in JWT other than that they are “normally statements about the subject.” SET makes stronger statements about the nature of members of the “events” claim: that they are extensions of a primary event, and should be related to a single event. But SET does not provide a programmatic way to understand the relationship between members of the “events” claim (e.g. whether or not one event statement extends another one), so this aspect of the spec is completely ungeneralizable. Even an intermediate processor has to have intimate knowledge of event types in order to do anything beyond basic JWT validation. An implementer cannot build a generic router that ingests SETs and hands off event statements to appropriate systems (an implementation pattern members of the working group have brought up as desirable) without having a deep understanding of all the event types and extensions it may encounter.
[/richanna]

Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>

Phil

Marius

+1

Phil

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=rC7AbAkZFzhUTi9hozWngjkykVYaEiqBlgD1Ew0d-eM&s=mdbES8GMPZhIsAkw3p0N2mWcPdmosQtV48Cdg6stfwQ&e=

---

From: Justin Richer <[email-masked]>
Date: Sun, 17 Dec 2017 14:40:56 -0500

I honestly do not find the current syntax simpler — and I proposed it. Annabelle did a better job at expressing and enabling what I was after. I found the parallel arrays of early drafts to be absurdly complex , and tried to simplify from that point into something somewhat reasonable. I had no intention, or inkling, that it would be abused in the way that people are currently talking about. And if the syntax is so easily abused, in all the ways that have been described on this list (such as multiple ambiguous objects, confusion about primary/secondary, extension vs. parallelism, batch payloads, etc, etc, etc), then we need to ask ourselves if the syntax is in fact any good or if it’s a bad design. I now believe it’s a bad design, and we’ve got a chance to fix it based on feedback from early implementers. 

I fully appreciate that people don’t like to change things, but I’m afraid that if we don’t change things now when they’re under our control, we’re going to be stuck in the very short future with a competing standard that muddies the water — or worse, a set of mutually incompatible or incomprehensible things that all “comply” with a meaningless spec. 

I said in Seoul that we need to focus on commonality. This latest discussion has been a strong call for codifying that commonality, with a small chorus of “it works for my slice and I don’t care about anything else” that doesn’t want to discuss anything anymore. You have to realize, this isn’t people saying “hang on we just need to think harder about this”, without bringing concrete arguments and use cases to the table. I’ve seen that stall tactic applied in the IETF countless times, and if that were being applied here you can be sure I’d call it out. We sent the draft for last call. We got feedback. We ignore this at our own peril.

 — Justin

> On Dec 15, 2017, at 11:50 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> Simpler? Yes.
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 17 Dec 2017 22:12:39 +0000

Justin, I believe that you are severely mischaracterizing the reality on the ground.  Developers building at least four use cases have stated that the existing specification works well for their use case:

  *   SCIM
  *   Back-Channel Logout
  *   Consent Receipts
  *   RISC

Yes, I understand that some RISC developers have also advocated changing the data structure, but doing so would mean ignoring the feedback from the early (and not-so early) developers of all the other use cases, and also ignoring the RISC members who think that we’re already good to go.

                                                       -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Sunday, December 17, 2017 11:41 AM
To: Marius Scurtescu <[email-masked]>
Cc: Mike Jones <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; Phil Hunt <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Consensus :: Single Event Syntax

 — Justin

On Dec 15, 2017, at 11:50 AM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Simpler? Yes.

Marius

+1

Phil

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

---

From: Justin Richer <[email-masked]>
Date: Mon, 18 Dec 2017 09:34:30 -0500

I disagree, Mike. My stance takes into account those that say the 
current structure works for them, and trying to understand how the new 
structure would work as well. Instead, I believe you're miscategorizing 
the support.

Consent Receipts is not using SET right now, and doing so at all would 
mean a syntax change for them no matter which format was used. I had 
advocated that the group follow this work when I brought the use case 
over here initially, but they've been developing in their own space 
instead. The 1.1 draft version of CR could be easily carried in either 
format, with some tweaks.

The SCIM working group does not exist and, as raised in Seoul, there's a 
question where any SCIM based work would go. So that's not real, and 
could go either way.

As you mentioned, the RISC group is split on the issue.

You're counting all of these as support for the old format where you 
could easily count them as support for the new format -- since "it works 
for me" applies both ways.

  -- Justin

On 12/17/2017 5:12 PM, Mike Jones wrote:
>
> Justin, I believe that you are severely mischaracterizing the reality 
> on the ground.  Developers building at least four use cases have 
> stated that the existing specification works well for their use case:
>
>   * SCIM
>   * Back-Channel Logout
>   * Consent Receipts
>   * RISC
>
> Yes, I understand that some RISC developers have also advocated 
> changing the data structure, but doing so would mean ignoring the 
> feedback from the early (and not-so early) developers of all the other 
> use cases, and also ignoring the RISC members who think that we’re 
> already good to go.
>
> -- Mike
>
> *Sent:* Sunday, December 17, 2017 11:41 AM
> *Cc:* Mike Jones <[email-masked]>; Richard Backman, 
> Annabelle <[email-masked]>; Phil Hunt <[email-masked]>; 
> I honestly do not find the current syntax simpler — and I proposed it. 
> Annabelle did a better job at expressing and enabling what I was 
> after. I found the parallel arrays of early drafts to be absurdly 
> complex , and tried to simplify from that point into something 
> somewhat reasonable. I had no intention, or inkling, that it would be 
> abused in the way that people are currently talking about. And if the 
> syntax is so easily abused, in all the ways that have been described 
> on this list (such as multiple ambiguous objects, confusion about 
> primary/secondary, extension vs. parallelism, batch payloads, etc, 
> etc, etc), then we need to ask ourselves if the syntax is in fact any 
> good or if it’s a bad design. I now believe it’s a bad design, and 
> we’ve got a chance to fix it based on feedback from early implementers.
>
> I fully appreciate that people don’t like to change things, but I’m 
> afraid that if we don’t change things now when they’re under our 
> control, we’re going to be stuck in the very short future with a 
> competing standard that muddies the water — or worse, a set of 
> mutually incompatible or incomprehensible things that all “comply” 
> with a meaningless spec.
>
> I said in Seoul that we need to focus on commonality. This latest 
> discussion has been a strong call for codifying that commonality, with 
> a small chorus of “it works for my slice and I don’t care about 
> anything else” that doesn’t want to discuss anything anymore. You have 
> to realize, this isn’t people saying “hang on we just need to think 
> harder about this”, without bringing concrete arguments and use cases 
> to the table. I’ve seen that stall tactic applied in the IETF 
> countless times, and if that were being applied here you can be sure 
> I’d call it out. We sent the draft for last call. We got feedback. We 
> ignore this at our own peril.
>
>  — Justin
>
>     On Dec 15, 2017, at 11:50 AM, Marius Scurtescu
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Simpler? 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
>     <[email-masked] <mailto:[email-masked]>>
>     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:[email-masked]
>         <mailto:[email-masked]>]
>         *To:* Marius Scurtescu <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* Richard Backman, Annabelle <[email-masked]
>         <mailto:[email-masked]>>; Phil Hunt <[email-masked]
>         <mailto:[email-masked]>>; Mike Jones
>         <[email-masked]
>         <mailto:[email-masked]>>; Benjamin Kaduk
>         <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>
>         +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
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>             On Thu, Dec 14, 2017 at 3:03 PM, Richard Backman,
>             Annabelle<[email-masked]
>             <mailto:[email-masked]>>wrote:
>
>                 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
>
>             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.
>
>                 -- 
>
>                 *From:*Phil Hunt <[email-masked]
>                 *Date:*Thursday, December 14, 2017 at 1:14 PM
>                 *Cc:*Mike Jones <[email-masked]
>                 <mailto:[email-masked]>>, Benjamin Kaduk
>                 <[email-masked] <mailto:[email-masked]>>,
>                 "[email-masked] <mailto:[email-masked]>"
>                 <[email-masked] <mailto:[email-masked]>>, Justin
>                 Richer <[email-masked] <mailto:[email-masked]>>
>                 On Dec 14, 2017, at 12:37 PM, Richard Backman,
>                 Annabelle <[email-masked]
>                 <mailto:[email-masked]>> 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
>                     <mailto:[email-masked]>> on behalf of
>                     Mike Jones <[email-masked]
>                     *Date:*Thursday, December 14, 2017 at 11:04 AM
>                     *To:*Phil Hunt <[email-masked]
>                     <mailto:[email-masked]>>, "Richard Backman,
>                     Annabelle" <[email-masked]
>                     *Cc:*Benjamin Kaduk <[email-masked]
>                     <mailto:[email-masked]>>, "[email-masked]
>                     <mailto:[email-masked]>" <[email-masked]
>                     <mailto:[email-masked]>>, Justin Richer
>                     By your logic, JWT should be even worse of an
>                     "interoperability disaster", but that doesn't seem
>                     to be the case in practice.
>
>                     Cc: Benjamin Kaduk, Justin
>                     Richer,[email-masked] <mailto:[email-masked]>
>
>                     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.
>
>                     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.
>
>                     -- 
>
>                     <mailto:[email-masked]>> on behalf of
>                     Phil Hunt <[email-masked]
>                     *Date:*Thursday, December 14, 2017 at 9:32 AM
>
>                     *To:*Mike Jones <[email-masked]
>                     *Cc:*Benjamin Kaduk <[email-masked]
>                     <mailto:[email-masked]>>, "Richard Backman,
>                     Annabelle" <[email-masked]
>                     <mailto:[email-masked]>>, Justin Richer
>                     <[email-masked] <mailto:[email-masked]>>,
>                     "[email-masked] <mailto:[email-masked]>"
>                     On Dec 14, 2017, at 8:33 AM, Mike Jones
>                     <[email-masked]
>                     <mailto:[email-masked]>> 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
>                         *From:*Id-event
>                         [mailto:[email-masked]]*On Behalf
>                         Of*Benjamin Kaduk
>
>                         *Sent:*Thursday, December 14, 2017 7:50 AM
>
>                         *To:*Phil Hunt <[email-masked]
>                         <mailto:[email-masked]>>; Richard
>                         Backman, Annabelle <[email-masked]
>                         *Cc:[email-masked]
>                         <mailto:[email-masked]>; Justin Richer
>                         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
>
>                             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.
>
>                             <mailto:[email-masked]>
>
>                                 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.
>
>                                 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?
>
>                                 -- 
>
>                                 *From: *Phil Hunt
>                                 "[email-masked]
>                                 <mailto:[email-masked]>"
>                                 <[email-masked]
>                                 <mailto:[email-masked]>
>
>
>                                     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?
>
>                                     -- 
>
>                                     *To: *Justin Richer
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>,
>                                     "[email-masked]
>                                     <mailto:[email-masked]>"
>                                     <[email-masked]
>                                     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
>                                         The “events” claim definition
>                                         is already clear that the
>                                         “events” values convey
>                                         multiple aspects of a single
>                                         logical event - not
>                                         The semantics of this claim is
>                                         to define a set of event
>                                         statements
>
>                                         You’re describing a
>                                         theoretical problem that’s not
>                                         actually present in the
>                                         working group spec.
>
>                                         -- Mike
>
>                                         *From:* Richard Backman,
>                                         Annabelle
>                                         [mailto:[email-masked]]
>
>                                         <mailto:[email-masked]>;
>                                         Phil Hunt
>                                         <[email-masked]>
>                                         <mailto:[email-masked]>
>
>                                         *Cc:* William Denniss
>                                         <[email-masked]>
>                                         <mailto:[email-masked]>;M.Lizar@OCG
>                                         <mailto:M.Lizar@OCG>
>                                         <[email-masked]>
>                                         <mailto:[email-masked]>;
>                                         Yaron Sheffer
>                                         <[email-masked]>
>                                         <mailto:[email-masked]>;
>                                         Dick Hardt
>                                         <[email-masked]>
>                                         <mailto:[email-masked]>;
>                                         <mailto:[email-masked]>
>
>                                         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
>                                         Drawing an analogy to
>                                         programming, I’m talking about
>                                         defining what the syntax
>                                         “function_x() && function_y()”
>                                         means. Regardless of what
>                                         meaning of that syntax as
>                                         “true if the result of
>                                         function_x is true and the
>                                         <mailto:[email-masked]>>,
>                                         "M.Lizar@OCG
>                                         <mailto:M.Lizar@OCG>"
>                                         <[email-masked]
>                                         <mailto:[email-masked]>>,
>                                         Dick Hardt
>                                         <[email-masked]
>                                         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
>                                         <[email-masked]
>                                         <[email-masked]
>                                         <mailto:[email-masked]>>;
>                                         Dick Hardt
>                                         <[email-masked]
>                                         <mailto:[email-masked]>>;
>                                         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
>
>                                         <mailto:[email-masked]>
>
>
>
>
>
>                                             On Dec 5, 2017, at 12:57
>                                             PM, Richard Backman,
>                                             Annabelle
>                                             <[email-masked]
>                                             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
>                                             *To: *"Richard Backman,
>                                             Annabelle"
>                                             <[email-masked]
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>,
>                                             "M.Lizar@OCG
>                                             <mailto:M.Lizar@OCG>"
>                                             <mailto:[email-masked]>>,
>                                             Phil Hunt
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>,
>                                             SecEvent
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>,
>                                             Dick Hardt
>                                             <[email-masked]
>                                             *Subject: *RE: [Id-event]
>                                             Consensus :: Single Event
>                                             Syntax
>
>                                             Morteza already pointed
>                                             out
>                                             simple solution to
>                                             enabling SETs to contain
>                                             only a single event
>                                             description for profiles
>                                             that want that – a
>                                             solution proposed by Yaron
>                                             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
>                                             *From:* Id-event
>                                             [mailto:[email-masked]]
>                                             *On Behalf Of *Richard
>                                             Backman, Annabelle
>
>                                             <mailto:[email-masked]>>;
>                                             Phil Hunt
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>;
>                                             SecEvent
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>;
>                                             Dick Hardt
>                                             <[email-masked]
>                                             *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?
>
>                                             -- 
>
>                                             <mailto:[email-masked]>>
>                                             on behalf of William
>                                             Denniss
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>,
>                                             Dick Hardt
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>,
>                                             SecEvent
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>,
>                                             Phil Hunt
>                                             <[email-masked]
>                                             *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 spec works well
>                                                 for the consent a
>                                                 privacy syntax use
>                                                 cases we are aware of
>                                                 (full stop)
>                                                     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
>                                                         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
>                                                         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
>                                                             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
>                                                             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
>                                                             It must
>                                                             not be
>                                                             used to
>                                                             convey
>                                                             multiple
>                                                             distinct
>                                                             (e.g.
>                                                             transactions)
>                                                             about a
>                                                             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
>                                                         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.
>                                                         Justin also
>                                                         agreed (and
>                                                         may have
>                                                         switched
>                                                         positions) [7]
>                                                             +1, drop
>                                                             "primary"
>                                                             and keep
>                                                             it an object
>                                                         Oracle
>                                                         Corporation,
>                                                         Identity Cloud
>                                                         Services Architect
>                                                         <mailto:[email-masked]>
>
>                                                             On Dec 1,
>                                                             2017, at
>                                                             8:50 AM,
>                                                             Dick Hardt
>                                                             <[email-masked]
>                                                             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.
>                                                             an
>                                                             proposed
>                                                             syntax
>                                                             that
>                                                             ensures
>                                                             one event
>                                                             per SET,
>                                                             and
>                                                             enables
>                                                             multiple
>                                                             events per
>                                                             SET when
>                                                             desired
>                                                             We will
>                                                             track
>                                                             results
>                                                             here:
>                                                             Discussion
>                                                             to be on
>                                                             the mail
>                                                             list as
>                                                             usual, not
>                                                             in the
>                                                             issue tracker!
>                                                             Id-event
>                                                             mailing list
>                                                             <mailto:[email-masked]>
>
>                                                         Id-event
>                                                         mailing list
>                                                         <mailto:[email-masked]>
>
>                                                     <mailto:[email-masked]>
>
>                                                 <mailto:[email-masked]>
>
>                                             <mailto:[email-masked]>
>
>                                         Id-event mailing
>                                         [email-masked]
>                                         <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/id-event
>                                     <mailto:[email-masked]>
>
>                             Id-event mailing [email-masked]
>                             <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Mon, 18 Dec 2017 07:51:01 -0800

I agree with Mike.

I do not find this proposal workable because it excludes the requirements of many with running code now. 

Further since implementers are following the wg draft they should not have to continually justify themselves. Those that seek to break implementation must justify. 

The only concern i heard is easily mitigated by allowing a receiver to indicate desire for single event SETs. This does not break running code. 

Phil

> On Dec 18, 2017, at 6:34 AM, Justin Richer <[email-masked]> wrote:
> 
> I disagree, Mike. My stance takes into account those that say the current structure works for them, and trying to understand how the new structure would work as well. Instead, I believe you're miscategorizing the support.
> 
> Consent Receipts is not using SET right now, and doing so at all would mean a syntax change for them no matter which format was used. I had advocated that the group follow this work when I       brought the use case over here initially, but they've been developing in their own space instead. The 1.1 draft version of CR could be easily carried in either format, with some tweaks. 
> The SCIM working group does not exist and, as raised in Seoul, there's a question where any SCIM based work would go. So that's not real, and could go either way. 
> You're counting all of these as support for the old format where you could easily count them as support for the new format -- since "it works for me" applies both ways. 
>  -- Justin
> 
>> SCIM
>> Back-Channel Logout
>> Consent Receipts
>> RISC
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ&s=KktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY&e=

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 18 Dec 2017 16:20:53 +0000

+1

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, December 18, 2017 7:51 AM
To: Justin Richer <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; Mike Jones <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; [email-masked]; Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

I agree with Mike.

Phil

On Dec 18, 2017, at 6:34 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

  *   SCIM
  *   Back-Channel Logout
  *   Consent Receipts
  *   RISC

                                                       -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Sunday, December 17, 2017 11:41 AM
To: Marius Scurtescu <[email-masked]><mailto:[email-masked]>
Cc: Mike Jones <[email-masked]><mailto:[email-masked]>; Richard Backman, Annabelle <[email-masked]><mailto:[email-masked]>; Phil Hunt <[email-masked]><mailto:[email-masked]>; Benjamin Kaduk <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

 — Justin

Simpler? Yes.

Marius

+1

Phil

+1
Phil

                                                       -- Mike

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3DsssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM%26m%3D85cyhAYmmz380nKWOgwzhl0dZmKMtiFnEEge6fiK1rA%26s%3DiccVyyTJcw_ZwESlqJw6m2HkrrnU0xd4xZjIbfavofA%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=RAss9kQt3vHc%2F28dp7jQnQOHwuckpv5nIMGTSEt2XQo%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DHKiKUZgXDLuGHjfG_wYgXCVNOctJXueCEh63hvF_ixc%26s%3DnvU8oqF7Izoh-0sBdFy3FOwGW-pNlwpynSj4aet5atE%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=zppcinIb1W16NlovqbRyJ%2FzXF6QyyYFnpGPh%2BKHRuUo%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DprG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ%26s%3Dtqqw1ywr-k_fQTVlTIQ-V24SRkRzlh5clMJQKLMLANw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=dZvF4mYHssVCopMsXbco5XqKsXowyDc4Smbit6Y3ixw%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

Mike,

Morteza already pointed out<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mailarchive.ietf.org_arch_msg_id-2Devent_KPaK5aN3EeIybWJmQOJiqdHXQzg%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DZClAgy65x4a1O93YYenj_z_6Bxd_6sMzPOs8PLi06XA%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=zrUnAKpLa4P8HGMX1ba3tJim0gFm6bT7o7e5W7L5tNY%3D&reserved=0> a simple solution to enabling SETs to contain only a single event description for profiles that want that – a solution proposed by Yaron<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3Dtac2j_cTgyBwnnfHNTPzlRUwOCjxvascShR4JfccwMg%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=xFcj%2Fz048ThM0h36t5O0GweZot0pj%2B8QtF8chKaBoOc%3D&reserved=0> 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

- Mark

   "events" into an array.

[Phil]

[Yaron]

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3D8DBZ5hsA4WNFez3mJr2W9TW0WCYTWMbY1Vs5sgcIauQ%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=EinEwfp9olMTa5LDfEETqp3Nx5%2F0DTfohq9pw%2BmO1C4%3D&reserved=0>).  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

 -- Justin

References:
[1] - https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00298.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DrG_9NWsC86NC5EDI8paY2lIrUkHUirGG3jfmoHhYAw8%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=2cUVhILq7B6oAnqTSIALGXgsAXK2Ak4m1ZWRfeUrMhg%3D&reserved=0>
[2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00299.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DwE8wEkrp-0wxrzKFqozLAsjsD2qgA2mCoDZQp5lwqdA%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=dfd7BjuCDWtlqxsgFh09EZT6NR6c%2BP5LuAORVBH7wF0%3D&reserved=0>
[3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00345.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DQEGxsGOAn3D6pmmzeLtQ_gkOSgxpq-8ce2CbXfe2Zk8%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=rRmMO0IvzgEUTXfDTXSc75tylTM3%2BnaJbyENki0hllI%3D&reserved=0>
[4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00347.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DIcdLUKGzpKm8QwfE2mo-NufvoiWgjsj__BKRvGGod8c%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=rpLu7fjkx41x%2B0ersQTiqvMyY7UGqKO%2FkTfbtpFzWvA%3D&reserved=0>
[5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00349.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3Dd0uNsjizWSlLYksDHdqZaYC6Ix0OMDltFs2e4QjTJJE%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=LMfPPOVpUrbhGm%2FSguTihmZAseD%2Bb21ZzjNJt0BUAjw%3D&reserved=0>
[6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00365.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3D_FtWiNomXopU9A9_k7A1nsjMQfaXZ_ZjxgBxNrhUBIQ%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=Sy4H7kAwGCojVyOt9PQCs9c%2BXYH8Lcyv2udF6H5TukQ%3D&reserved=0>
[7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3Dk5JC5HYCfm0BtQJar8_ZAKRUzgUsJYaCbtiLWOkWxJc%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=kis2mtAYghiv%2BAN4Ec19pyohazncI1p4O72OBqGgqpY%3D&reserved=0>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com_%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DzQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=Y%2FlD6tPrGxemOTjVZ0CWjsUWIRUYxrih4otmI%2F1vNqU%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DP-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=rvL543RbhjP74ogd09Qhve0wodNAqNdGo7hcF9I%2FPw4%3D&reserved=0> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSecEvent_Drafts_issues_1%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3D3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=a8uSf2q7yE7M51pJvShbCl9pNY%2BqwcBbygU2OUzHzHg%3D&reserved=0>

/Dick
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3Dp986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY%26s%3DYnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=B7mIaLTxxcgHLsPIgYL1MggTRi6xOSCOTEQQEH4ibCs%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=CPpB%2BZsOlnji036LpWYVz0%2B0loVMM1lxxAHfuEZ76M4%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=CPpB%2BZsOlnji036LpWYVz0%2B0loVMM1lxxAHfuEZ76M4%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=CPpB%2BZsOlnji036LpWYVz0%2B0loVMM1lxxAHfuEZ76M4%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3D64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk%26s%3DoLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=asRm4EX7HNwHB6dj3%2B9gsF5ML5RekVwAf1YLX5BA5SE%3D&reserved=0>

_______________________________________________ Id-event mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DprG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ%26s%3D71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=96C9T6oxIu5bMmzUee1D8sCNXrAIymfa0NuN65a8VRM%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DprG0cnnpZdmj3VLjyxQ5dVKC3y6dLhr49mcD1NVR0AQ%26s%3D71lmYUkVWVH_HWBqDK_xmuhgzUM2-OqKqWNJ8D0lmTc%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=XuJQhPxzD6w22xxqghY0UqMKil%2F0OnzYytlIdZikV00%3D&reserved=0>

_______________________________________________ Id-event mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DvfhSbt7MosGc8EBa0PTWz8y-Ut109JH4J14kRCIbzoY%26s%3DoZbMC2L9fLzIytCmnBbmTr-5gpMEmLVSa2o_jzR-cA8%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=OSaNh7hBRjphjtzwDGZGDbkDA5sFPZ6k3GVFLT%2F%2BOXA%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMDaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DbL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ%26s%3DKktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=bb0a7dz0UbOyUXgBDGd7glonC3aCpadlWmF6IyhJWS8%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ&s=KktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY&e=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DbL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ%26s%3DKktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY%26e%3D&data=02%7C01%7Ctonynad%40microsoft.com%7C6ae42eabada54e778dba08d5462f33fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636492090945298698&sdata=to1kVk9mA92rVNu8Deo8phHQOrNbUhxG%2FO%2BtctOLd3w%3D&reserved=0>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 18 Dec 2017 18:11:48 +0000

Phil,

The current draft requires the use of multi-event SETs for extensions. Forcing profilers to choose between extensibility and interoperability is a great way to kill adoption.

From: Phil Hunt <[email-masked]>
Date: Monday, December 18, 2017 at 7:51 AM
To: Justin Richer <[email-masked]>
Cc: Mike Jones <[email-masked]>, Marius Scurtescu <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

I agree with Mike.

Phil

 -- Justin

  *   SCIM
  *   Back-Channel Logout
  *   Consent Receipts
  *   RISC

                                                       -- Mike

 — Justin

Simpler? Yes.

Marius

+1

Phil

+1
Phil

                                                       -- Mike

Phil

Phil

Phil,

                                                                -- Mike

Hi Annabelle,

                                                                -- Mike

Phil

Mike,

                                                                -- Mike

- Mark

   "events" into an array.

[Phil]

[Yaron]

 -- Justin

References:

Phil

/Dick

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
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=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ&s=KktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY&e=>

---

From: Adam Dawes <[email-masked]>
Date: Mon, 18 Dec 2017 11:38:15 -0800

+1 to Justin's points, I think Annabelle's is a clearer spec.

But what matters most for Google is closing on this matter quickly. We have
parties eagerly waiting to receive RISC data from our nearly operational
transmitter (absent a stable SET format). If we must, we can live with the
03 version but ultimately I don't see Google supporting transmitting
multiple events in a SET with the current ambiguous syntax. I think we will
just pipeline everything into single separate events. And as a receiver, we
would also prefer to receive single payload events. This makes it easier to
just relay events to the appropriate sub-systems without concern of leaking
information not relevant to that sub-system.

Perhaps in the future, we'll see use cases for multiple events, but so far
we haven't seen anything on the list that would make us build out that
support.

On Mon, Dec 18, 2017 at 7:51 AM, Phil Hunt <[email-masked]> wrote:

> Further since implementers are following the wg draft they should not have
> to continually justify themselves. Those that seek to break implementation
> must justify.
>
> The only concern i heard is easily mitigated by allowing a receiver to
> indicate desire for single event SETs. This does not break running code.
>
> Phil
>
> I disagree, Mike. My stance takes into account those that say the current
> structure works for them, and trying to understand how the new structure
> would work as well. Instead, I believe you're miscategorizing the support.
>
> advocated that the group follow this work when I brought the use case over
> here initially, but they've been developing in their own space instead. The
> 1.1 draft version of CR could be easily carried in either format, with some
> tweaks.
>
> question where any SCIM based work would go. So that's not real, and could
> go either way.
>
> You're counting all of these as support for the old format where you could
> easily count them as support for the new format -- since "it works for me"
> applies both ways.
>
>  -- Justin
>
> Justin, I believe that you are severely mischaracterizing the reality on
> the ground.  Developers building at least four use cases have stated that
> the existing specification works well for their use case:
>
>    - SCIM
>    - Back-Channel Logout
>    - Consent Receipts
>    - RISC
>
>
>
> Yes, I understand that some RISC developers have also advocated changing
> the data structure, but doing so would mean ignoring the feedback from the
> early (and not-so early) developers of all the other use cases, and also
> ignoring the RISC members who think that we’re already good to go.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Justin Richer [mailto:[email-masked] <[email-masked]>]
> *To:* Marius Scurtescu <[email-masked]> <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>
> <[email-masked]>; Richard Backman, Annabelle
> <[email-masked]> <[email-masked]>; Phil Hunt
> <[email-masked]> <[email-masked]>; Benjamin Kaduk
> <[email-masked]> <[email-masked]>; [email-masked]
> Annabelle did a better job at expressing and enabling what I was after. I
> found the parallel arrays of early drafts to be absurdly complex , and
> tried to simplify from that point into something somewhat reasonable. I had
> no intention, or inkling, that it would be abused in the way that people
> are currently talking about. And if the syntax is so easily abused, in all
> the ways that have been described on this list (such as multiple ambiguous
> objects, confusion about primary/secondary, extension vs. parallelism,
> batch payloads, etc, etc, etc), then we need to ask ourselves if the syntax
> is in fact any good or if it’s a bad design. I now believe it’s a bad
> design, and we’ve got a chance to fix it based on feedback from early
> implementers.
>
>
>
> I fully appreciate that people don’t like to change things, but I’m afraid
> that if we don’t change things now when they’re under our control, we’re
> going to be stuck in the very short future with a competing standard that
> muddies the water — or worse, a set of mutually incompatible or
> incomprehensible things that all “comply” with a meaningless spec.
>
>
>
> discussion has been a strong call for codifying that commonality, with a
> small chorus of “it works for my slice and I don’t care about anything
> else” that doesn’t want to discuss anything anymore. You have to realize,
> this isn’t people saying “hang on we just need to think harder about this”,
> without bringing concrete arguments and use cases to the table. I’ve seen
> that stall tactic applied in the IETF countless times, and if that were
> being applied here you can be sure I’d call it out. We sent the draft for
> last call. We got feedback. We ignore this at our own peril.
>
>
>
>  — Justin
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bL-BMACU7_BSuxL7lFUXZ7mW2U-CBM8gsw98jVyUhNQ&s=KktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY&e=>
>
>
>
>
>
>
>
>
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bL-BMACU7_BSuxL7lFUXZ7mW2U-
> CBM8gsw98jVyUhNQ&s=KktPZzNYa1WjpEFVCZFZUd4S9hsvxYH7l9XoODfy1pY&e=
>
>

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: Leif Johansson <[email-masked]>
Date: Mon, 18 Dec 2017 21:18:40 +0100

On 2017-12-18 20:38, Adam Dawes wrote:
> But what matters most for Google is closing on this matter quickly. We
> have parties eagerly waiting to receive RISC data from our nearly
> operational transmitter (absent a stable SET format). If we must, we can

I don't claim to speak for the folks who built https://refeds.org/sirtfi
but I'm sure their heads are exploding trying to come to grasp with this
thread.

I agree with Justin that Anabells take on this is clearer but I think
any claim that either the alt draft or the 03 version is fundamentally
unworkable is somewhat hyperbolic.

	Cheers Leif