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

[Marius Scurtescu <[e-mail]>]

comments inline...

On Sun, Dec 3, 2017 at 11:40 PM, Morteza Ansari (moransar) <
[e-mail]> 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.
>

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?


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

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


>
> 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 <[e-mail]> on behalf of Mike Jones <
> [e-mail]>
> *Date: *Friday, December 1, 2017 at 7:17 PM
> *To: *Phil Hunt <[e-mail]>, SecEvent <[e-mail]>
> *Cc: *Yaron Sheffer <[e-mail]>, Dick Hardt <
> [e-mail]>
>
> *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.
>
>
>
> We should stay with what already works and complete the SET spec in a
> timely fashion.
>
>
>
>                                                                 -- 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
>
>