# OAuth WG Interim Meeting - DPoP ## Date 15 March 2021 # Notes **Note takers: Hannes and Tony** ## Topic <b>OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)</b> Presenter: Brian Campbell Slides: [DPoP Slides](https://datatracker.ietf.org/meeting/interim-2021-oauth-01/materials/slides-interim-2021-oauth-01-sessa-dpop-01) Rifaat starts the meeting with an outlook of the upcoming virtual interim meetings. Brian goes through his DPoP slides. He mentions the open issues, which can be found in the slide deck - slide #14ff. Freshness & Signature Coverage: Mike looked at the internal Microsoft implementation, which aims to prevent malware from minting tokens, and it offers a server provided nonce. The nonce is provided by an "unauthenticated" response, which includes the nonce. A new nonce is provided in the 200 OK. The first nonce requires an extra roundtrip. Mike will find out the details and will send the details to the list. Justin to talk about the OAuth PoP draft and HTTP Signing. He believed that the DPoP is (deliberately) a point-solution. Are there easy bits in DPoP that can have positive contributions? Brian talks about the different approaches to address the freshness properties, which triggered a response from Francis Pouatcha on chat saying "Incorporating a hash of the request in the proof might solve this problem (or atleat limit it down to rplay)" Justin (on chat) responsed that "the problem isn't the hash, the problem is normalization of the request so that the hash is at all meaningful. This is what we're trying to do with HTTP Message Signatures. DPoP takes a decidedly limited approach to this, with a specific set of tradeoffs." Francis says "This is what was solved with SHIMP. This will be a meaningfull complement to make it solid enougth for the interdented purpose. Without being a replacement for HTTP Signature." Francis believes that DPoP needs the extension offered by SHIMP. SHIMP is Simple HTTP Message Integrity Protocol. Brian does not believe SHIMP provides any benefits for this specific problem but adds lots of complexity. Justin: +1 to what Brian says. The problem with the HTTP message signing is the normalization. My preference for DPoP to have it be very simple access token hash. This does not get into the normalization of the message. I am working with Annabell on the HTTP signature spec. I hope to get an RFC this year. Francis: DPoP should be by no way a replacement for HTTP signing. Agrees with Mike about the nonce aspect. Hannes: Will HTTP signing be finished ealier than DPoP Justin: General purpose HTTP signing has lots of corner cases. DPoP should remain simple & extensible. He sees DPoP as a building block that offers Here are my backup notes: Overview New header added – DPOP Proof, to provide a POP, it’s a JWT, only supports asymmetric key pair Crypto agility provided. Negotiation exchange challenge/response messages – errors and negotiations Path forward for open issues No new draft since last meeting, there are a few open issues 1. Refresh issue, claim that there is a chance that the proof can be replayed as there is no timeliness since there are sever input. Mike J. says that their implementation includes sever nonce, the nonce can be reused, there can be a new nonce in the 200 response, thus 1 extra trip for the first nonce and no additional after that. Brian asked how that the nonce was conveyed, Mike will get back. a. Maybe its OK as it is? Maybe suggest key rotation that will be sufficient. b. incorporate a hash of the access token c. Allow server to supply nonce (like what Mike had suggested) Brian, way forward is editorial changes, that describe the attack and using key rotation and leave it as that. DPOP should not be a replacement for http signing. There has been progress in HTTP signing. DPDP was meant to be a quick solution. DPOP should remain simple and extensible. There is value in keeping DPOP. Justin says its ok to take DPOP as is with the editorial changes and just publish. Brian is maybe ok in adding a hash as a compromise to get this out the door or do nothing. Brian things we are close to publish and have something useable with the caveats Dennis made some comments, should include audience restrictions Poll, leave as is (with editorial changes, no protocol changes) – 8 , add mechanism - ? No consensus Consensus bias – add the JWK token in the header, this would be a change in the protocol, this this would not be increasing the size, just moving the JWT. Justin does not like this as it changes the parallelism of the protocol ## Attendees * Rifaat Shekh-Yusef (chair) * Hannes Tschofenig (chair) * Brian Campbell (Presenter) * Justin Richer * Torsten Lodderstedt * Vittorio Bertocci * Aaron Parecki * Bjorn Hjelm * Mike Jones * Dick Hardt * Filip Skokan * Michael Palage * Pedro do Vale * Anthony Nadalin * Denis Pinkas * Brian Campbell * Francis Pouatcha * Jon Meyler * Dario Savarese * Phil Hunt ## Document [IETF DPoP Draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) ## Recording https://ietf.webex.com/webappng/sites/ietf/recording/02031991f24841dabade66e5ba73a72c/playback ## Next Interim Meetings * March 22 OAuth 2.1 – Dick/Aaron https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ * March 29 Client Intermediary Metadata – Aaron https://datatracker.ietf.org/doc/draft-parecki-oauth-client-intermediary-metadata/ Multi-Subject JWT – Rifaat https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ * April 5 RAR – Torsten https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ * April 12 Security BCP – Daniel https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ * April 19 Identity Use Cases in Browser Catalog – Vittorio/George https://datatracker.ietf.org/doc/draft-bertocci-identity-in-browser/ * April 26 TMI BFF – Vittorio/Brian https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/