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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 3 Dec 2017 19:39:02 +0200

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.

Below is some proposed syntax that ensures one event per SET, and 
enables multiple events per SET when desired.

------------------------------------------------------------------------

This specification defines the following new claims for use in the SET 
envelope:

*event*: A JSON object known as the "event payload", whose contents 
identify the type of event contained within the SET and contain 
additional information defined as part of an event type definition in a 
Profiling Specification.

This specification defines the following claims for use in event payloads:

*event_type*...
*event_id*...
*event_subject*...
*event_time*...

Both the SET envelope and event payload MAY contain additional claims, 
such as those defined in a Profiling Specification. The format and 
meaning of these claims is out of scope of this specification. 
Implementations SHOULD ignore any claims in the SET envelope or event 
payload that they do not understand.

The following is a non-normative example showing a SET envelope 
expressing a hypothetical event with two additional claims in the event 
payload:

|{ "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "iss": 
"https://transmitter.example.com", "aud": [ 
"https://receiver.example.com" ], "iat": 1458496025, "event": { 
"event_type": "https://secevent.example.com/example_event", 
"event_subject": { "identifier_type": 
"urn:ietf:params:secevent:subject:email", "email": "[email-masked]" }, 
"event_time": 1458492425, "claim_1": "foo", "claim_2": "bar" } } |

The payload in this example contains the following:

  * An "event_type" claim whose value is the URI identifying the
    hypothetical event type.
  * An "event_subject" claim whose value identifies a subject via email
    address.
  * An "event_time" claim whose value is the time at which the event
    occured.
  * Two claims "claim_1" and "claim_2" that are defined by the
    hypothetical event type's Profiling Specification.

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!

---

From: Phil Hunt <[email-masked]>
Date: Sun, 3 Dec 2017 11:42:32 -0800

Thanks Yaron,

As posted on the other thread, below is the historical discussion that occurred just before adoption and then again when I re-raised the issue after 00 of the WG draft was posted.

As many already know, I am *not* in favour of adoption.
The WG Draft presentation at IETF100 went through the issue highlighting a number of concerns with the new format as well as providing key reasons for why multiple payloads are needed and are useful. [0]
During the Friday informal session in Singapore, there was substantial discussion on the need to support multiple aspect SETs in streams. Sooner or later, almost all of us face using events with multiple aspects.
The proposed new singular event format does not actually define a single event system. It actually defines a more complex system whereby special parsing instructions (such as “related event” create complex logic to handle multiple event claim sets (payloads). The new text further distinguishes what is an extension vs. what is an event. In this case, while there might be some benefit, the added parsing and structure complexity (e.g. what extension goes with what event) just causes even more confusion.
I sympathize with the concern that it is not clear what a receiver should do in all cases. However that was *never* the intent. The intent when I proposed this work, was for a SET to convey a shared signal that allow independent decision making and action across and between domains. I support continued discussion on how to best advice implementers about their freedom to decide and how this supports inter-operability and implementation.

Best,

Phil

References: 
[0] - https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-events/
[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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=neJGeQPZSfA3oeojIh38TIB8VcV5v8Ifu2vFjBqg3jU&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=fkdbarjmqhoEIPbWedO61BrwZ0xpzuyXnfUt2w_5E4Y&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=xZd0OIIZkyiaVus87BBGUt9vZE4PRNx1bFFG6I02NzQ&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=VXjuoVdBLSd5CN9Q4U0W1NySJVRxndur2m0QuVpZF9o&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=cU1QSoU-yreJxd6mXEOWfFoglhYXofYgMmbsZT-uPOo&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=jhHFza3nvU0GT13rne72WVnMmD-8JPZbrgXTit8UlEw&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=_BboqL92NXhF-DXxDk1UhEOPYeNZTmP4TQ6x-gjb7AQ&e=>

On Dec 10, 2016, Yaron while reviewing the ID draft-hunt-idevent-token-07 [1]:
>   * Why "events" and not "event"? We don't really have support for
>     multiple events. Certainly not if they are all of the same type.
>     The current text is confusing: "events" is not the same as "a
>     primary event and its extensions”.
> [MIKE] Reflects your earlier comment re: primary vs. extensions.  "events” is
> plural to reflect the fact that the attribute is multi-valued. I agree,
> given that only one primary event can be included, the naming is misleading.

From later in the thread [2]:
>>>>  * 2: "first value" is meaningless. JSON objects are unordered (4th
>>>>    paragraph of RFC 7159). If order /is/ important, we could make
>>>>    "events" into an array.
>>> [Phil] Yup.   How would the group like to fix this?  We could make “events”
>>> singular and have an extensions attribute to hold the extensions.  Or we
>>> could go to a more complex JSON structure (not personally a fan).
>> 
>> [Yaron] I'm personally fine with a main "event" object and an "extensions" attribute. I can even live with "event" being called "events", per Mike's proposal. But the structure needs to make sense as a JSON object if we want it implemented.
> 
> [PH] Thread: Should the primary event be a separate attribute?
> 
> We had this broken out before. If there is sufficient desire to break it out again, I have no objection.

Then following WG adoption, I re-reraised the issue after discussion with Annabelle draft-secevent-token-00 [3]: 
> On this topic, following Yaron’s comments Mike Jones raised some points that there should be no distinction between primary events and extensions (https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=HJVBSXHaT94B04XNIpOZZIqXuMl7ZfqIlr_mMGDDsBU&e=>).  Summarizing:
> * Processors will run through all of them regardless. It is not necessarily helpful to understand which is a primary vs. extension
> * Let’s drop distinction between primary vs. extension. You can simply express one or more sets of event attributes in a single JWT
> 
> My proposal is to drop this terminology in the text and keep the attribute multi-valued. The purpose of the attribute is to inform the reader what events are being asserted and what additional data may be present. It is up to the reader to ultimately infer meaning when one or more URIs are present.  Further, when multiple URIs are present it must still to make a combined statement about a single state change about a subject. It must not be used to convey multiple distinct (e.g. transactions) events about a subject.
> 
> Assuming everyone agrees, I will plan to remove these distinctions in the next update with some new text. Please comment if you have concerns.

To which Mike Jones responded [4]
> I believe we already had consensus to drop the primary/secondary distinction, which we intentionally did before adoption of the working group draft.  I believe any such distinction will both be unhelpful and result in syntactic complexity.  Please let’s finish stamping out the notion that any of the events in a SET are somehow different than the others.
> 

William Denniss wrote [5]: 
> I agree with your proposal.
> 
> They're all just events. Up to implementors to define & categorize their events how they like.

Marius also agreed (he may have switched positions now) [6]:
> I also think it makes sense to remove the primary/secondary distinction.
> 
> Marius

Justin also agreed (and may have switched positions) [7]
> +1, drop "primary" and keep it an object
> 
>  -- Justin
> 

Phil

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

> On Dec 3, 2017, at 9:39 AM, Yaron Sheffer <[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.
> 
> Below is some proposed syntax that ensures one event per SET, and enables multiple events per SET when desired.
> 
> This specification defines the following new claims for use in the SET envelope:
> 
> *event*: A JSON object known as the "event payload", whose contents identify the type of event contained within the SET and contain additional information defined as part of an event type definition in a Profiling Specification.
> 
> Both the SET envelope and event payload MAY contain additional claims, such as those defined in a Profiling Specification. The format and meaning of these claims is out of scope of this specification. Implementations SHOULD ignore any claims in the SET envelope or event payload that they do not understand.
> 
> The following is a non-normative example showing a SET envelope expressing a hypothetical event with two additional claims in the event payload:
> 
> |{ "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "iss": "https://transmitter.example.com", "aud": [ "https://receiver.example.com" ], "iat": 1458496025, "event": { "event_type": "https://secevent.example.com/example_event", "event_subject": { "identifier_type": "urn:ietf:params:secevent:subject:email", "email": "[email-masked]" }, "event_time": 1458492425, "claim_1": "foo", "claim_2": "bar" } } |
> 
> We will track results here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_1&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=hYk7oKhd6Dvudd1z89mcRqLy95-g9wSZBvAExLrHkyA&s=H-j2zFsK_5tuWTEcOcEKcrMwE-kM7qQs8pR96JWl880&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=hYk7oKhd6Dvudd1z89mcRqLy95-g9wSZBvAExLrHkyA&s=V3FW1S_3ugK2XMkci7VTeeM5qzGbkeuBCT8v7Dx3gsI&e=

---

From: Mike Jones <[email-masked]>
Date: Sun, 3 Dec 2017 19:50:15 +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.  Any other formulation that creates a “single event syntax” would also be a breaking change.

The working draft already meets the needs of multiple use cases and is in production use, for instance by all implementations of OpenID Connect Backchannel Logout.  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: Sunday, December 3, 2017 11:43 AM
To: Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax - resending

Thanks Yaron,

  *   The WG Draft presentation at IETF100 went through the issue highlighting a number of concerns with the new format as well as providing key reasons for why multiple payloads are needed and are useful. [0]
  *   During the Friday informal session in Singapore, there was substantial discussion on the need to support multiple aspect SETs in streams. Sooner or later, almost all of us face using events with multiple aspects.
  *   The proposed new singular event format does not actually define a single event system. It actually defines a more complex system whereby special parsing instructions (such as “related event” create complex logic to handle multiple event claim sets (payloads). The new text further distinguishes what is an extension vs. what is an event. In this case, while there might be some benefit, the added parsing and structure complexity (e.g. what extension goes with what event) just causes even more confusion.
I sympathize with the concern that it is not clear what a receiver should do in all cases. However that was *never* the intent. The intent when I proposed this work, was for a SET to convey a shared signal that allow independent decision making and action across and between domains. I support continued discussion on how to best advice implementers about their freedom to decide and how this supports inter-operability and implementation.

Best,

Phil

References:
[0] - https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-events/
[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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=neJGeQPZSfA3oeojIh38TIB8VcV5v8Ifu2vFjBqg3jU&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=fkdbarjmqhoEIPbWedO61BrwZ0xpzuyXnfUt2w_5E4Y&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=xZd0OIIZkyiaVus87BBGUt9vZE4PRNx1bFFG6I02NzQ&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=VXjuoVdBLSd5CN9Q4U0W1NySJVRxndur2m0QuVpZF9o&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=cU1QSoU-yreJxd6mXEOWfFoglhYXofYgMmbsZT-uPOo&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=jhHFza3nvU0GT13rne72WVnMmD-8JPZbrgXTit8UlEw&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=_BboqL92NXhF-DXxDk1UhEOPYeNZTmP4TQ6x-gjb7AQ&e=>

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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=HJVBSXHaT94B04XNIpOZZIqXuMl7ZfqIlr_mMGDDsBU&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

Phil

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

On Dec 3, 2017, at 9:39 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

*event_type*...
*event_id*...
*event_subject*...
*event_time*...

|{ "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "iss": "https://transmitter.example.com", "aud": [ "https://receiver.example.com" ], "iat": 1458496025, "event": { "event_type": "https://secevent.example.com/example_event", "event_subject": { "identifier_type": "urn:ietf:params:secevent:subject:email", "email": "[email-masked]<mailto:[email-masked]>" }, "event_time": 1458492425, "claim_1": "foo", "claim_2": "bar" } } |

_______________________________________________
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=hYk7oKhd6Dvudd1z89mcRqLy95-g9wSZBvAExLrHkyA&s=V3FW1S_3ugK2XMkci7VTeeM5qzGbkeuBCT8v7Dx3gsI&e=

---

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

> …it is not clear what a receiver should do in all cases.

Once again, this is not about telling the receiver what to do. It’s about making sure the receiver knows what the SET means at a syntactic level. It’s like knowing all the words in a sentence without having the rules of grammar to tell you which one is the subject and which one is the verb.

> The intent when I proposed this work, was for a SET to convey a shared signal that allow independent decision making and action across and between domains

The current SET draft does not achieve this; the signal is ambiguous, as there is nothing in the SET that indicates how any two entries in the “events” claim relate to one another.

For example, suppose you receive a SET with the following “events” claim:

"events": {
  "A": { ... },
  "B": { ... },
  "C": { ... }
}

What does this represent?

  1.  Three distinct related events.
  2.  An event A which is extended by B and C.
  3.  An event A which is extended by B, and a separate, related event C.
  4.  An event A and a separate, related event C which is extended by B.
  5.  Three different representations of the same event, with B and C being deprecated names A.
  6.  Three distinct unrelated events.

…that’s not even all the possibilities. It’s not even deterministic; if A and B are distinct events and C could extend either one of them, even a system that understands each event type doesn’t know how to interpret it. Note that all of these are based on things attendees of the WG session said they are planning to with SETs.

This ambiguity will force recipients to expose more data than necessary to individual event processing systems, as only the end application logic could possibly know whether it needs to care about A and B, or just A, or all three, etc.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Sunday, December 3, 2017 at 11:43 AM
To: Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax - resending

Thanks Yaron,

Best,

Phil

References:

Marius

Phil

*event_type*...
*event_id*...
*event_subject*...
*event_time*...

---

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

Comments inline...

On Sun, Dec 3, 2017 at 11:42 AM, Phil Hunt <[email-masked]> wrote:

> Thanks Yaron,
>
> As posted on the other thread, below is the historical discussion that
> occurred just before adoption and then again when I re-raised the issue
> after 00 of the WG draft was posted.
>
>    - The WG Draft presentation at IETF100 went through the issue
>    highlighting a number of concerns with the new format as well as providing
>    key reasons for why multiple payloads are needed and are useful. [0]
>
> For sure, and the new syntax allows that in a much cleaner and flexible
way.

I should add that Tony Nadalin added a Microsoft requirement for batching
multiple events, which the current "events" syntax does not allow and which
the new "event" syntax does allow.

>    - During the Friday informal session in Singapore, there was
>    substantial discussion on the need to support multiple aspect SETs in
>    streams. Sooner or later, almost all of us face using events with multiple
>    aspects.
>
>
Right, and again the proposed "event" syntax supports that in a much
cleaner way.

>    - The proposed new singular event format does not actually define a
>    single event system. It actually defines a more complex system whereby
>    special parsing instructions (such as “related event” create complex logic
>    to handle multiple event claim sets (payloads). The new text further
>    distinguishes what is an extension vs. what is an event. In this case,
>    while there might be some benefit, the added parsing and structure
>    complexity (e.g. what extension goes with what event) just causes even more
>    confusion.
>
> Sure, we can talk about the extension language. That's no reason to refuse
the suggestion wholesale.

> I sympathize with the concern that it is not clear what a receiver should
> do in all cases. However that was *never* the intent. The intent when I
> proposed this work, was for a SET to convey a shared signal that allow
> independent decision making and action across and between domains. I
> support continued discussion on how to best advice implementers about their
> freedom to decide and how this supports inter-operability and
> implementation.
>

The "event" syntax proposal is coming from implementers.

> [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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=neJGeQPZSfA3oeojIh38TIB8VcV5v8Ifu2vFjBqg3jU&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=fkdbarjmqhoEIPbWedO61BrwZ0xpzuyXnfUt2w_5E4Y&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=xZd0OIIZkyiaVus87BBGUt9vZE4PRNx1bFFG6I02NzQ&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=VXjuoVdBLSd5CN9Q4U0W1NySJVRxndur2m0QuVpZF9o&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=cU1QSoU-yreJxd6mXEOWfFoglhYXofYgMmbsZT-uPOo&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=jhHFza3nvU0GT13rne72WVnMmD-8JPZbrgXTit8UlEw&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=_BboqL92NXhF-DXxDk1UhEOPYeNZTmP4TQ6x-gjb7AQ&e=>
>
>
> *[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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4m1zCPItOQtiY8pa8xv44LEb7z5M3scM4judNPzmu28&s=HJVBSXHaT94B04XNIpOZZIqXuMl7ZfqIlr_mMGDDsBU&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.
>
>
> www.independentid.com
> [email-masked]
> 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.
>
> identify the type of event contained within the SET and contain additional
> information defined as part of an event type definition in a Profiling
> Specification.
>
> such as those defined in a Profiling Specification. The format and meaning
> of these claims is out of scope of this specification. Implementations
> SHOULD ignore any claims in the SET envelope or event payload that they do
> not understand.
>
> The following is a non-normative example showing a SET envelope expressing
> a hypothetical event with two additional claims in the event payload:
>
> |{ "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "iss": "
> https://transmitter.example.com", "aud": [ "https://receiver.example.com"
> ], "iat": 1458496025, "event": { "event_type": "
> https://secevent.example.com/example_event", "event_subject": {
> "identifier_type": "urn:ietf:params:secevent:subject:email", "email": "
> [email-masked]" }, "event_time": 1458492425, "claim_1": "foo",
> "claim_2": "bar" } } |
>
> We will track results here: https://urldefense.proofpoint.
> com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_
> issues_1&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=hYk7oKhd6Dvudd1z89mcRqLy95-
> g9wSZBvAExLrHkyA&s=H-j2zFsK_5tuWTEcOcEKcrMwE-kM7qQs8pR96JWl880&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=hYk7oKhd6Dvudd1z89mcRqLy95-
> g9wSZBvAExLrHkyA&s=V3FW1S_3ugK2XMkci7VTeeM5qzGbkeuBCT8v7Dx3gsI&e=
>
>
>
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

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

On Sun, Dec 3, 2017 at 11:50 AM, Mike Jones <[email-masked]>
wrote:

> I am strongly opposed to making a change to reintroduce a distinction
> between primary and secondary events.
>

Sure, this proposal has nothing to do with that.

>   This topic has been heavily discussed in the working group and people
> very clearly came down on the side of having no such distinction.
>

Right, that discussion was in a different context. It does not apply here.

>   Annabelle’s draft needlessly reintroduces this distinction, with the
> result being a breaking change and making the structure more complicated,
> not less.
>

What breaking changes? This is real feedback from implemeters and we are
shutting them down because of breaking changes?

>   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.  Any
> other formulation that creates a “single event syntax” would also be a
> breaking change.
>

That nested structure makes semantics very clear, I don't see any problems
with it.

>
>
> The working draft already meets the needs of multiple use cases and is in
> production use, for instance by all implementations of OpenID Connect
> Backchannel Logout.
>

Mike, you should open up to feedback from other profiles and use cases than
back-channel logout. This proposal is the result of other use cases running
into issues with the current draft.

>   There are not sufficient reasons to reintroduce complexity that was
> previously soundly rejected and to make wholesale design changes after
> working group last call.
>
>
>

If it works, why do we have this discussion to begin with? Works for
back-channel logout does not mean it works for everyone.

>
>
>                                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] * On Behalf Of *Phil
> Hunt
> *Sent:* Sunday, December 3, 2017 11:43 AM
> *To:* Yaron Sheffer <[email-masked]>
> *Cc:* SecEvent <[email-masked]>
> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax - resending
>
>
>
> Thanks Yaron,
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 7 Dec 2017 13:13:47 -0800

I struggle to understand how the related event structures are simple. Only simple events are simple. It merely kicks the can down the road. Everyone who needs multi-aspects will have more, not less complexity. 
 
The alternate also breaks apart extensions yet there is no clear differentiation for extension vs aspect. 
 
Nor should there be. 

I believe what is in common agreement is that parties negotiating individual streams should be configurable as to single or multi-aspect and potentially what combinations to expect on a stream. 

As Mike said contextual definition is similar practice with jwt and so it is true for SET. I still believe the current draft does the job the best. 

Phil

> On Dec 7, 2017, at 12:27 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Sun, Dec 3, 2017 at 11:50 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.
>> 
> 
> What breaking changes? This is real feedback from implemeters and we are shutting them down because of breaking changes?
> 
>  
>>   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.  Any other formulation that creates a “single event syntax” would also be a breaking change.
>> 
> 
> That nested structure makes semantics very clear, I don't see any problems with it.
> 
>  
>>  
>> 
>> The working draft already meets the needs of multiple use cases and is in production use, for instance by all implementations of OpenID Connect Backchannel Logout.
>> 
> 
> Mike, you should open up to feedback from other profiles and use cases than back-channel logout. This proposal is the result of other use cases running into issues with the current draft.
> 
>  
>>   There are not sufficient reasons to reintroduce complexity that was previously soundly rejected and to make wholesale design changes after working group last call.
>> 
>>  
>> 
> If it works, why do we have this discussion to begin with? Works for back-channel logout does not mean it works for everyone.
> 
>  
>>  
>> 
>>                                                                 -- Mike
>> 
>>  
>> 
>> 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:
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=sPg6hxPRDRadFWO3a-bempZM9M2BTdMjnGXb1no98Os&e=

---

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

> The alternate also breaks apart extensions yet there is no clear differentiation for extension vs aspect.

Phil, that is one of the interop-breaking issues with the current draft. If there is no difference between an extension and an aspect of an event, then multi-part SETs cannot be decomposed without extensive knowledge of the event types, profiles, and use cases involved.

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

Nor should there be.

Phil

On Dec 7, 2017, at 12:27 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Dec 3, 2017 at 11:50 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I am strongly opposed to making a change to reintroduce a distinction between primary and secondary events.

  See the deeply nested “related events” structure in https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D03-23section-2D3&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=lXEE2izbidLyy_YFsrlIgC4i9dkgcISUgjBduHSrSUc&e=> to understand some of the of the additional complexity being proposed.  Any other formulation that creates a “single event syntax” would also be a breaking change.

                                                                -- Mike

From: Id-event [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Hunt
Sent: Sunday, December 3, 2017 11:43 AM
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Cc: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax - resending

Thanks Yaron,

Best,

Phil

References:
[0] - https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-events/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_100_materials_slides-2D100-2Dsecevent-2Dset-2Devents_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=kYhuURa8K7LZttt6wXiZnaScAI86-ir3HaKp8ZvhehY&e=>

Marius

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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=eM9ZOw9hisQZWN-mv1FshkA1ZWhRgD5SpYC_myt2jCI&e=>
[email-masked]<mailto:[email-masked]>

*event_type*...
*event_id*...
*event_subject*...
*event_time*...

_______________________________________________
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=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=sPg6hxPRDRadFWO3a-bempZM9M2BTdMjnGXb1no98Os&e=>