The meeting started at 13:31.  Note Well was shown.

John Bradley reporting on meeting with AD about HTTPS draft.
Mike Jones: He's requesting clarifications of non-normative parts?
JB: Yes.
JB: We're in good shape. Hopefully we can get it through IESG by the end of the year.

Leif: More Q about core documents?


Nick talking about TB negotiation in TLS 1.3
(draft-nharper-tokbind-tls13)
Leif: Where do we take this?
NH: My suggestion is that the WG adopt this either as-is or merge with the (already accepted) 0RTT draft
MJ: Is it ever meaningful to implement one without the other?
NH: yes, you can dislike 0RTT.
Andrei Popov: TB with 1rtt makes sense. TB with 0rtt has weaker security properties. Not sure it makes sense. I'd like to keep the drafts separate.
Humming:

    Like the idea of adopting this (strong hum)

    Oppose (crickets)

    Don't know (crickets)

Will confirm on the list that we want to adopt this.

Brian Campbell on HTTPS TB with Reverse Proxies
(draft-campbell-tokbind-ttrp-01 - started 13:42)
TTRP = TLS Terminating Reverse Proxy
Stefan Santesson: One way of making this fail-safe is to HMAC the data between the RP and the backend server with a shared secret. Have you considered this?
BC: There's a wide variety of ways, but it's a broader problem, so there should not be a one-off solutiong for this draft.
Stefan: Seems to me this is the wrong conclusion. You are specifying this header, and you have an opportunity to make this safe - to prove that it originates from the reverse proxy.
BC: I'm looking to avoid setting shared secrets between RP and backend server. Don't want more key management issues.
Leif: Some people suggested making a generic mechanism. The consensus last time was that we should not make a one-off solution for this here. Somebody should make a generic mechanism (but nobody has done so yet)

BC: -01 only supports provided and referred binding types. What about others?
MJ: The TB doc and TB-HTTPS doc can communicate for 256 IDs. All but 0 and 1 are thrown away in this draft.
BC: You're right. We'll toss any new. 
MJ: That is not a good protocol design
BC: It's a good design
MJ: If you have something with known audiences, you're going to need different bindings for different audiences.
BC: I'd like to know if this is an extension that we want to have
MJ: it's throwing away information. You should not assume they won't be used.
BC: I think it's simplifying
NH: There are also extensions (over and above the 245 unused code points). I think it's acceptable to have a protocol that covers only existing use cases...
MJ: ...today
NH: Yes, today.
MJ: I want it to be defined how this additional information is passed.
Leif: There is a difference between makind a 1:1 representation and making a representation for the majority case with a place for extensibility. 
MJ: If the goal of your draft is to enable communication, you need to define how you represent additional binding types.
JB: Since we don't know what they are, are there specific rules for how the TTRP needs to extract the data or are they all the same with different numbers?
MJ: Yes
Vinod: ...
MJ: I'm fine with whatever syntax you want. We shouldn't be throwing away information. That's my request
Leif: Can you sit together and come up with some lines defining this?
BC: I'd like to understand the use case.
MJ: Like the Microsoft graph where things come in at different TLS connections. 
JB: Good to document this use case. Who signs what and what does it mean.
MJ: I may be able to do this with Tony.  I can work on a syntax proposal with Brian this week.
*** MJ and Brian will offer a concrete proposal on the list.

Piotr Sikora: Regarding token binding types: if we want to add new types interoperability is not defined
MJ: not the job of this document.
Piotr: But interoperability is not (yet) defined.
Vinod: Our implementation is roughly the same as this except for the header names.  Will move to the standard headers
Andrei Popov: Entirely possible that future docs will define new bindings, but they will also define TTRP processing. Then we have issue with discovery. 
BC: Depends on processing rules.  If new bindings follow same processing rules, no problem. Otherwise...  We will work on it.
BC: Hoping for broader implementation interest as things progress.
Leif: Rough timelines? WGLC by London?
BC: Perhaps around London.

====
Leif: same question for 1.3?
NH: Should be ready in London for regulsr 1.3.  0rtt might take longer.
====

(some shuffling of presentation computers around 14:20)

Attested TLS Token Binding
(draft-mandyam-tokbind-attest - 14:21)
JB explains: attestations at the token binding layer. 
JB: has anyone looked at this?
(2 hands come up - Tony and Brian)
JB: The notion may be useful for web authorization. 
AP: Great interest in some teams at Microsoft. The strength of the key depends on the strength of the key storage
JB: General idea has some support, but need to wait to know if *this* is the one.
JB: Will not call for adoption now.  Will do so if there's general positive feedback.

*** Asking for Open Mic issues.

Jeff Hodges: Anything said about the HTTPS draft?
JB: We've discussed with AD and he wanted to know what constraints. We'll add some text for what kind of federated protocols we intend.
JH: He will push it?
JB: Yes, because of our agreement.
JH: I think he should have sent it to the list.
Leif: He was not sue if his comments were legit.
JH: Any changes need to be on the list. Also John, Andrey and my comments.
Leif: Sure. Nothing to hide.
JH: That's fine. If there are any notes on the discussion, please send to the list.

*** And we're done at 14:28