Subject: [Id-event] Some comments to draft-hunt-idevent-token-07

From: Yaron Sheffer <[email-masked]>
Date: Sat, 10 Dec 2016 23:27:37 +0200

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
    <https://%E2%80%8Bexample.%E2%80%8Bcom/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt>-
    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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 14 Dec 2016 08:51:34 -0800

Yaron,

Thanks for your extensive feedback. 

Apologies for my late response. I will respond shortly. 

Phil

> On Dec 10, 2016, at 1:27 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> 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
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Dec 2016 12:18:01 -0800

Yaron,

Thanks for your comments. My responses inline.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> 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.
The spec has undergone some restructuring recently, and it may need some more tightening up. The informal consensus from the id-events list is that there should be only one event. However, in order to allow some deployers to provide additional information, and extension methodology was included.  An example is given.
> 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.
I think the key word in your question is “might”.  Also, its not the publisher that needs authentication of the statement its really the subscriber.

Many have preferred to have a minimum option where security is essentially point-to-point depending primarily on TLS.  There are other cases where end-to-end key based is preferred especially when transmitting over less secure transport.

Remember that this specification is a coming together of a bunch of initiatives around a common format. It is difficult to assign mandatory requirements unless there is strong consensus to do so.

> 1: "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop.
The intention is to define a base level format that other working groups and SDOs will use to define their own events. The primary benefit is to have a common format.

I had originally envisioned an event registry, but the early discussions were to avoid IANA registration. We then switched to using URI’s for events. 

The informal consensus was that what matters is that publisher and subscriber agree on meaning and that it is ok for events to be highly specific.
> 1.2: principle -> principal
Noted
> 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.
Yup.   How would the group like to fix this?  We could make “events” singular and have an extensions attribute to hold the extensions.  Or we could go to a more complex JSON structure (not personally a fan).
> 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://%e2%80%8bexample.%e2%80%8bcom/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt>https://​example.​com/​scim/​event/​pas​swor​dRes​etEx​t <https://example.com/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt> - I believe it needs to be part of the passwordReset object and not parallel to it.
I will check for clarity. The password example is intended to demonstrate an example where a publisher wishes to provide additional context such as the number of resets performed.  Note in defining a password reset event it might indeed make sense to combine that info. My intent was to show an extension. Maybe there is a better hypothetical example?
> 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”.
Reflects your earlier comment re: primary vs. extensions.  "events” is plural to reflect the fact that the attribute is multi-valued. I agree, given that only one primary event can be included, the naming is misleading.
> "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier version.
NO.  In the example, “iss” and “sub” indicate the subject is from a different issuer of the event.  For example a relying party web site wants to tell the identity provider (the original subject issuer) that the user has requested a logout.
> "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI?
This is defined by the JWT spec.
> Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings”?
Habit from the world of IDM. We could align it.
> Why is "sub" optional? Do we have any good examples of events where this value is not required?
You might have an event about a session, or an IP address, or some other thing.

There was an email discussion in the past about whether sub should be a security subject (e.g. as defined by SAML or OpenID Connect), or whether sub is just the subject of the event and thus can be anything.

I expect to see more discussion on this.
> "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.
Assume you are referring to “nbf”. The definition comes from JWT. 
> "exp" - is it also a NumericDate? Please specify.
Defined by JWT, RFC7519
> 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.
It is an example. Many have indicated that they want the event should be a URL to the page that defines the event.

> 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 define…
Please quote the text, 2.2 simply shows how to construct a SET token based on language from 7519.
> 2.2: this section is confusing. We first say that the JWT must be encrypted.
Where does it say this?
> But then instead, we sign it, and we "sign" with a null algorithm. Why?
specific text please?
> 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 s…
Which text are you referring to.

Signatures aren’t always necessary if the method for delivery itself authenticates the publisher delivering the HTTP POST request and it is secured by TLS. 
> 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”?
Just because an endpoint returns success after a POST does not by itself guarantee it was able to decrypt or parse the message. Nor does it prove  the subscriber held the private key to decrypt the JWE.

We cover this somewhat in the distribution draft when we talk about verification messages which require the receiver to parse the message and return content back proving possession.
> 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 t…
Seems reasonable.
> 3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that?
Yes. Some of us do - this work actually began within the SCIM WG.  Provisioning was provided as an example of a type of event where ordering would be crucial.
> 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.
txn is a separate concept. txn is there when publishers decide to issue multiple events against the same originating event.  For example, one subscriber might understand suspicious activity while another might only understand logout. Some have requested an attribute that lets the publisher track that the different events actually stem from the same original event.  For example when a publishers operations center gets a call to trace a series of events. 
> 3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated logins/logouts).
The point here is to address event design issues where relying on timestamp to order events is problematic. For example if you signal logout only by subject identifier then it becomes hard to tell if a user is logging back in or not. It is better to cancel a session associated with a subject so that the new session can still be established.
> 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 impleme…
I agree. The real issue is that JWT’s should have had a type to begin with. One of the threads is here:
https://www.ietf.org/mail-archive/web/id-event/current/msg00120.html
> 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.
This is something that publisher and subscriber have to negotiate. This is anticipated in the distribution spec to some degree. Though IMO, there is not a lot of consensus on this yet.
> 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…
How about cancellation of a token or a session?  If just passing a “jti” value, there is arguably no PII.  The JTI might be traceable, but the relying party would have to know about it to infer meaning.  Also, tokens/sessions should never be permanent.  I am not a lawyer, but I doubt these examples would actually be PII.
> 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, e…
Again, the subject of an event might be about a session or a token, device, etc.
> I suggest to add an Implementation Status section, per RFC 7942.
It would be helpful for the chairs to provide guidance on this.

---

From: Mike Jones <[email-masked]>
Date: Wed, 14 Dec 2016 20:58:38 +0000

Let me also thank you for these detailed comments, Yaron.  They’re very useful!

I’m on vacation this week but have already flagged this to respond to in detail next week.  That said, I agree with many of Phil’s responses.  That said, I am against changing “events” to “event”.  It’s application-dependent whether there is only one event, a set of related events sharing context, and which is primary.  I think we should remain general in this regard.  (Yes, we do need to finish cleaning up the language leftover from when events were represented in a JSON array rather than a JSON object.)

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, December 14, 2016 12:18 PM
To: Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07

Yaron,

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Dec 10, 2016, at 1:27 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

  *   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.
I think the key word in your question is “might”.  Also, its not the publisher that needs authentication of the statement its really the subscriber.

  *   1: "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop.
The intention is to define a base level format that other working groups and SDOs will use to define their own events. The primary benefit is to have a common format.

  *   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.
Yup.   How would the group like to fix this?  We could make “events” singular and have an extensions attribute to hold the extensions.  Or we could go to a more complex JSON structure (not personally a fan).

  *   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<https://example.com/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt> - I believe it needs to be part of the passwordReset object and not parallel to it.
I will check for clarity. The password example is intended to demonstrate an example where a publisher wishes to provide additional context such as the number of resets performed.  Note in defining a password reset event it might indeed make sense to combine that info. My intent was to show an extension. Maybe there is a better hypothetical example?

  *   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”.
Reflects your earlier comment re: primary vs. extensions.  "events” is plural to reflect the fact that the attribute is multi-valued. I agree, given that only one primary event can be included, the naming is misleading.

  *   "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier version.
NO.  In the example, “iss” and “sub” indicate the subject is from a different issuer of the event.  For example a relying party web site wants to tell the identity provider (the original subject issuer) that the user has requested a logout.

  *   "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI?
This is defined by the JWT spec.

  *   Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings”?
Habit from the world of IDM. We could align it.

  *   Why is "sub" optional? Do we have any good examples of events where this value is not required?
You might have an event about a session, or an IP address, or some other thing.

  *   "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.
Assume you are referring to “nbf”. The definition comes from JWT.

  *   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.
It is an example. Many have indicated that they want the event should be a URL to the page that defines the event.

  *   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.
Please quote the text, 2.2 simply shows how to construct a SET token based on language from 7519.

  *   2.2: this section is confusing. We first say that the JWT must be encrypted.
Where does it say this?

  *   But then instead, we sign it, and we "sign" with a null algorithm. Why?
  *   Signed SETs MUST (not MAY) be validated by the subscriber.
specific text please?

  *   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.
Which text are you referring to.

  *   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”?
Just because an endpoint returns success after a POST does not by itself guarantee it was able to decrypt or parse the message. Nor does it prove  the subscriber held the private key to decrypt the JWE.

  *   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.
Seems reasonable.

  *   3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that?
Yes. Some of us do - this work actually began within the SCIM WG.  Provisioning was provided as an example of a type of event where ordering would be crucial.

  *   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.
txn is a separate concept. txn is there when publishers decide to issue multiple events against the same originating event.  For example, one subscriber might understand suspicious activity while another might only understand logout. Some have requested an attribute that lets the publisher track that the different events actually stem from the same original event.  For example when a publishers operations center gets a call to trace a series of events.

  *   3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated logins/logouts).
The point here is to address event design issues where relying on timestamp to order events is problematic. For example if you signal logout only by subject identifier then it becomes hard to tell if a user is logging back in or not. It is better to cancel a session associated with a subject so that the new session can still be established.

  *   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.
I agree. The real issue is that JWT’s should have had a type to begin with. One of the threads is here:
https://www.ietf.org/mail-archive/web/id-event/current/msg00120.html

  *   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.
This is something that publisher and subscriber have to negotiate. This is anticipated in the distribution spec to some degree. Though IMO, there is not a lot of consensus on this yet.

  *   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.
How about cancellation of a token or a session?  If just passing a “jti” value, there is arguably no PII.  The JTI might be traceable, but the relying party would have to know about it to infer meaning.  Also, tokens/sessions should never be permanent.  I am not a lawyer, but I doubt these examples would actually be PII.

  *   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.
Again, the subject of an event might be about a session or a token, device, etc.

Thanks,
    Yaron
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 18 Dec 2016 23:32:08 +0200

Hi Phil,

Thank you for your detailed comments, they are very helpful as I ramp up 
my understanding of this area. Please see some responses inline.

Thanks,
	Yaron

On 14/12/16 22:18, Phil Hunt wrote:
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
> The spec has undergone some restructuring recently, and it may need some
> more tightening up. The informal consensus from the id-events list is
> that there should be only one event. However, in order to allow some
> deployers to provide additional information, and extension methodology
> was included.  An example is given.
>>
>> 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.
>>
> I think the key word in your question is “might”.  Also, its not the
> publisher that needs authentication of the statement its really the
> subscriber.
>
> Many have preferred to have a minimum option where security is
> essentially point-to-point depending primarily on TLS.  There are other
> cases where end-to-end key based is preferred especially when
> transmitting over less secure transport.
>
> Remember that this specification is a coming together of a bunch of
> initiatives around a common format. It is difficult to assign mandatory
> requirements unless there is strong consensus to do so.
>
> The intention is to define a base level format that other working groups
> and SDOs will use to define their own events. The primary benefit is to
> have a common format.
>
> I had originally envisioned an event registry, but the early discussions
> were to avoid IANA registration. We then switched to using URI’s for
> events.
>
> The informal consensus was that what matters is that publisher and
> subscriber agree on meaning and that it is ok for events to be highly
> specific.

I still need to wrap my mind around a spec (and a working group) where 
the end result is not interoperable implementations.

>>     paragraph of RFC 7159). If order /is/ important, we could make
>>     "events" into an array.
> Yup.   How would the group like to fix this?  We could make “events”
> singular and have an extensions attribute to hold the extensions.  Or we
> could go to a more complex JSON structure (not personally a fan).

I'm personally fine with a main "event" object and an "extensions" 
attribute. I can even live with "event" being called "events", per 
Mike's proposal. But the structure needs to make sense as a JSON object 
if we want it implemented.

>>
>>   * 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://%e2%80%8bexample.%e2%80%8bcom/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt>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.
> I will check for clarity. The password example is intended to
> demonstrate an example where a publisher wishes to provide additional
> context such as the number of resets performed.  Note in defining a
> password reset event it might indeed make sense to combine that info. My
> intent was to show an extension. Maybe there is a better hypothetical
> example?
>>
>>     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”.
> Reflects your earlier comment re: primary vs. extensions.  "events” is
> plural to reflect the fact that the attribute is multi-valued. I agree,
> given that only one primary event can be included, the naming is misleading.
>>
>>   * "In the above example "iss" and "sub" contained within the claim"
>>     - this is incorrect, probably leftover from an earlier version.
> NO.  In the example, “iss” and “sub” indicate the subject is from a
> different issuer of the event.  For example a relying party web site
> wants to tell the identity provider (the original subject issuer) that
> the user has requested a logout.

I'm still confused by the text. The paragraph talks about iss and sub 
contained within the claim, and contrasted with "the top level value of 
iss", which I'm unable to locate.

> This is defined by the JWT spec.

I am talking about the syntax. "aud" is an array of URIs, not a URI.

>>     "array of strings”?

We should.

> There was an email discussion in the past about whether sub should be a
> security subject (e.g. as defined by SAML or OpenID Connect), or whether
> sub is just the subject of the event and thus can be anything.
>

I'm confused. If the subject is an IP address or session identifier, it 
still doesn't make it into an optional value.

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

The clarification is still needed, if the JWT definition is imprecise.

>>   * "exp" - is it also a NumericDate? Please specify.

If we repeat all other JWT definitions, we should repeat this one too, 
for consistency.

> It is an example. Many have indicated that they want the event should be
> a URL to the page that defines the event.

I would prefer our examples to be what we think are best practices. And 
personally I don't think this is one. What if the next version of the 
web site's code changes "consent.html" into "consent.jsp"?

> based on language from 7519.

Quoting: "In this example, because the event contains attribute values, 
the token MUST be encrypted per JWE (see [RFC7516]) before transmission."

>>     encrypted.

See above.

>>   * Signed SETs MUST (not MAY) be validated by the subscriber.

Quote: "so that individual events MAY be authenticated and 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.
> Signatures aren’t always necessary if the method for delivery itself
> authenticates the publisher delivering the HTTP POST request and it is
> secured by TLS.
>>
>>     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”?
> Just because an endpoint returns success after a POST does not by itself
> guarantee it was able to decrypt or parse the message. Nor does it prove
>  the subscriber held the private key to decrypt the JWE.

Absolutely. And your text here is much clearer than the sentence I quote 
above, "that alone does not guarantee...".

>
> We cover this somewhat in the distribution draft when we talk about
> verification messages which require the receiver to parse the message
> and return content back proving possession.
>>
> Yes. Some of us do - this work actually began within the SCIM WG.
>  Provisioning was provided as an example of a type of event where
> ordering would be crucial.
>>
>>   * 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.
> txn is a separate concept. txn is there when publishers decide to issue
> multiple events against the same originating event.  For example, one
> subscriber might understand suspicious activity while another might only
> understand logout. Some have requested an attribute that lets the
> publisher track that the different events actually stem from the same
> original event.  For example when a publishers operations center gets a
> call to trace a series of events.
>>
>>   * 3.4: Also, our timestamps only have 1 second granularity, and so
>>     are too coarse for session state (consider automated logins/logouts).
> The point here is to address event design issues where relying on
> timestamp to order events is problematic. For example if you signal
> logout only by subject identifier then it becomes hard to tell if a user
> is logging back in or not. It is better to cancel a session associated
> with a subject so that the new session can still be established.
>>

Yep. I would like to reopen this discussion post-adoption.

>>
>>   * 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.
> This is something that publisher and subscriber have to negotiate. This
> is anticipated in the distribution spec to some degree. Though IMO,
> there is not a lot of consensus on this yet.
>>
>>     shared is NOT PII, and therefore legal agreements about
>>     information sharing and user consent must always be in place.
> How about cancellation of a token or a session?  If just passing a “jti”
> value, there is arguably no PII.  The JTI might be traceable, but the
> relying party would have to know about it to infer meaning.  Also,
> tokens/sessions should never be permanent.  I am not a lawyer, but I
> doubt these examples would actually be PII.
>>
>>     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 am an author on 7942, so I will only recommend it as an individual: I 
think it will be helpful to WG members when evaluating the draft. We can 
probably delay it to just before WGLC though.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 21 Dec 2016 13:20:34 -0800

Yaron,

Thanks for your comments. Its always good to get broader review. My responses inline.

I have marked some sections as “Thread: …” which is an invitation to open a new email thread to keep the discussion going.

Phil

@independentid

> On Dec 18, 2016, at 1:32 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Phil,
> 
> Thank you for your detailed comments, they are very helpful as I ramp up my understanding of this area. Please see some responses inline.
> 
> Thanks,
> 	Yaron
> 
>> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com <http://www.independentid.com/>>
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> 
>> 
>> 
>>> On Dec 10, 2016, at 1:27 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>
>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
> I still need to wrap my mind around a spec (and a working group) where the end result is not interoperable implementations.

[PH] I think you may be confusing protocol and message format with content. The goal of this specification is to provide a common event format that can be easily exchanged.  Other WGs and SDOs are planning to use this common format to define their own specific events. E.g. http://openid.net/specs/openid-connect-backchannel-1_0.html

So what we are looking for is a way for libraries to be developed that are extensions of current JWT libraries. 

Ideally this is small incremental profile of JWT that adds key clarifications, security and privacy considerations.
> I'm personally fine with a main "event" object and an "extensions" attribute. I can even live with "event" being called "events", per Mike's proposal. But the structure needs to make sense as a JSON object if we want it implemented.

[PH] Thread: Should the primary event be a separate attribute?

We had this broken out before. If there is sufficient desire to break it out again, I have no objection.
>>>    URL: <https://%e2%80%8bexample.%e2%80%8bcom/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt <https://example.com/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt>>https://
> I'm still confused by the text. The paragraph talks about iss and sub contained within the claim, and contrasted with "the top level value of iss", which I'm unable to locate.
[PH]  Thread: On the issue of “sub” and “iss”

“sub” in the root level is defined by the JWT specification. Many of the implementations of JWT have asserted “sub” as unique only within the context of a specific issuer. This worked fine in SSO cases because only the identity provider that controls the issuer would issue an assertion for a subject within their domain.

When we start to talk about hypothetical events that may arise, it is reasonable to expect that a relying party may wish to issue an event about a federated identity providers subject.  If they do that, then “iss” becomes conflicted.  “iss” should be the issuer of the event. Yet, “sub” by itself in many cases does not sufficiently identify the subject of the event.

We worked around this by allowing sub and iss to be moved to the payload area. This would allow a relying party site the ability to signal an event about a subject for which they were not the original issuer.
> I am talking about the syntax. "aud" is an array of URIs, not a URI.
[PH] I will double-check this.
>> Habit from the world of IDM. We could align it.
[PH] OK
> I'm confused. If the subject is an IP address or session identifier, it still doesn't make it into an optional value.
[PH] Thread: “sub” used for any purpose or used as an authenticated user only

It depends on what the defining event spec wants to use. There was resistance to forcing its use.

In fact there was a lot of opinion that “sub” should only be used for an authenticated user as that was the defacto use.

I think this thread could use some more discussion.
> If we repeat all other JWT definitions, we should repeat this one too, for consistency.
> 
>>> 
> I would prefer our examples to be what we think are best practices. And personally I don't think this is one. What if the next version of the web site's code changes "consent.html" into "consent.jsp”?

[PH] From my standpoint this is a chicken and the egg practice. This is a new format which there are several planned extensions.  So there is nothing stable I as editor can refer to.

The hypothetical examples are shown to give a variety of examples that are acceptable.  For example, SCIM *might* use URNs while other specifications like RISC might user pointers to published HTML or txt files on the OpenId.net site.

It is really up to the publisher and the subscriber to agree.

> Quoting: "In this example, because the event contains attribute values, the token MUST be encrypted per JWE (see [RFC7516]) before transmission.”

[PH] Examples are not normative.  The text may not be sufficiently clear.  What I was trying to distinguish was the difference between an event that says a record was modified, and an event that says a record was modified with the actual changes as part of the event.

> Quote: "so that individual events MAY be authenticated and validated by the subscriber."
> 
>>> 
> Absolutely. And your text here is much clearer than the sentence I quote above, "that alone does not guarantee...".
> 
>> 

[PH] Thread: Avoiding SETs being confused as an access token

I agree. My personal thought is to avoid usage of “sub” at the top level. It addresses the issuer conflict mentioned above and current implementations will fail if an event is passed as if it were an access token as sub is missing.

The complaint I heard back is that there are some libraries that simply will not work at all if “sub” is not present. This is despite the JWT spec making sub optional.

I’m not sure what is best here. I tend to side with existing libraries being upgraded to be SET compatible anyway. The reality is, SET isn’t breaking JWT rules, its the implementation that is.

With that said, there may be a better way to distinguish SETs and JWTs.

> I am an author on 7942, so I will only recommend it as an individual: I think it will be helpful to WG members when evaluating the draft. We can probably delay it to just before WGLC though.

[PH] Thread: RFC7942 support

I am a bit surprised by this specification and as editor I would like some guidance on this from the chairs.

As editor, RFC7942 has admirable goals, but it creates a chicken-and-the-egg problem…

My understanding of RFCs is that except for errata there is no revision process for RFCs. 7942 introduces a requirement for monthly if not daily updates that the IETF does not currently support.

Many organizations are not willing/able to publish their implementation support until code is “shipping” and often until after the IETF has published RFCs.  Introducing an implementation list at the draft stage unfairly penalizes organizations that will not ship until RFC status is obtained.  IMO it would also be mis-leading as to the acceptance of a specification.

For example, my impression of SCIM implementation was that it almost immediately doubled *after* publication as 7643/7644.  Had published implementation information at publication it would have been immediately incomplete and potentially erroneous.

>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 22 Dec 2016 13:34:04 +0200

Hi Phil,

I'd like to respond separately to your last point, as an individual (and 
coauthor of the said RFC). It's important to me to clarify the intent 
and some important details of the RFC.

Thanks,
	Yaron

On 21/12/16 23:20, Phil Hunt wrote:
> I have marked some sections as “Thread: …” which is an invitation to
> open a new email thread to keep the discussion going.
>
> Phil
>
>>>>
>> I am an author on 7942, so I will only recommend it as an individual:
>> I think it will be helpful to WG members when evaluating the draft. We
>> can probably delay it to just before WGLC though.
>

The RFC and its predecessor were used by over 50 I-Ds, so obviously the 
problems are not insurmountable.
>
> My understanding of RFCs is that except for errata there is no revision
> process for RFCs. 7942 introduces a requirement for monthly if not daily
> updates that the IETF does not currently support.

No. The RFC applies to I-Ds only, and the Implementation Status section 
should be removed before the I-D is published as an RFC. This is stated 
clearly in RFC 7942 (not clearly enough though, since you missed it :-).

>
> Many organizations are not willing/able to publish their implementation
> support until code is “shipping” and often until after the IETF has
> published RFCs.  Introducing an implementation list at the draft stage
> unfairly penalizes organizations that will not ship until RFC status is
> obtained.  IMO it would also be mis-leading as to the acceptance of a
> specification.

Again, the goal is to support the WG and the IETF at large while the I-D 
is being developed. It is not a goal (or a likely result, IMHO) to 
benefit or penalize specific implementers. The RFC is vague enough that 
companies can choose what to publish and what not to.

>
> For example, my impression of SCIM implementation was that it almost
> immediately doubled *after* publication as 7643/7644.  Had published
> implementation information at publication it would have been immediately
> incomplete and potentially erroneous.

See above.

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 22 Dec 2016 07:12:23 -0800

Thanks Yaron for the clarification. 

If it is only in the I-d stage then my concerns are misplaced. 

I think it would be useful as there are a number of libraries that should already work. 

Phil

> On Dec 22, 2016, at 3:34 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Phil,
> 
> I'd like to respond separately to your last point, as an individual (and coauthor of the said RFC). It's important to me to clarify the intent and some important details of the RFC.
> 
> Thanks,
>    Yaron
> 
> The RFC and its predecessor were used by over 50 I-Ds, so obviously the problems are not insurmountable.
>> 
> No. The RFC applies to I-Ds only, and the Implementation Status section should be removed before the I-D is published as an RFC. This is stated clearly in RFC 7942 (not clearly enough though, since you missed it :-).
> 
>> 
> Again, the goal is to support the WG and the IETF at large while the I-D is being developed. It is not a goal (or a likely result, IMHO) to benefit or penalize specific implementers. The RFC is vague enough that companies can choose what to publish and what not to.
> 
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Dec 2016 19:47:23 +0000

I’m replying to Yaron’s original message so the result will be short enough to be quickly readable, while acknowledging that Phil already made many points in his responses that I agree with.  Where I don’t have anything to add to Phil’s responses, I don’t include a response to those points.  My replies are prefixed by “Mike>”.

Thanks for taking the time to do a thorough read, Yaron!

                                                       -- Mike

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

Mike> Per my reply in the thread “[Id-event] Draft adoption”, I think we’d be better off completely dropping the distinction between primary events and secondary events.  When applications send a set of related events together, it’s logical for recipients to process all of them (or all of them that they understand).  The primary/secondary distinction is unhelpful and leads to complication, rather than clarity or simplification.  Let’s drop it entirely.

Mike> This is ground already well-covered during both the JOSE [RFC 7515] and JWT [RFC 7519] standardization efforts.  The key observation is that JWT (and SET) is a data structure to be used in protocols and applications – not a protocol or application specification.  It’s up to protocol and application specifications to define whether signing is needed (and if so, with what algorithms).  In some cases, it won’t be needed because the JWT/SET is already integrity protected by the protocol or application – for instance, by TLS.  Just like for JWT, we shouldn’t require signing in cases that it adds no value but does add overhead.  A working group consensus call confirmed the need for the ability to use “alg”:“none” for JWS objects.

Mike> I agree with Phil’s response that interop happens within applications and protocols using SETs.

Mike> Order is unimportant.  This was already widely discussed on the id-event list.  While we used to use an array representation, a conscious choice was made to move to the current “set of events” syntax, replacing the old “array of events” syntax.

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

Mike> The “event extensions” language is a holdover from when there was an array of events and the first event was somehow special.  I agree that we need to perform editorial surgery to clean this up, because it is currently misleading.

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

Mike> What’s being represented is a set of related events from the same issuer.  Again, the extensions language is misleading, and needs to be fixed.

Mike> I agree with Phil’s points.  The editors can work on this to make the intent clearer.

  *   Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings"?
  *   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?
  *   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"?

Mike> We do have an unambiguous manner of distinguishing SETs from other JWTs – the inclusion of the “events” claim.  OAuth access tokens are, by definition, opaque, and completely outside of our scope of work.

Mike> We should stay completely clear of specifying what applications and protocols must do with SETs.  It’s up to them to profile SETs so that the application’s privacy and security properties are maintained, which will differ between applications.  Just like whether “alg”: “none” is appropriate is a protocol/application decision, it’s also a protocol/application decision whether encryption is needed, depending upon the context.

Mike> Per my previous comment, what’s PII (or not) is protocol/application-specific and not an appropriate topic for the SET spec.  The editors should remove any such language, other than perhaps informative comments in the Security Considerations and Privacy Considerations sections, listing things that protocol/application designers should consider.

Thanks,

    Yaron

Mike> Thanks again for the thorough and thoughtful comments, Yaron!

                                                       -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Dec 2016 12:19:20 -0800

[personal hat]
+1

[editor hat]
I’ll await chair instruction on what to modify before/after adoption etc.

The clean-up and consistency issues can happen as soon as some of these decisions are clarified as the formal consensus.  At the moment we’re kind of stuck in between “styles”.

I note there may be some resistance to change now as I understand some implementation and testing is already under way — which is why I singled the “breaking” change.

Phil

@independentid

> On Dec 29, 2016, at 11:47 AM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yaron Sheffer
> To: SecEvent <[email-masked] <mailto:[email-masked]>>
> 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 <https://example.com/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt> - I believe it needs to be part of the passwordReset object and not parallel to it.
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 29 Dec 2016 23:02:22 +0000

Wrt. Existing implementations

If someone is already implementing, they are doing so knowing the spec can
change

We should not be swayed by existing implementations except for lessons they
may have learned

On Thu, Dec 29, 2016 at 12:19 PM Phil Hunt <[email-masked]> wrote:

> The clean-up and consistency issues can happen as soon as some of these
> decisions are clarified as the formal consensus.  At the moment we’re kind
> of stuck in between “styles”.
>
> I note there may be some resistance to change now as I understand some
> implementation and testing is already under way — which is why I singled
> the “breaking” change.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
>
>
>
>
> I’m replying to Yaron’s original message so the result will be short
> enough to be quickly readable, while acknowledging that Phil already made
> many points in his responses that I agree with.  Where I don’t have
> anything to add to Phil’s responses, I don’t include a response to those
> points.  My replies are prefixed by “Mike>”.
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Yaron Sheffer
> *Sent:* Saturday, December 10, 2016 1:28 PM
> *To:* SecEvent <[email-masked]>
> *Subject:* [Id-event] Some comments to draft-hunt-idevent-token-07
>
> defining more strictly the difference between "event" and "event extension"
> and tweaking the JSON structure a bit.
>
> Mike> Per my reply in the thread “[Id-event] Draft adoption”, I think we’d
> be better off completely dropping the distinction between primary events
> and secondary events.  When applications send a set of related events
> together, it’s logical for recipients to process all of them (or all of
> them that they understand).  The primary/secondary distinction is unhelpful
> and leads to complication, rather than clarity or simplification.  Let’s
> drop it entirely.
>
> will be used for security-sensitive activities across complex distributed
> systems.
>
>    - 1: Why is signing optional? The publisher doesn't know how the
> Mike> This is ground already well-covered during both the JOSE [RFC 7515]
> and JWT [RFC 7519] standardization efforts.  The key observation is that
> JWT (and SET) is a data structure to be used in protocols and applications
> – not a protocol or application specification.  It’s up to protocol and
> application specifications to define whether signing is needed (and if so,
> with what algorithms).  In some cases, it won’t be needed because the
> JWT/SET is already integrity protected by the protocol or application – for
> instance, by TLS.  Just like for JWT, we shouldn’t require signing in cases
> that it adds no value but does add overhead.  A working group consensus
> call confirmed the need for the ability to use “alg”:“none” for JWS objects.
>
>
>    - 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.
>
>
> Mike> Order is unimportant.  This was already widely discussed on the
> id-event list.  While we used to use an array representation, a conscious
> choice was made to move to the current “set of events” syntax, replacing
> the old “array of events” syntax.
>
>
>    - 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
>    <https://example.com/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt>
>     - I believe it needs to be part of the passwordReset object and not
>    parallel to it.
>
>
> Mike> The “event extensions” language is a holdover from when there was an
> array of events and the first event was somehow special.  I agree that we
> need to perform editorial surgery to clean this up, because it is currently
> misleading.
>
>
>    - Why "events" and not "event"? We don't really have support for
>    current text is confusing: "events" is not the same as "a primary event and
>    its extensions".
>
>
> Mike> What’s being represented is a set of related events from the same
> issuer.  Again, the extensions language is misleading, and needs to be
> fixed.
>
>
>    - "In the above example "iss" and "sub" contained within the claim" -
>    - "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
>    - "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
>    - 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
>    - 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
>    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
>    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
>    - 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
>    - 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.
>
>
> Mike> We do have an unambiguous manner of distinguishing SETs from other
> JWTs – the inclusion of the “events” claim.  OAuth access tokens are, by
> definition, opaque, and completely outside of our scope of work.
>
>
>    - 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.
>
>
> Mike> We should stay completely clear of specifying what applications and
> protocols must do with SETs.  It’s up to them to profile SETs so that the
> application’s privacy and security properties are maintained, which will
> differ between applications.  Just like whether “alg”: “none” is
> appropriate is a protocol/application decision, it’s also a
> protocol/application decision whether encryption is needed, depending upon
> the context.
>
>
>    - 4: I don't think the subject information is "perceived" as PII. It
>    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.
>
>
> Mike> Per my previous comment, what’s PII (or not) is
> protocol/application-specific and not an appropriate topic for the SET
> spec.  The editors should remove any such language, other than perhaps
> informative comments in the Security Considerations and Privacy
> Considerations sections, listing things that protocol/application designers
> should consider.
>
>
>    - I suggest to add an Implementation Status section, per RFC 7942.
>
> Thanks,
>     Yaron
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 31 Dec 2016 22:24:19 +0200

Hi Phil,

The chairs requested to clarify the event/events syntax and the related 
text, to make it all consistent with whatever semantics the editors 
settle on: single event with extensions, list of ordered events, set of 
events, whatever. The goal is to have a consistent start with respect to 
the main subject of this document. Everything else can happen after 
adoption.

Or in Mike's words: we are asking the editors to produce a new, cleaner 
individual draft before adoption as a working group document.

Thanks,
	Yaron

On 29/12/16 22:19, Phil Hunt wrote:
> decisions are clarified as the formal consensus.  At the moment we’re
> kind of stuck in between “styles”.
>
>> On Dec 29, 2016, at 11:47 AM, Mike Jones <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> enough to be quickly readable, while acknowledging that Phil already
>> made many points in his responses that I agree with.  Where I don’t
>> have anything to add to Phil’s responses, I don’t include a response
>> to those points.  My replies are prefixed by “Mike>”.
>>
>> *From:* Id-event [mailto:[email-masked]] *On Behalf
>> Of *Yaron Sheffer
>> *To:* SecEvent <[email-masked] <mailto:[email-masked]>>
>> Mike> Per my reply in the thread “[Id-event] Draft adoption”, I think
>> we’d be better off completely dropping the distinction between primary
>> events and secondary events.  When applications send a set of related
>> events together, it’s logical for recipients to process all of them
>> (or all of them that they understand).  The primary/secondary
>> distinction is unhelpful and leads to complication, rather than
>> clarity or simplification.  Let’s drop it entirely.
>>
>> Mike> This is ground already well-covered during both the JOSE [RFC
>> 7515] and JWT [RFC 7519] standardization efforts.  The key observation
>> is that JWT (and SET) is a data structure to be used in protocols and
>> applications – not a protocol or application specification.  It’s up
>> to protocol and application specifications to define whether signing
>> is needed (and if so, with what algorithms).  In some cases, it won’t
>> be needed because the JWT/SET is already integrity protected by the
>> protocol or application – for instance, by TLS.  Just like for JWT, we
>> shouldn’t require signing in cases that it adds no value but does add
>> overhead.  A working group consensus call confirmed the need for the
>> ability to use “alg”:“none” for JWS objects.
>>
>>
>> id-event list.  While we used to use an array representation, a
>> conscious choice was made to move to the current “set of events”
>> syntax, replacing the old “array of events” syntax.
>>
>>
>>     URL: https://​example.​com/​scim/​event/​pas​swor​dRes​etEx​t
>>     <https://example.com/%E2%80%8Bscim/%E2%80%8Bevent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt> -
>> Mike> The “event extensions” language is a holdover from when there
>> was an array of events and the first event was somehow special.  I
>> agree that we need to perform editorial surgery to clean this up,
>> because it is currently misleading.
>>
>>
>>     primary event and its extensions".
>>
>>
>> Mike> What’s being represented is a set of related events from the
>> same issuer.  Again, the extensions language is misleading, and needs
>> to be fixed.
>>
>>
>>     a particular SET was delivered to the correct subscribing party"?
>> Mike> We do have an unambiguous manner of distinguishing SETs from
>> other JWTs – the inclusion of the “events” claim.  OAuth access tokens
>> are, by definition, opaque, and completely outside of our scope of work.
>>
>>
>> Mike> We should stay completely clear of specifying what applications
>> and protocols must do with SETs.  It’s up to them to profile SETs so
>> that the application’s privacy and security properties are maintained,
>> which will differ between applications.  Just like whether “alg”:
>> “none” is appropriate is a protocol/application decision, it’s also a
>> protocol/application decision whether encryption is needed, depending
>> upon the context.
>>
>>
>> Considerations sections, listing things that protocol/application
>> designers should consider.
>>
>>