These are last call comments for draft-ietf-oauth-dpop-12.
First, I want to thank the authors and participants for working on this document, its good to see it and I think it will be very useful.
I had a few questions/comments.
1. Interaction with private_key_jwt
When I first started to look at the document I got a little depressed because it brought up the private_key_jwt authentication mechanism which always makes me a bit sad because while it is an authentication mechanism of sorts, it's a poor proof-of-possession mechanism. It's really a self-signed bearer token that's prone to many of the problems described in the objectives section. This seems to be widely used as an authentication mechanism especially in cases where an automated client talks to a service using a pre-configured public key. The document declares authentication out of scope, but I didn't let myself get too despondent, because it seems that DPoP could be used to improve the private_key_jwt client authentication mechanism with a better POP. But from the document, I'm not quite sure how as the document focuses more on public clients instead of confidential clients (I think that is the right terminology).
If I'm reading the document correctly, I think the client could include a DPoP Proof JWT header in the token request using the same key contained the private_key_jwt. The token service could then evaluate both the private_key_jwt JWT and the DPoP proof JWT before issuing an access token and refresh tokens to supplement the authentication provided by the private_key_jwt with a better PoP. Is this correct?
If so the document should mention this use case as I think it would improve the some common practice. (I can submit some text if I'm on the right track). If not is there another DPoP mechanism that should be used to supplement the private_key_jwt with better PoP?
2. Confirmation Methods
Is the goal of section 6 to define mandatory to implement conformation methods? If it is, it should say so. I think the paragraph might be a little clearer if it used the term key confirmation method in section 6. For example, "Other key confirmation methods, such as those defined in [RFC7800] and [RFC8705] may be used per agreement between the authorization server and the protected resource, but are not detailed in this specification.
I may have a few additional editorial comments as I go through the draft that I will pass along.
Cheers,
Joe
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
