Minutes interim-2020-oauth-02: Mon 18:00
minutes-interim-2020-oauth-02-202003091800-01

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.

Recording link:
https://ietf.webex.com/recordingservice/sites/ietf/recording/play/3375c9db84ed49759392c63740bc4732