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

["Richard Backman, Annabelle" <[e-mail]>]

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

--
Annabelle Richard Backman
Amazon – Identity Services


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

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 <[e-mail]<mailto:[e-mail]>> wrote:
On Sun, Dec 3, 2017 at 11:50 AM, Mike Jones <[e-mail]<mailto:[e-mail]>> 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<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.

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.

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

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:[e-mail]<mailto:[e-mail]>] On Behalf Of Phil Hunt
Sent: Sunday, December 3, 2017 11:43 AM
To: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>
Cc: SecEvent <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax - resending

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/<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=>
[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<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=>
[e-mail]<mailto:[e-mail]>

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

Is it important to syntactically ensure that only one event is in a SET? For privacy reasons, some use cases want to ensure that only one signal is in a SET. This adds some additional complexity for use cases that want to include multiple signals in a SET.

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": "[e-mail]<mailto:[e-mail]>" }, "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://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=

Discussion to be on the mail list as usual, not in the issue tracker!

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=hYk7oKhd6Dvudd1z89mcRqLy95-g9wSZBvAExLrHkyA&s=V3FW1S_3ugK2XMkci7VTeeM5qzGbkeuBCT8v7Dx3gsI&e=


_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=sPg6hxPRDRadFWO3a-bempZM9M2BTdMjnGXb1no98Os&e=>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=Gf-OVmnkr9zdUMfe5kkfbDRC-8Xsay4GmHlOu5NZQDY&s=sPg6hxPRDRadFWO3a-bempZM9M2BTdMjnGXb1no98Os&e=