Minutes IETF102: secevent
minutes-102-secevent-00

Meeting Minutes Security Events (secevent) WG
Title Minutes IETF102: secevent
State Active
Other versions plain text
Last updated 2018-07-31

Meeting Minutes
minutes-102-secevent

Security Events

IETF102, Montréal

Friday

Abandon all hope, ye who enter here.

# Chairs Overview

SET published as RFC8417
Used by
        - OIDC Back-channel Logout
        - RISC

# Push-based HTTP delivery
        Annabelle Backman

Formerly "secevent-delivery"
        - no normative changes

Uses 202 Accepted because processing might not occur synchronously

Error responses are 400 w/json error objects
        - Consensus in London to not use http status codes

Implementations by Google and Amazon (in progress)

> HTTP "push" is an overloaded term
        - HTTP/2 "server push"

# Poll-based HTTP Delivery
        Mike Jones

Extracted from delivery spect

## Issues

1. Terminology mismatch with RFC8417

2. Normative text is ambiguous (w/o examples)

3. Duplication of information

"jti" sent twice
        - In envelope and in SET itself
        - Could allow error cases (in case of mismatch)

> Annabelle: rationale was to allow easy filtering based on jti

> Tony isn't happy about changing this because he doesn't want to change
code based on a draft

4. "maxEvents" sometimes defaults "returnImmediately" to be ignored

Should be orthogonal

> Annabelle: there shouldn't be undefined scenarios

> Mike: not changing the output of the spec, define it explicitly instead of
using "ignore"

Mike to propose text

5. "SETs MAY be reissued"

Unclear whether and how SETs can be reissued

> Annabelle: we need a mechanism to say whether a SET was received or not

>> Editors to define: a state management section would be helpful to
remove this ambiguity

6. Spec says there should be a mechanism for loss notification but doesn't
define one

> Tony: there are many different ways to do this and we don't want to
specify it

> Annabelle: there would be value in specifying a programmatic way to do
this (for interop)

7. No registry yet

8. A bunch of grammar and editorial issues

## Duplication between Push and Poll

Options:

- Move to three specs
        - One for common pieces
        - One for push
        - One for poll

- Move to one delivery spec
        - Have it "either A or B"

> Justin: implementers will want to sit down and read one document with
everything they care about

> Annabelle: it's possible to have abstractions in one document and other
details in another spec

> Ben: you can only have things like registry creation in a single document,
could leave that decision for the end

- Refactor to make later document reference earlier document
        - For example: Push spec defines everything, Poll spec references Push
        spec

> Phil: why not use SSTP?

> Annabelle: that would make life worse for everyone

>> Hum: does the group want to go to a "single delivery mechanism"?

  - Consensus in the room is to keep multiple mechanisms but discussion will go
  through the list

> Justin: having Push have core content and Poll is reference is fine with
clear examples

> Annabelle: will take an action item to put together a cleaned-up version
of -01 for Push to go over with mike

> Tony doesn't like it, there would be no synchronization

> Ben (as AD): there would be absolutely synchronization

> Annabelle: believes -01 will address these concerns

# Subject Identifiers for SET
        (Annabelle Backman)

Originally strated as an ID, went to RISC, came back to SECEVENT

Submitted as a working group document

"sub" isn't optimal for some scenarios
        - Works for a lot of them but not everything (complex, format, etc)

Create a "subject" object, with subject identifier types

Email, phone, iss-sub, id-token-claims

id-token-claims
        - Can send all of the claims inside of the id token since recipient
        might use any of them - Originated inside an id token

> Leif: why not use URI's

> Justin: you end up punting to a URN registry if you do that

> Yaron: does the semantic need to be specified here?

> Annabelle: there's room to be clearer about the semantics

> Dick: the use case is in OIDC with a set of identifiers

> Ben: what page of registries should it go under (probably SET)?
        - Reasonable to ask the document registering the claim to be very clear
        about semantics of the subject identifer type

> Leif: short names get unreistered and leak

> Brian: short names for registry, URI for unregistered claims

>> Leif puts his thumbs in the air

> Brian: size is not a huge thing
 - "subject_type" could be just "_type"?

> Annabelle: could be used to indicate other kinds of subjects (like
token_subject)

Could we have single/multiple semantics like JWT audience?
 - Discussion to move to the list