Skip to main content

Minutes interim-2020-oauth-09: Mon 18:00
minutes-interim-2020-oauth-09-202005181800-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2020-05-18 16:00
Title Minutes interim-2020-oauth-09: Mon 18:00
State Active
Other versions plain text
Last updated 2020-05-18

minutes-interim-2020-oauth-09-202005181800-00
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.