Comments inline. Phil
@independentid www.independentid.com phil.h...@oracle.com > On Nov 16, 2015, at 12:37 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > 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. [PH] I think the change is the point of the POP specifications. We are talking about a new class of tokens that are specifically not Bearer tokens thus the threat mitigation states that POP tokens are assumed to be digitally signed. Was that not clear from the introduction? > > 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). [PH] I think this can be simplified a bit. I think this was referring to a “NULL” ciphersuite which is what 7525 says should not be done. We should also point to 7525. > > 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:” > [PH] Will add to the next draft pending your comments on the above items. > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
