Skip to main content

Minutes IETF99: secevent
minutes-99-secevent-00

Meeting Minutes Security Events (secevent) WG
Date and time 2017-07-18 07:30
Title Minutes IETF99: secevent
State Active
Other versions plain text
Last updated 2017-07-18

minutes-99-secevent-00
Security Events WG IETF 99
===

Chairs: Yaron S & Dick H

- Chairs intro to secevents architecture and documents
- Mike Jones presenting draft-ietf-secevent-token
  * spec is functionally stable for a while
  * walk through changes since IETF98
    + protecting against confusion with id-tokens
    + signature validation profile
    + explicit typing
  * Time for WGLC?
  * Marius and MikeJ - discussion of issues around mismatch and key resolution
    + a parser/validator must rely on profile understanding
    + yaron - a common dispatcher impossible?
    + mike: some common processing framework may be possible, but key mgmt is
    tied to profile + mike & leif: there are use-cases of connect that profile
    key mgmt + marius: still possible to do a baseline connect profile +
    marius: we are writing a document that won't work for multiple usecases +
    mike: I don't agree - the document is flexible enough + mike: profiles will
    get written - eg for connect with the standard jwt key mgmt scheme, maybe
    in IETF or elsewhere + mike: what we do is aligned with the jwt approach:
    profiles are necessary & this is a good thing + chair (dick): summarizes
    discussion - suggests marius expand on his argument list + william dennis:
    events claim allows us to distinguish between jwts, need to get this out
    asap + dick hardt (participant): shared code is important, worried about
    profile mixup - which profile is associated with a SET must be clear
  * Chairs asks for how many have reviewed the document (about 10)
  * William Dennis: we should talk about how to get to WGLC
  * Chairs hum for WGLC - clear consensus in the room
- Marius: SET token delivery over HTTP
  * Marius summarizes HTTP delivery mechanism
  * Leif: make 'dup' a non-error - it should just be ignored
  * Yaron: questions about multiple vs single events in push/pull, multiple
  events should not be a problem for push * Marius: it will make life harder
  for the recipient - need to keep track of state * Yaron: move complexity to
  pull * Marius: yes - also poll is more firewall friendly * Dick & others:
  firewall issue is a real one * Annabelle Backman (AB): need clarification of
  what action is needed based on each error * Marius: logging is often the only
  thing you can do * AB: clarify what the sender should do * AB: is both pull
  and push MTI? necessary? * AB: pull is a lot more complex - maybe not worth
  while * AB: 'more available' parameter adds a lot of complexity - don't see
  the value * Marius: sorta agree... * TonyN: like to see two options in as
  single draft - pull and push should be different * Yaron: optional hurts
  interop
- Chairs: call for WG adoption
  * clear consensus in favour
- AB: Management API for Event Streams
  * AB walkthrough of draft
  * Yaron: a directory endpoint would be useful
  * Yaron: if we wind up with an explicit profile claim, this should replace
  the list of individual events * Marius: SCIM vs this? * <missed some of the
  discussion with Kathleen on tooling>
- Chairs: hum for adoption at this tim
  * no clear consensus
- Chairs discuss whether to continue work on this
- Chairs: is the mgmt api in scope for the WG
  * strong consensus for "in scope for WG"
- Marius: RISC use cases
  * walkthrough of RISC use cases draft
  * LJ: suggest include complexity considerations of push vs pull for the case
  when IdP need to register with the RP as an Oauth2 client * Yaron: clarify
  the term "security as a service" vs "identity as a service"... discussion
  about delegation mechanism etc
- TonyNadalin (TN): SCIM use cases
  * walkthrough of the SCIM usecases draft
  * Yaron: missmatch in terminology needs to be fixed by both author teams
  * MikeJones: is the use of SCIM as control plane implicit?
  * TN: yes
  * AB: what about mobile push? use SMS?
  * TN: yes - we have usecases for events over SMS and those should be defined
  outside a SCIM context