[Id-event] SET "aud" syntax

[Mike Jones <[e-mail]>]

Hi Yaron,

You commented below on the “aud” syntax, asking for it to be an array.  The “aud” syntax is already defined by RFC 7519 as:
   In the general case, the "aud" value is an array of case-
   sensitive strings, each containing a StringOrURI value.  In the
   special case when the JWT has one audience, the "aud" value MAY be a
   single case-sensitive string containing a StringOrURI value.

So that standard JWT libraries can be used with SETs, I believe we should just reference the RFC 7519 definition, something along the lines of “The syntax of the “aud” claim is as defined in Section 4.1.3 of [RFC 7519].”  Would that work for you?

                                                       -- Mike

From: Id-event [mailto:[e-mail]] On Behalf Of Yaron Sheffer
Sent: Saturday, December 10, 2016 1:28 PM
To: SecEvent <[e-mail]>
Subject: [Id-event] Some comments to draft-hunt-idevent-token-07


Hi, I finally read the draft in detail, and I do have a few comments.

My main suggestion is to tighten the specification of an Event, by defining more strictly the difference between "event" and "event extension" and tweaking the JSON structure a bit.

In addition, I think we should require the claim to be signed, since it will be used for security-sensitive activities across complex distributed systems.

  *   1: Why is signing optional? The publisher doesn't know how the subscriber's system is architected, and might well want end-to-end authentication of the claim. This is also important for auditing.
  *   1: "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop.
  *   1.2: principle -> principal
  *   2: "first value" is meaningless. JSON objects are unordered (4th paragraph of RFC 7159). If order is important, we could make "events" into an array.
  *   2: event extensions are not defined but only introduced by the text after they are described. Also, in the example there's this URL: https://​example.​com/​scim/​event/​pas​swor​dRes​etEx​t - I believe it needs to be part of the passwordReset object and not parallel to it.
  *   Why "events" and not "event"? We don't really have support for multiple events. Certainly not if they are all of the same type. The current text is confusing: "events" is not the same as "a primary event and its extensions".
  *   "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier version.
  *   "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI?
  *   Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings"?
  *   Why is "sub" optional? Do we have any good examples of events where this value is not required?
  *   "a future date" - we should clarify that there may be cases when nbf is smaller than iat, i.e. when it takes some time until the SET is issued.
  *   "exp" - is it also a NumericDate? Please specify.
  *   In the medical example, it is strange that the event is named by a URL that points to an HTML page. I would expect a more stable URI.
  *   2.2: is encryption a MUST whenever there are attributes specified? If so, we should have a normative section saying so, not just mention it in the context of an example. Besides, we have not defined what attributes are.
  *   2.2: this section is confusing. We first say that the JWT must be encrypted. But then instead, we sign it, and we "sign" with a null algorithm. Why?
  *   Signed SETs MUST (not MAY) be validated by the subscriber.
  *   Also, I think we should remove the preconditions and always require signing, as a MUST. An optional signature is actually a security loophole because an attacker can remove the signature, and the subscriber doesn't know that it's missing.
  *   3.2: "that alone will not guarantee that the correct subscribing party knows they should have received a particular SET." The text is unclear to me. Do we mean: "that alone does not guarantee that a particular SET was delivered to the correct subscribing party"?
  *   We may want a separate Implementation Considerations section, and move "delivery", "sequencing" and "timing" into it. Yes they are security-relevant, just like anything else in this document, but they would apply just as well to any event stream protocol.
  *   3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that?
  *   3.3: ISTM that we should define a sequencing mechanism, rather than leave it open to profiles. E.g., require a sequence number whenever "txn" is used.
  *   3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated logins/logouts).
  *   3.5: Why don't we have an unambiguous way to distinguish SETs from access tokens, why leave it to implementers? Sounds like a major security issue in the making. We should consider here ALL implementations that accept access tokens, including legacy implementations that cannot be modified.
  *   4: The audit happens on the subscriber side. By then it is too late to require JWS to be used by the publisher. As mentioned, I propose that JWS should ALWAYS be required.
  *   4: "When sharing personally identifiable information" - we should remove this condition. I don't see a case where the information shared is NOT PII, and therefore legal agreements about information sharing and user consent must always be in place.
  *   4: I don't think the subject information is "perceived" as PII. It is PII, otherwise it would be useless to the subscriber, because the subscriber would not be able to identify the subject. Also, even if the information on the wire is not in itself PII, e.g. when using a hash, the fact that a publisher shares information that a particular user is also a user on its system and is undergoing certain state changes is privacy-sensitive.
  *   I suggest to add an Implementation Status section, per RFC 7942.

Thanks,

    Yaron