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

[Marius Scurtescu <[e-mail]>]

On Fri, Dec 1, 2017 at 7:12 PM, Mike Jones <[e-mail]>
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 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.
>

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

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


>
>                                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Phil Hunt
> *Sent:* Friday, December 1, 2017 10:36 AM
> *To:* SecEvent <[e-mail]>
> *Cc:* Yaron Sheffer <[e-mail]>; Dick Hardt <
> [e-mail]>
> *Subject:* Re: [Id-event] Consensus :: Single Event Syntax
>
>
>
> For historical purposes, this has been discussed twice before (once at the
> request of Annabelle).
>
>
>
> I think it would be helpful, why, after WGLC, this issue is being brought
> forward yet again. Dick has stated that Annabelle’s concern that she finds
> it difficult to implement is sufficient.  Yet, I’m not sure we are
> entertaining a new concern here. No new information was provided.
>
>
>
> I note that at the time, the chairs did not feel there was a lack of
> consensus in order to call for one in the past.
>
>
>
> On some of these matters, the choice may be arbitrary, and that is why I
> think keeping track of prior discussion is important so that we can clearly
> move forward and not repeat discussion of the past further confusing
> consensus.
>
>
>
> While I advocated for singular events as a possibility in the past, I now
> have much more stronger technical reasons for the WG draft design, which
> have strengthened rather than weakened in the past week. I will share these
> later, after the minutes have been published.
>
>
>
> On Dec 10, 2016, Yaron while reviewing the ID draft-hunt-idevent-token-07
> [1]:
>
>   * Why "events" and not "event"? We don't really have support for
>
>     multiple events. Certainly not if they are all of the same type.
>
>     The current text is confusing: "events" is not the same as "a
>
>     primary event and its extensions”.
>
> [MIKE] Reflects your earlier comment re: primary vs. extensions.  "events” is
>
> plural to reflect the fact that the attribute is multi-valued. I agree,
>
> given that only one primary event can be included, the naming is misleading.
>
>
>
> From later in the thread [2]:
>
>  * 2: "first value" is meaningless. JSON objects are unordered (4th
>    paragraph of RFC 7159). If order /is/ important, we could make
>    "events" into an array.
>
> *[Phil] *Yup.   How would the group like to fix this?  We could make
> “events”
> singular and have an extensions attribute to hold the extensions.  Or we
> could go to a more complex JSON structure (not personally a fan).
>
>
> *[Yaron]* I'm personally fine with a main "event" object and an
> "extensions" attribute. I can even live with "event" being called "events",
> per Mike's proposal. But the structure needs to make sense as a JSON object
> if we want it implemented.
>
>
>
> [PH] Thread: Should the primary event be a separate attribute?
>
>
>
> We had this broken out before. If there is sufficient desire to break it
> out again, I have no objection.
>
>
>
> Then following WG adoption, I re-reraised the issue after discussion with
> Annabelle draft-secevent-token-00 [3]:
>
> On this topic, following Yaron’s comments Mike Jones raised some points
> that there should be no distinction between primary events and extensions (
> https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U).
>  Summarizing:
>
> * Processors will run through all of them regardless. It is not
> necessarily helpful to understand which is a primary vs. extension
>
> * Let’s drop distinction between primary vs. extension. You can simply
> express one or more sets of event attributes in a single JWT
>
>
>
> My proposal is to drop this terminology in the text and keep the attribute
> multi-valued. The purpose of the attribute is to inform the reader what
> events are being asserted and what additional data may be present. It is up
> to the reader to ultimately infer meaning when one or more URIs are
> present.  Further, when multiple URIs are present it must still to make a
> combined statement about a single state change about a subject. It must not
> be used to convey multiple distinct (e.g. transactions) events about a
> subject.
>
>
>
> Assuming everyone agrees, I will plan to remove these distinctions in the
> next update with some new text. Please comment if you have concerns.
>
>
>
> To which Mike Jones responded [4]
>
> I believe we already had consensus to drop the primary/secondary
> distinction, which we intentionally did before adoption of the working
> group draft.  I believe any such distinction will both be unhelpful and
> result in syntactic complexity.  Please let’s finish stamping out the
> notion that any of the events in a SET are somehow different than the
> others.
>
>
>
> William Denniss wrote [5]:
>
> I agree with your proposal.
>
>
>
> They're all just events. Up to implementors to define & categorize their
> events how they like.
>
>
>
> Marius also agreed (he may have switched positions now) [6]:
>
> I also think it makes sense to remove the primary/secondary distinction.
>
>
> Marius
>
>
>
> Justin also agreed (and may have switched positions) [7]
>
> +1, drop "primary" and keep it an object
>
>  -- Justin
>
>
>
> References:
>
> [1] - https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html
>
> [2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html
>
> [3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html
>
> [4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html
>
> [5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html
>
> [6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html
>
> [7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services Architect
>
> @independentid
>
> www.independentid.com
>
> [e-mail]
>
>
>
> On Dec 1, 2017, at 8:50 AM, Dick Hardt <[e-mail]> wrote:
>
>
>
> Is it important to syntactically ensure that only one event is in a SET?
> For privacy reasons, some use cases want to ensure that only one signal is
> in a SET.
> This adds some additional complexity for use cases that want to include
> multiple signals in a SET.
>
> See https://tools.ietf.org/html/draft-backman-secevent-token-02
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=P-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM&e=> for
> an proposed syntax that ensures one event per SET, and enables multiple
> events per SET when desired
>
>
>
> We will track results here: https://github.com/IETF-
> SecEvent/Drafts/issues/1
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw&e=>
>
>
>
> Discussion to be on the mail list as usual, not in the issue tracker!
>
>
>
> /Dick
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=YnAKATJz3qVYniVaDUIMtQb9L-
> vMocgsYARzV6axzq4&e=
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>