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