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.]