Hello, I reviewed draft-ietf-oauth-pop-architecture and have a few questions.
1. Section 6, Threat Mitigation: Last sentence of first paragraph, "To simplify the subsequent description we assume that the token itself is digitally signed by the authorization server and therefore cannot be modified." Since bearer tokens are not signed by default, is this proposing a change? If so, where will that change occur? To state that "it is assumed" without it being required anywhere is not a good assumption. I'd still see this as a risk or security consideration. When OAuth is re-used by other protocols, I am seeing that re-use leave off basic protections that should be assumed like TLS, let alone digital signatures. If this is required in the defined architecture (Section 7 - it does show this, but there are no MUSTs that I can find), just state that and refer to the requirement. 2. Section 6, Threat Mitigation Third paragraph, "As an example, TLS with a ciphersuite that offers confidentiality protection has to be applied (which is currently true for all ciphersuites, except for one). Please list a reference so the reader knows which ciphersuites are acceptable from the recommended ones in RFC7525. I don't recall there being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and that we've discussed that already with previous drafts, so this should be spelled out more). 3. (Nit) Section 6.2, add a comma to improve readability From: "Instead of providing confidentiality protection the authorization server could also put the identifier of the client into the protected token with the following semantic:" To: "Instead of providing confidentiality protection, the authorization server could also put the identifier of the client into the protected token with the following semantic:" Thank you all for your work on this draft! -- Best regards, Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
