Security Event Token (SET)
RFC 8417
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
(Benjamin Kaduk; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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]..."
(Alexey Melnikov; former steering group member) No Objection
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.
(Alissa Cooper; former steering group member) No Objection
= 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.
(Ben Campbell; former steering group member) No Objection
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).
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
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"
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
Hello, I'm not sure about the use of normative language in this sentence: Throughout this document, all figures MAY contain spaces
(Mirja Kühlewind; former steering group member) No Objection
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?
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection