Hi Joseph,
On Fri, Jan 20, 2023 at 6:10 PM Joseph Salowey <joe@xxxxxxxxxxx> wrote:
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.
Thanks! Glad to hear that. I hope it will be useful as well.
I had a few questions/comments.1. Interaction with private_key_jwtWhen 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?
The DPoP proof JWT and the private_key_jwt JWT ultimately use pretty similar mechanisms so it's not obvious that DPoP is materearly better. Supplementing the private_key_jwt somehow with DPoP could be done but I don't believe it'd add much value.
Using DPoP with/for client authentication to the AS was proposed at one point during an interim meeting a while back (https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf slide 19) but it was more about trying to simplify some redundancy. There wasn't sufficient interest in pursuing it at the time anyway.
OAuth client authentication is not a defined thing for calls to resource servers (aka protected resources). As I struggle to find words to reply here and reread your question/comment, it seems like maybe that (client using something like private_key_jwt making protected resource API calls) is the case you are referring to. That's "off-label" use of private_key_jwt, which I certainly don't endorse but isn't a defined thing and thus not in scope for DPoP to say anything about. Something like the client credentials grant with private_key_jwt and DPoP binding the access token might be a better and standard supported way of accomplishing the automated client to service w/ pre-configured public key case. FWIW.
2. Confirmation MethodsIs the goal of section 6 to define mandatory to implement conformation methods?
The goal is to provide an interoperable way to convey the binding of the access token to the DPoP key for both token introspection and JWT formated access tokens. That's done with the jkt conformation method
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.
The confirmation method in RFC8705 is a hash of a certificate so isn't applicable/appropriate in the context of DPoP that's using bare JWK formatted keys.
I may have a few additional editorial comments as I go through the draft that I will pass along.
Cheers,Joe
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
