Minutes IETF101: secevent
minutes-101-secevent-00

IETF 101 London Friday 23 March 2018 9:30 - 11:30

Recorded meeting: https://www.youtube.com/watch?v=r0hbpQqsN6s.

[Yaron] (WG status update, agenda bashing)
[Annabelle] asks for 10 minutes for discussion

[Mike] (presents Security Event Token draft update)

[Annabelle] (presents SET Token delivery using HTTP draft)
[Mike] Microsoft needs for both POLL and PUSH
[Phil] Redefining smth in HTTP may cause problems
[William] Return codes are only for browsers to display messages for users
[Phil] It's needed for resending in case of error (?)
Later edit by Phil: There was some other discussion, I believe it was about
status 400 which informs the client of JWT-related errors and that using status
403 would not let clients be able to differentiate between authz errors and JWT
errors. [Annabelle] What is MTI - push or poll? [Phil] With PUSH  happened
immediately... [Leif] What is MTI for server or for client? [William] Each
option has an explicit use case [Yaron (as chair)] We need to have only one
preferred option [Phil] There are very different cases [Phil] Push is simple,
but in terms of applicability it's not a long term use case [Annabelle] There
use cases for both [Phil] Take two and then abandon one [William] Why does the
chair require a single MTI [Leif] It's from chair's experience, WG consensus
needed [William] We have use cases for both [Mike] Procedurally it's better to
keep both methods in one draft [Yaron] Having two methods complicates the
description which method is for which situation etc. [William] Still have
interoperability issue for receiver [Yaron] Need to resolve this [Leif] WG
should decide [Ben as AD] If the WG doesn't select a single method the IESG
would probably object [Annabelle] SET will probably be profiled for different
use cases [Yaron] Is going to make hums about selecting a single delivery
method and whether we need to split the draft [John] What is hum about -
mandatory to implement or to deploy? [Leif] We should analyze scenarios
[Annabelle] The protocol are unidirectional, so MTI for transmitter/receiver is
problematic [Justin] No negotiation, either it is or not, MTI for the receiver
is dictated by what the receiver supports [Phil] They both must be able HTTP,
the roles can be changed [Leif] Confusion between MTI and to deploy, a good
question - select MTI for transmitter [Annabelle] Every transmitter should have
both [Tero] Minimal implementation requires one, bigger may have both, single
MTI is better then two for limited devices [Annabelle] IoT implementers have
special requirement [William] They are application specific, we expected
profile this [Yaron] Hum if we need a single MTI for transmitter - silence
Later edit: Clearly no support for a single MTI. [Justin] Hum must be for
multiple discrete options [Yaron] Hum on use cases for two methods - some hums
[Yaron] Hum if both should be MTI - some hums [Yaron] Hum if should not specify
MTI - some hums Later edit: room was split between two MTIs and no MTIs.
[Annabelle] We should split the spec [Justin] Agree to split the spec [Justin]
I hummed for both MTI for transmitter, because they are not usually constrained
[Annabelle] SET is possibly to be used w/o HTTP, this is only MTI for those
using HTTP; both MTI is problematic because implementers will do unnecessary
stuff [William] If both are MTI, we need 2 specs [John] Splitting the spec is
the best way [Mike] If split, then the information for developers will be
duplicated [Ben] Why single document better (?) [Mike] My experience with JOSE
[Annabelle] Significant overlap between documents is SET, otherwise little
commonality Later edit: existing editors volunteered to take Push-specific doc,
Annabelle and Mike volunteered to work on Poll. [from jabber] Little
commonality between two methods [Mike] We'll do both, we have use cases for
both [Yaron] Hum if split documents - some long hums [Yaron] Hum if one
document - some hums [Yaron] Room is in favor of splitting the documents
[Yaron] Wrap up: no MTI, split the document into two, transmitter implements
either or both

[Annabelle] (presenting Subject Identifier Types)
[Mike] 3rd party specifications cannot establish IANA registry
[Leif] IANA Expert?
[Ben] FCFS, doesn't need Expert, or specification required
[Leif] I support this idea
[William] I also support
[Yaron] Any objections to adopt this document? No objections, publish as WG
document

[Annabelle] Expiration ("exp") claim is not recommended; however it has some
value [Mike] It's a layering violation; problems with caching [Annabelle] We're
not talking about caching, you don't want to grow anti-replay database forever,
having expiration helps [Phil] The past doesn't expire, it's up to receiver how
to use it, caching doesn't make sense [Yaron] What about replay protection?
[Mike] JTI helps to detect replay (?) [from jabber] Transport should deal with
replay [John] Expiry is expected to mean that token should not be processed
after that, it's not an indication that information is no longer valid [Mike]
It must not be mandatory [Annabelle] Currently the draft says it's not
recommended [Mike] We have to allow it to be optional because of the need to
distinguish from access tokens. [Ben] Some use case when processing expired
token (?) [John] Have an explicit expire for JTI, there are other solutions
[Phil] I prefer to add a new attribute to SET, not changing ... [Yaron] The
document in LC, smaller changes are OK without blocking the doc's progress.
[Phil] Replay and caching are different for PUSH and POLL, prefer to see in
HTTP header [Brian] Expiration is not necessary, receiver has policy to follow
[Annabelle] No-one is advocating using exp for caching [from jabber] JTI
expiration belongs to JTI not to transport [Yaron] We're not ready to have hum,
room thinks there is an issue, please work through it on the list.

[Phil] Presents his SSTP Delivery draft - symmetric transport protocol,
parameters used in requests and response are same [Phil] We would change
optionality from two methods to a single one, may be a compromise [Yaron] The
protocol was only published yesterday, so we are not ready to discuss now.

[Meeting adjourned.]