Forgive me if this is well-trodden territory, but I would have expected the security considerations in this proposal to include a note to the effect of:
"In a scenario where a mobile client is contending with malicious apps on the same device that listen on the same custom URL scheme, it's important to keep in mind that a malicious app can initiate its own authorization request. Such a request would appear the same as a legitimate request from the end-user's perspective. So in this case, a malicious app could request its own verifier code and successfully obtain authorization using the tcse protocol." Obviously this does not negate the value of the proposal, but it's something I'd expect readers to keep in mind. In particular, it has very strong implications for whitelisted authorizations, where no end user interaction is required. In such a case, a malicious app could initiate a request at any time and the user would not be in the loop to raise a question about its legitimacy. On May 9, 2014 4:51 PM, "Brian Campbell" <bcampb...@pingidentity.com> wrote: > > I notice that code_verifier is defined as "high entropy cryptographic random string of length less than 128 bytes" [1], which brought a few questions and comments to mind. So here goes: > > Talking about the length of a string in terms of bytes is always potentially confusing. Maybe characters would be an easier unit for people like me to wrap their little brains around? > > Why are we putting a length restriction on the code_verifier anyway? It seems like it'd be more appropriate to restrict the length of the code_challenge because that's the thing the AS will have to maintain somehow (store in a DB or memory or encrypt into the code). Am I missing something here? > > Let me also say that I hadn't looked at this document since its early days in draft -00 or -01 last summer but I like the changes and how it's been kept pretty simple for the common use-case while still allowing for crypto agility/extension. Nice work! > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 > > _______________________________________________ > 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
