Hi Brian, Just wondering if there's still a chance for this to be addressed in 04? I could try preparing a draft PR if that helps.
On a related note, are there any recommendations on the contents of the "error_description" WWW-Authenticate attribute? For example, our prototype DPoP implementation for Keycloak recognizes the following error conditions: - DPoP proof decoding failure - Invalid DPoP signature - Invalid or missing "typ" in DPoP header - Unsupported DPoP algorithm - No JWK in DPoP header - No public key in DPoP header - Private key is present in DPoP header - DPoP mandatory claims are missing - DPoP HTTP method/URL mismatch - Malformed HTTP URL in DPoP proof - DPoP proof has already been used - DPoP proof is not active - No access token hash in DPoP proof (when used with an access token) - DPoP proof access token hash mismatch (same) Would you recommend to a) provide detailed info (above) in error_description, b) provide generic "DPoP proof missing or invalid", c) omit error_description? Thanks, Dmitry On Tue, Aug 10, 2021 at 12:58 AM Brian Campbell <bcampbell= [email protected]> wrote: > Hi Dmitry, > > I think you are right that it's probably worthwhile to allow for a > distinction in a protected resource error response. I'm inclined to say > that a new error code such as "invalid_dpop_proof" to use with the 401 > response containing the DPoP WWW-Authenticate header is the most > straightforward way to accommodate it in the document. I'll look to add > that, probably somewhere in section 7 > <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html#name-protected-resource-access>, > in the next draft revision. > > > On Thu, Aug 5, 2021 at 8:50 AM Dmitry Telegin <dmitryt= > [email protected]> wrote: > >> Hello, >> >> When a protected resource is accessed using DPoP proof + DPoP-bound >> access token, either of those could be invalid. Should we make distinction >> between these two cases? I.e. should the response always be a 401 >> Unauthorized with WWW-Authenticate: DPoP ... error="invalid_token"? or >> could we use error="invalid_dpop_proof", similar to token request? or maybe >> even 400 Bad Request? >> >> Regards, >> Dmitry >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > *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.*
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
