Thanks. I will push it to the next rev.
2014-05-15 8:43 GMT+09:00 Josh Mandel <[email protected]>: > 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" <[email protected]> > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
