Security Event Token (SET)
draft-ietf-secevent-token-13

Thanks to the authors and everyone else who contributed to this document. I have
two minor editorial comments.

---------------------------------------------------------------------------

Please make sure these nits are fixed before sending on to the RFC editor:

  == Unused Reference: 'RFC7009' is defined on line 1066, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7517' is defined on line 1078, but no explicit
     reference was found in the text

---------------------------------------------------------------------------

§4.3:

>  JWTs are now being used in application areas beyond the identity
>  applications in which they first appeared.  For instance, the Session
>  Initiation Protocol (SIP) Via Header Field [RFC8055] and Personal
>  Assertion Token (PASSporT) [RFC8225] specifications...

RFC 8055 defines a Received Realm parameter for the Via Header Field, not the
header field itself. Please rephrase as "...the Session Initiation Protocol
(SIP) Via Header Field Received Realm parameter [RFC8055]..."

This document is in a good shape, thank you for your work on it.

A couple of nits:

First references to Base64url and UTF-8 need normative references.
Use RFC 3629 for the latter.

= Sec. 5.1 =

"Security events distributed through third parties or that carry
   personally identifiable information SHOULD be encrypted using JWE
   [RFC7516] or secured for confidentiality by other means."

The SHOULD here seems like it should be a MUST unless there are obvious exception cases.

= Sec. 5.2 =

"In
   addition to confidentiality and integrity (discussed above),
   implementers and profiling specifications MUST consider the
   consequences of delivery mechanisms that are not secure and/or not
   assured."

The "implementers ... MUST consider" construction seems like an odd use of normative language.

Thanks for the work on this. 

Most of my comments have already been captured by others. I have one remaining observation, which I don't expect to be addressed: "SET" is going to be an exceptionally difficult Google search term. (I speak from experience as the one-time chair of the "SIMPLE" working group).

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4210



IMPORTANT
S 2.2.
>         *  a URI representing a user resource that was modified; or,
>   
>         *  a token identifier (e.g. "jti") for a revoked token.
>   
>         If used, the profiling specification SHOULD define the content and
>         format semantics for the value.  This claim is OPTIONAL, as the

Doesn't this need to be a MUST for interoperability?


S 4.
>         present but require that all be understood if the SET is to be
>         accepted.  Some profiles might require that only a single value be
>         present.  All such choices are within the scope of profiling
>         specifications to define.
>   
>   4.  Preventing Confusion between SETs and other JWTs

Why don't you include some claim that makes these unambiguously SETs?
That would at least prevent one directional confusion.

COMMENTS
S 2.2.
>   
>      "iss" (Issuer) Claim
>         As defined by Section 4.1.1 of [RFC7519], this claim contains a
>         string identifying the service provider publishing the SET (the
>         issuer).  In some cases, the SET issuer is not the issuer of the
>         security subject.  Therefore, implementers cannot assume that the

I am having a hard time reading this text. What do you mean "issue or
security subject?"


S 3.
>         Profiling specifications MUST define how the event subject is
>         identified in the SET, as well as how to differentiate between the
>         event subject's issuer and the SET issuer, if applicable.  It is
>         NOT RECOMMENDED for profiling specifications to use the "sub"
>         claim in cases in which the subject is not globally unique and has
>         a different issuer from the SET itself.

Doesn't this contradict the SHOULD i called out above?


S 5.1.
>      personally identifiable information SHOULD be encrypted using JWE
>      [RFC7516] or secured for confidentiality by other means.
>   
>      Unless integrity of the JWT is ensured by other means, it MUST be
>      signed using JWS [RFC7515] so that the SET can be authenticated and
>      validated by the SET recipient.

This MUST seems less helpful than it would otherwise be because it
doesn't specify what a valid signer is.


S 5.4.
>      When SETs are delivered asynchronously and/or out-of-band with
>      respect to the original action that incurred the security event, it
>      is important to consider that a SET might be delivered to a SET
>      recipient in advance of or behind the process that caused the event.
>      For example, a user having been required to log out and then log back
>      in again, may cause a token revoked SET to be issued, typically

Might be clearer to quote "token revoked"

Hello,

I'm not sure about the use of normative language in this sentence:
   Throughout this document, all figures MAY contain spaces

I guess this doc could also be informational as it "only" specifies a SET data structure and specific profiles will be defined in other documents that I guess would/could/should be stand-alone and as such might only need to refer this doc informatively. Was the intended state discussed in the working group? 

Minor question/comment:
sec  6: "SET issuers SHOULD take steps to minimize the chance of event correlation, when such correlation would constitute a privacy violation."
Should this maybe be a MUST given there is a constraint already given?