Subject: [Id-event] Doc shepherd review

From: Yaron Sheffer <[email-masked]>
Date: Thu, 1 Mar 2018 01:27:22 +0200

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Feb 2018 23:29:46 +0000

Thanks, Yaron.  I'm right now adding the defined terms that Marius had asked for.  I'll apply these corrections as well at the same time.

				Thanks again,
				-- Mike

-----Original Message-----
From: Id-event <[email-masked]> On Behalf Of Yaron Sheffer
Sent: Wednesday, February 28, 2018 3:27 PM
To: SecEvent <[email-masked]>
Subject: [Id-event] Doc shepherd review

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"?
- 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.
- "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]
https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Feb 2018 15:34:39 -0800

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

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

> 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: Mike Jones <[email-masked]>
Date: Wed, 28 Feb 2018 23:45:35 +0000

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

Yaron,

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,

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: Mike Jones <[email-masked]>
Date: Thu, 1 Mar 2018 01:15:46 +0000

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

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

Phil

Hi,

Thanks,
    Yaron