The following is my review as a document shepherd: Section 4.3
Last sentence Since the document uses “SHOULD”, this implies that there are some valid cases where this is not needed. Should a text be added to explain when this is not needed? Section 6.1 1. First sentence - what is the reason for using “SHOULD”, instead of “MUST” in this case? 1. The DPoP Proof contains a hash of the Access Token, and the Access Token contains a hash of the public key in the DPoP Proof. Why do you need both? Would one of these be sufficient? Section 7.1 1. “if the request does not include valid credentials or does not contain an access token sufficient for access, the server can respond with a challenge to the client to provide DPoP authentication information.” Should the “can” be replaced with a “SHOULD”? 1. Also, I think it would be clearer if you can explicitly state what the authorization server should do when it does not challenge the client, which I am assuming will be something along the lines of: “the authorization server issues an error response per Section 5.2 of RFC6749“ Section 7.2 1. “Specifically, such a protected resource MUST reject a DPoP-bound access token received as a bearer token per [RFC6750 <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-08.html#RFC6750> ].” I think that I understand what you are trying to say with this sentence, but the way the sentence reads is confusing to me. I am assuming what you are trying to say is something along the lines of “a dpop protected resource must reject a request that provides a bearer token”. Is that correct? If so, can you please rephrase the sentence to make it clearer? 1. “A protected resource that supports only [RFC6750 <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-08.html#RFC6750>] and is unaware of DPoP would most presumably accept a DPoP-bound access token as a bearer token” Wouldn't such a resource server check the value of the WWW-Authenticate header to make sure it contains the Bearer scheme, which means that the request is most likely to be declined? Section 10.1 Why define two different mechanisms to achieve the same thing? This seems to add complexity without an obvious benefit. Section 11.6 Should the algorithms be explicitly called out? Or at least reference a document that calls out such algorithms? Section 11.7 Why is OAuth Token Binding included? Section 11.8 Why not include algorithm agility to make sure the mechanism is ready to allow for more secure algorithms in the future? Regards, Rifaat
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
