Participants: - Roman Danyliw - Torsten Lodderstedt - Travis Spencer - Aaron Parecki - Ben Kaduk - Brian Campbell - Cigdem Sengul - Daniel Fett - David Waite - Filip - Jim Schaad - Justin Richer - Marco Tiloca - Matthew de Haast - Michael Peck - Mike Jones - Phil Hunt - Hannes Tschofenig - Joseph Heenan - David Waite - Bjorn Hjelm - Cristofer Gonzales - Tony Nadalin - Vittori - Rifaat
Notes: Rifaat showed the list of documents relevant for the discussion Several documents are relevant to this discussion, including https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 https://tools.ietf.org/html/draft-richanna-oauth-http-signature-pop-00 https://tools.ietf.org/html/draft-cavage-http-signatures-12 https://tools.ietf.org/html/rfc8613 https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07 https://tools.ietf.org/html/rfc7800 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33 https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 Brian went through his presentation. Hannes notes that OSCORE, a solution presented from the ACE group, is missing in the list. Brian responds that nobody in the OAuth world cares about OSCORE. Discussion about whether the ACE group uses the key distribution parameters for use with HTTP. Jim believes it does. Justin explained the work Annabelle was doing. Rifaat asked whether PoP + HTTP signing will solve his problem. Brian does not believe that HTTP signing solves anything and if it gets done then it will take a long time. It also does not cover the refresh token case. HTTP Signing is a lot about HTTP canonicalization. It will allow for signing and HMAC computation over the resulting string. Roman: For some HTTP signing may still be too expensive? Justin: Yes, we are starting with the cavage-http-signatures draft. There are some big problems with it. For example, what parts are signed. Depends on we sign it will be necessary to re-create the signature with every request. We need a profile for OAuth use to indicate where to send the token and what to include in the signature. Brian: I believe that every request should require a new signature. Finding out whether a signature can be omitted will be prohibitive. Justin: DPOP signs only a small number of elements and does not require HTTP signing. Justin: For the HTTP signature solution we are planning to offer a symmetric and an asymmetric key version. Justin: DPOP is a key presentation for single page application and it can probably be used with other apps too. We are going to have a PoP solution with an generic HTTP message mechanism. Torsten: How many deployable solutions do we have? Brian: We have probably 3 or 4 solutions. Justin: In terms of implementations we have 3. ?: What if we split the key distribution from the HTTP signing? Justin: That's how we wanted to do the generic approach. It is how we do it with HTTP signing. ?: What are you signing in the HTTP message? Justin: I believe if we have generic HTTP signing then we could re-use it with DPOP. Mike: Microsoft is internally deployed the old HTTP signing. The reason is that it is stable (although abandoned). Our product groups that is simple, like DPOP. John and I talked at the last IETF on how we wanted to do symmetric DPOP. Inherently you have to do a key distribution step. I would like to see the DPOP draft adopted as a WG draft (recognizing that it may be revised to include a symmetric key solution). The working group needs to make a decision on how to add symmetric key distribution. Filip: We would also like to see adoption. Roman: three options 1) Stay with POP key distribution 2) DPOP (as is) 3) Use ECDHE exchange from Neil Brian: We could add (3) to (2) but it would be difficult and prohibitively difficult. (3) should its own thing. Or maybe if the push for performance improvements is so big that we need to jump straight to (3). There is the risk of too many options. Torsten: Is the concern that (2) is too slow? Filip: At the last meeting there was a concern from AWS that signing of each request is prohibitively complex. But (2) works in my deployment. Mike: It depends on the use case. Phil: How does TLS 1.3 alter some of the requirements? What about the HTTP group doing the work on signing? Brian: I don't think there is any dependency. Justin: I do think that there is room for both. I don't think DPOP should be stretched to a generic solution and it isn't. It is a clever hack for a specific use case. Brian: I wouldn't agree on the term "hack". Phil: I am concerned that the market tries to apply a limited solution to everything. Justin: That's why we need to standardize many solutions. DPOP makes a lot of sense as it is today. If you can layer a symmetric key solution then that's fine too. I think AWS should not use DPOP. Phil: I think we need to make clear that PoP is orthogonal to message signing. Saying that those things are separate going forward. I am worried that we are repeating the cycle for the 3rd or 4th time in 10 years. Mike: The market left OAuth 1.0 because of HTTP signing interoperability problems. Phil: When I was looking at MTLS there was a similar perception about whether it is actually needed. There are two extreme: (1) sign everything and encrypt everything and then (2) just use the existing stuff. Mike: I like DPOP because it does very little. It just as little as possible to demonstrate PoP for the token. Phil: Yes, I like that. Brian: There is certainly opportunity in the draft to make the draft clear. It is certainly for more use cases than for SPA-type apps. Rifaat: Any other comments? Next step is to take it to the list. There is also another question about the use of symmetric key in addition to asymmetric key. Roman: We will only do a call for adoption of the DPOP solution and not for any other option. Rifaat: Yes. Rifaat: Neither I nor Hannes will be at the Vancouver IETF meeting. The following participants are planning to be there: Justin, Aaron, Mike, Brian, David, Spencer, Tony, Matthew. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
