Thanks Dick. OIDF is also trying to write a white paper why in-app browser for this purpose is a bad idea.
=nat via iPhone 2015/05/09 4:28、Dick Hardt <dick.ha...@gmail.com> のメッセージ: > Glad to know I was not missing something. > > I explained all the logic in my first response to the reviewer. Next response > was to comply with 10.6 > > I have filed an appeal. Will keep list updated. > > Aaron: the LinkedIn API claw back really sucks. Facebook turned down APIs > earlier than v2 last month, and now there is little profile data from them. > Getting data out of the silos has gotten much tougher. > > >> On Fri, May 8, 2015 at 7:46 PM, Joost van Dijk <vandijk.jo...@gmail.com> >> wrote: >> This is indeed very bad news. Not just because we are developing apps that >> use the same approach, but also because we have declared in-app browsers to >> be Bad Practice when used for authentication because of the reasons you >> described. >> >> Furthermore, it just won't work. Our OAuth authorization server >> authenticates to an identity federation where very diverse authentication >> methods are used, such as TLS client authentication. An app won't have >> access to the private key needed to authenticate when using an in-app >> browser: you really need to open the platform browser for this to work. >> >> Cheers, >> >> -- >> Joost >> >>> On 08 May 2015, at 18:21, Dick Hardt <dick.ha...@gmail.com> wrote: >>> >>> I have an app that is was submitted to TestFlight that was rejected for >>> opening up Safari for getting authorization from Google or LinkedIn. >>> >>> Apple wants me to load the Google or LinkedIn page with an in-app browser >>> to comply with >>> >>> 10.6 - Apple and our customers place a high value on simple, refined, >>> creative, well thought through interfaces. They take more work but are >>> worth it. Apple sets a high bar. If your user interface is complex or less >>> than very good, it may be rejected >>> >>> I'm thinking this is crazy >>> >>> The user experience is better bouncing to Safari as it: >>> >>> 1) clearly signals to the user that they are providing their credentials to >>> Google or LinkedIn >>> >>> 2) Google and LinkedIn can pre-fill the username if they have previously >>> used the browser at either site >>> >>> 3) If they Safari has their credentials, Safari can fill them in at Google >>> / LinkedIn >>> >>> From a security point of view, the in-app webview has >>> >>> 1) NO signal to the user they are providing their credentials to LinkedIn >>> or Google. >>> >>> 2) Looks like a new browser instance to LinkedIn and Google rather than an >>> already known device. >>> >>> I'm surprised Apple is taking this stance. Am I missing something? >>> >>> -- Dick >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to oauth+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to oauth+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to oauth+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
