Subject: Re: [Id-event] Doc shepherd review

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 1 Mar 2018 19:32:40 +0000

“…whether and how multiple members of the JSON object that is the value of the events claim are used for SETs conforming to those profiles.”

The “whether and how” construction condenses this statement, but I think it makes it harder to understand. How about:

“…whether the value of the events claim may contain multiple members, and the significance of this case if any for SETs conforming to those profiles.”

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Mike Jones <[email-masked]>
Date: Wednesday, February 28, 2018 at 5:16 PM
To: Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>, Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Doc shepherd review

Yaron, the edits in https://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ec address your review comments.

                                                                -- Mike

From: Id-event <[email-masked]> On Behalf Of Mike Jones
Sent: Wednesday, February 28, 2018 3:46 PM
To: Phil Hunt <[email-masked]>; Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] Doc shepherd review

Phil is correct.  The “txn” claim is intentionally usable with any JWT and not specific to SETs. This just happens to be the spec to define it and add it to the IANA JWT Claims registry.

Yaron, I plan to tweak your language “SETs serve to exchange information about identity-related events” because the charter is about security events, only some of which are identity events.  We shouldn’t narrow the scope of applicability beyond what’s intended.

                                                                -- Mike

From: Id-event <[email-masked]<mailto:[email-masked]>> On Behalf Of Phil Hunt
Sent: Wednesday, February 28, 2018 3:35 PM
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Cc: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Doc shepherd review

Yaron,

Thanks for the comments, will add to the next update.

Mike has added some other minor editorial fixes for consistency with JWT etc which I believe the group discussed.

A couple questions inline…

Phil

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

On Feb 28, 2018, at 3:27 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I will be document shepherd for the SET spec. As such, I just reread it once again, and I think it is in very good shape. Here are my (mostly editorial) comments.

- Abstract: please add the following to clarify, e.g. after the first sentence: SETs serve to exchange information about identity-related events.
- A security subject MAY be permanent - this is descriptive text, please change "MAY" to "may".
- "SETs have no capability for error signaling to ensure the validation of a received SET" - SETs are a format, so it is a higher level protocol that may or may not signal errors. I suggest to remove this sentence.
- "has occurred about a Subject." Should this be "has occurred to a Subject”?

I will re-read. I think what the spec is trying to say is to or related to. Meaning the even is directly related to the subject but not necessarily to the subject.  I will review and suggest some text.

- 2.2: for readability, please include the full names of the claims ("Issuer", "JWT ID" etc.).
- IMO the distinction between JWTs and SETs with regard to the need to use "exp" is not convincing. I suggest we refer to Sec. 4.5 for a better rationale why we make this claim NOT RECOMMENDED rather than OPTIONAL as in RFC 7519.
- txn: this paragraph should speak about SETs rather than JWTs.

I will defer to Mike, but I believe he suggested to have this registered for general JWT use.

- "to provide integrity, confidentiality, and issuer validation", should be "issuer authenticity".
- "Whether and how multiple "events" values are used": the reader who has not been following our discussions may not understand what this means, maybe we should say in parentheses, (i.e. multiple members in the "events" JSON object).
- "MUST support TLS 1.2" - add "or a higher version".
- 4.5: intentionally - I think we mean "maliciously".
- 6.1.1: "Security Event URI" - this description is incorrect, should probably be "Security Event information" or something similarly vague.
- RFC 7617 - unused ref. Similarly saml-core.

Thanks,
    Yaron

_______________________________________________
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=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=F-QmvDFTApiQ6Wjga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=nLwDZhuM4B_ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3YUo&e=

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Mar 2018 14:12:22 -0800

Annabelle,

Apologies, but “significance of this case” does not seem to add actionable information or aid in understanding. Also "if any” seems unclear.

Can you propose something else (with before and after text)?

Thanks,

Phil

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

> On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Mike Jones <[email-masked] <mailto:[email-masked]>>
> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
> Cc: SecEvent <[email-masked] <mailto:[email-masked]>>, Phil Hunt <[email-masked] <mailto:[email-masked]>>
> Yaron, the edits in  <>https://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ec <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_11_commits_e27a2696f707107ec85a994844c6cbe2283356ec&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=gx78QYM_4ZY95MAl9d6bQsr275ioYed707aoGb7wGdc&e=> address your review comments.
>  
>                                                                 -- Mike
>  
> From: Id-event <[email-masked] <mailto:[email-masked]>> On Behalf Of Mike Jones
> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
> Cc: SecEvent <[email-masked] <mailto:[email-masked]>>
> From: Id-event <[email-masked] <mailto:[email-masked]>> On Behalf Of Phil Hunt
> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
> Cc: 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=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=SFMqLvSwmX-MX0r8Qanj0k2jYVPrwBSSUsJhx03KyPU&e=>
> [email-masked] <mailto:[email-masked]>
>  
> 
>> On Feb 28, 2018, at 3:27 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=F-QmvDFTApiQ6Wjga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=nLwDZhuM4B_ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3YUo&e <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=F-QmvDFTApiQ6Wjga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=nLwDZhuM4B_ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3YUo&e>=
> 
>  
> [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=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=Za82EBppu_mOdrdvDQwJumc9CpxIeunBFdeuGQpSW4A&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=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=Za82EBppu_mOdrdvDQwJumc9CpxIeunBFdeuGQpSW4A&e=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 2 Mar 2018 22:30:09 +0000

How about:

Change this line<https://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ec#diff-dcb2f7864ea1359367200592bfec3e21R737> to:

Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the events claim may contain multiple members, and any additional processing instructions required when multiple members are present in SETs conforming to that profile.

I think this is a clearer, more precise description of what it is profile authors need to consider. It also fits better with the subsequent examples, which present different rules for processing multi-event SETs.

From: Phil Hunt <[email-masked]>
Date: Friday, March 2, 2018 at 2:12 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Mike Jones <[email-masked]>, Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] Doc shepherd review

Annabelle,

Thanks,

Phil

On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 28, 2018 at 5:16 PM
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Cc: SecEvent <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Doc shepherd review

Yaron, the edits in https://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ec<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_11_commits_e27a2696f707107ec85a994844c6cbe2283356ec&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=gx78QYM_4ZY95MAl9d6bQsr275ioYed707aoGb7wGdc&e=> address your review comments.

                                                                -- Mike

From: Id-event <[email-masked]<mailto:[email-masked]>> On Behalf Of Mike Jones
Sent: Wednesday, February 28, 2018 3:46 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Cc: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Doc shepherd review

                                                                -- Mike

Yaron,

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=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=SFMqLvSwmX-MX0r8Qanj0k2jYVPrwBSSUsJhx03KyPU&e=>
[email-masked]<mailto:[email-masked]>

Hi,

Thanks,
    Yaron

_______________________________________________
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=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=Za82EBppu_mOdrdvDQwJumc9CpxIeunBFdeuGQpSW4A&e=

---

From: Mike Jones <[email-masked]>
Date: Fri, 2 Mar 2018 22:39:15 +0000

That’s closer.  I find the word “additional” somewhat prejudicial, however.  How about this more neutral language?

Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the “events” claim may contain multiple members, and what processing instructions are employed in the single- and multiple-valued cases for SETs conforming to that profile.

                                                                -- Mike

From: Richard Backman, Annabelle <[email-masked]>
Sent: Friday, March 2, 2018 2:30 PM
To: Phil Hunt <[email-masked]>
Cc: Mike Jones <[email-masked]>; Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Doc shepherd review

How about:

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 2, 2018 at 2:12 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Doc shepherd review

Annabelle,

Thanks,

Phil

                                                                -- Mike

                                                                -- Mike

Yaron,

Phil

Hi,

Thanks,
    Yaron

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 2 Mar 2018 22:53:42 +0000

I like the addition of “single- and”. +1

I think “additional” is fair, given that they would be additional instructions on top of the processing instructions defined within SET, but I’m fine with taking it out and going with your text.

From: Id-event <[email-masked]> on behalf of Mike Jones <[email-masked]>
Date: Friday, March 2, 2018 at 2:40 PM
To: "Richard Backman, Annabelle" <[email-masked]>, Phil Hunt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] Doc shepherd review

                                                                -- Mike

How about:

Annabelle,

Thanks,

Phil

                                                                -- Mike

                                                                -- Mike

Yaron,

Phil

Hi,

Thanks,
    Yaron

---

From: Justin Richer <[email-masked]>
Date: Sat, 3 Mar 2018 07:15:27 -0500

I'd prefer to keep "additional" here as well.

On 3/2/2018 5:53 PM, Richard Backman, Annabelle wrote:
> I think “additional” is fair, given that they would be additional 
> instructions on top of the processing instructions defined within SET, 
> but I’m fine with taking it out and going with your text.
>
> -- 
>
> *From: *Id-event <[email-masked]> on behalf of Mike Jones 
> <[email-masked]>
> *Date: *Friday, March 2, 2018 at 2:40 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>, Phil Hunt 
> <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
> *Subject: *Re: [Id-event] Doc shepherd review
>
> That’s closer. I find the word “additional” somewhat prejudicial, 
> however. How about this more neutral language?
>
> Among the syntax and semantics of SETs that a profiling specification 
> may define is whether the value of the “events” claim may contain 
> multiple members, and *what* processing instructions are *employed in 
> the single- and multiple-valued cases* for SETs conforming to that 
> profile.
>
> -- Mike
>
> *From:* Richard Backman, Annabelle <[email-masked]>
> *Sent:* Friday, March 2, 2018 2:30 PM
> *To:* Phil Hunt <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Yaron Sheffer 
> <[email-masked]>; SecEvent <[email-masked]>
> *Subject:* Re: [Id-event] Doc shepherd review
>
> How about:
>
> Change this line 
> <https://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ec#diff-dcb2f7864ea1359367200592bfec3e21R737> 
> to:
>
> Among the syntax and semantics of SETs that *a profiling specification 
> may* define is whether *the value of the events claim may contain 
> multiple members, and any additional processing instructions required 
> when multiple members are present in* SETs conforming to *that profile*.
>
> I think this is a clearer, more precise description of what it is 
> profile authors need to consider. It also fits better with the 
> subsequent examples, which present different rules for processing 
> multi-event SETs.
>
> -- 
>
> *From: *Phil Hunt <[email-masked] <mailto:[email-masked]>>
> *Date: *Friday, March 2, 2018 at 2:12 PM
> *To: *"Richard Backman, Annabelle" <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *Mike Jones <[email-masked] 
> <mailto:[email-masked]>>, Yaron Sheffer 
> <[email-masked] <mailto:[email-masked]>>, SecEvent 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [Id-event] Doc shepherd review
>
> Annabelle,
>
> Apologies, but “significance of this case” does not seem to add 
> actionable information or aid in understanding. Also "if any” seems 
> unclear.
>
> www.independentid.com <http://www.independentid.com>
>
>     On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     “…whether and how multiple members of the JSON object that is the
>     value of the events claim are used for SETs conforming to those
>     profiles.”
>
>     The “whether and how” construction condenses this statement, but I
>     think it makes it harder to understand. How about:
>
>     “…whether the value of the events claim may contain multiple
>     members, and the significance of this case if any for SETs
>     conforming to those profiles.”
>
>     -- 
>
>     *From:*Id-event <[email-masked]
>     <mailto:[email-masked]>> on behalf of Mike Jones
>     <[email-masked] <mailto:[email-masked]>>
>     *Date:*Wednesday, February 28, 2018 at 5:16 PM
>     *To:*Yaron Sheffer <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:*SecEvent <[email-masked] <mailto:[email-masked]>>, Phil
>     Hunt <[email-masked] <mailto:[email-masked]>>
>     *Subject:*Re: [Id-event] Doc shepherd review
>
>     Yaron, the edits
>     inhttps://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ec<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_independentid_Identity-2DEvents_pull_11_commits_e27a2696f707107ec85a994844c6cbe2283356ec&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=gx78QYM_4ZY95MAl9d6bQsr275ioYed707aoGb7wGdc&e=>address
>     your review comments.
>
>     -- Mike
>
>     *From:*Id-event
>     <[email-masked]<mailto:[email-masked]>>*On
>     Behalf Of*Mike Jones
>     *Sent:*Wednesday, February 28, 2018 3:46 PM
>     *To:*Phil Hunt
>     <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer
>     <[email-masked]<mailto:[email-masked]>>
>     *Cc:*SecEvent <[email-masked]<mailto:[email-masked]>>
>     *Subject:*Re: [Id-event] Doc shepherd review
>
>     Phil is correct.  The “txn” claim is intentionally usable with any
>     JWT and not specific to SETs. This just happens to be the spec to
>     define it and add it to the IANA JWT Claims registry.
>
>     Yaron, I plan to tweak your language “SETs serve to exchange
>     information about identity-related events” because the charter is
>     about security events, only some of which are identity events.  We
>     shouldn’t narrow the scope of applicability beyond what’s intended.
>
>     -- Mike
>
>     *From:*Id-event
>     <[email-masked]<mailto:[email-masked]>>*On
>     Behalf Of*Phil Hunt
>     *Sent:*Wednesday, February 28, 2018 3:35 PM
>     *To:*Yaron Sheffer
>     <[email-masked]<mailto:[email-masked]>>
>     *Cc:*SecEvent <[email-masked]<mailto:[email-masked]>>
>     *Subject:*Re: [Id-event] Doc shepherd review
>
>     Yaron,
>
>     Mike has added some other minor editorial fixes for consistency
>     with JWT etc which I believe the group discussed.
>
>         On Feb 28, 2018, at 3:27 PM, Yaron Sheffer
>         <[email-masked]<mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         I will be document shepherd for the SET spec. As such, I just
>         reread it once again, and I think it is in very good shape.
>         Here are my (mostly editorial) comments.
>
>         - Abstract: please add the following to clarify, e.g. after
>         the first sentence: SETs serve to exchange information about
>         identity-related events.
>         - "SETs have no capability for error signaling to ensure the
>         validation of a received SET" - SETs are a format, so it is a
>         higher level protocol that may or may not signal errors. I
>         suggest to remove this sentence.
>     I will re-read. I think what the spec is trying to say is to or
>     related to. Meaning the even is directly related to the subject
>     but not necessarily to the subject.  I will review and suggest
>     some text.
>
>         - IMO the distinction between JWTs and SETs with regard to the
>         need to use "exp" is not convincing. I suggest we refer to
>         Sec. 4.5 for a better rationale why we make this claim NOT
>         RECOMMENDED rather than OPTIONAL as in RFC 7519.
>         - "to provide integrity, confidentiality, and issuer
>         validation", should be "issuer authenticity".
>         - "Whether and how multiple "events" values are used": the
>         reader who has not been following our discussions may not
>         understand what this means, maybe we should say in
>         parentheses, (i.e. multiple members in the "events" JSON object).
>         - 6.1.1: "Security Event URI" - this description is incorrect,
>         should probably be "Security Event information" or something
>         similarly vague.
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event