OAuth Meeting Minutes - 18. May 2020 Agenda Demonstration of Proof-of-Possession at the Application Layer https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Attendees 1. Brian Campbell 2. Dominick Baier 3. Filip Skokan 4. George Fletcher 5. Jim Schaad 6. Justin Richer 7. Hannes Tschofenig 8. Yuki Goto 9. Aaron Parecki 10. Tim Cappalli 11. Andreas Falk 12. Daniel Fett 13. Mike Jones 14. Janak Amarasena 15. David Waite 16. Dick Hardt 17. Anthony Nadalin 18. Peter Yee 19. Vibro (?) 20. Vittorio Bertocci 21. Michael Richardson 22. Thanuja (?) 23. Jared Jennings 24. Denis Minutes Brian went through his slides,which can be found at: TBD. (IETF website has some problems; failed to upload slides repeatedly) Link to the draft: https://tools.ietf.org/html/draft-ietf-oauth-dpop-00 George: OpenID Connect uses dynamic client registration with client credentials. Would you use another set of credentials with DPOP in such a scenario? Brian: The client authentication is currently independent of the DPOP usage. The draft is silent on the re-use of any keys. George: That’s fine but it is a lot of weight. George: We need to talk about the roll-out strategy Brian: We should discuss this topic at some point and it is in the slide deck. Filip: I agree that most RS will most likely accept the DPoP token as a bearer. If it uses the token type as a lookup then it will most likely fail. It is not a seamless transition. Brian: I agree; it is more seamless with respect to the resource servers and the clients will have some “smarts” to make this work. Filip: The client needs to know that the API does not support DPoP. There has to be some sort of meta-data or some form of signaling. George: I am worried about having the client know about what to do with which resource server. The hope was that the client is dumb. This adds a significant amount of smarts to the clients. Cannot we have the RS accept both types of tokens? I worry about the client having todo the switch. Brian: I am not sure. Justin: The client should never do a downgrade from DPoP to a bearer token. It should be the role of the RS. The client is not expected to be smart. Regarding the jti: the recommendation of -01 is good. Most of the concerns could be in the security consideration section. The fear that I have to remember the jti ever transmitted is unjustified. Regarding the client metadata and the signaling: we need answers but I don’t have them. There is probably no clean way to signal the clients capabilities and intents. Brian: My thought on the client to do the right thing in terms of getting things to work (interoperability) and counting on the RS to correctly make decisions regarding security. Justin: A client getting a DPoP token always has to send it as a DPoP token. The RS can then make the decisions. (George agrees with this approach; do does Daniel) Brian: The thinking here is that there is a world where the RS is completely ignorant of DPoP tokens and wanting those to still work. This is the pressing goal for me. Justin: There is too much black magic in that approach. Having the RS just check for the token type to make a different decision is important and only a small code update. Brian: I need to think about this a bit more but I believe I disagree.