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