I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-secevent-token-07
Reviewer: Russ Housley
Review Date: 2018-03-27
IETF LC End Date: unknown
IESG Telechat date: 2018-05-10

Summary: Has Issues

Process concern

A request for a telechat review of draft-ietf-secevent-token was
assigned to me.  However, there has not yet been an IETF Last Call
announced for this document.


Major Concerns

All of the examples in Section 2.1 are non-normative.  Instead of
staying that in each of the subsections, please add some text at the
top of Section 2.1 that says so.

I do not understand the first paragraph of Section 3.  I think you are
trying to impose some rules on future specifications that use SET to
define events.  Please reword.


Minor Concerns

The Abstract says:

   ...  This statement of fact
   represents an event that occurred to the security subject.  In some
   use cases, the security subject may be a digitial identity, but SETs
   are also applicable to non-identity use cases.  ...

Please correct the spelling of digital identity.

I do not think this tells the reader when they might want to employ this
specification.  The following sentence from the Introduction does a
better job:

   This specification is scoped to security and identity related events.


In Section 2, the last bullet on page 5 talks about the "events" JSON
object.  The last sentence caught me by surprise, and I had to read it a
few times to figure out the intent.  The events object cannot be "{}",
but the payload for an event in that object can be "{}".  I think that
a MUST statement about there being at least one URI string value would
have helped me.