Security Events
charter-ietf-secevent-01

[Ballot comment]
I'm sorry for not noticing this sooner. In

- A method for delivering events using HTTP POST (push)

POST is an HTTP "method", but I bet that's not what you mean by "method" in this bullet - but either way, this is confusing. Could this be "mechanism", or, really, almost anything that's not "method"?

[Ballot comment]
Shouldn't the method for delivering the event be a secure method?

How about adding on a sentence after the following section:
The Security Events working group will produce a standards-track Event Token
specification that includes:
- A JWT extension for expressing security events
- A syntax that enables event-specific data to be conveyed
This Event Token specification will be event transport independent.

Adding: A secure transport will be specified.

[Ballot comment]

I have a few things I'd like to see improved before this WG is
approved. It's fine that that's done during external evaluation
though.

- What is an "identity related protocol"? I think it'd be way better
to be as specific as possible about what's meant here.

- I'm concerned that this bit is overly generic and will lead to
delays. It'd be better if the set of relevant events was better
characterised in the charter before we start I think.

  "The Security Events working group will produce a standards-track Event Token
  specification that includes:
    - A JWT extension for expressing security events
    - A syntax that enables event-specific data to be conveyed"

- I agree with Kathleen that only secure transports make sense
here and that can and should be in the charter.

- I think there's some missing text on privacy - we don't want this
work to end up helping e.g. advertisers track people across web
sites. And we don't want exchange of event information to lead
to two co-operating partners being able to build up databases of
each others' employees. I'm not sure what'd be right to put in
the charter though.