Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Looks like Apple fixed all of the critical issues here https://bitbucket.org/openid/connect/src/default/How-Sign-in... but left in some "peculiarities," some of which are quite unpleasant.

> The scope value of only the very first request by an application is respected. If an application initially requests only the name scope, and the user allows it, it is then impossible to later also request the email scope.

So if you don't ask for the user's email right up front, you can never ask for it again later?!



Yep, no "teaser" offers.


How is that a bad thing?


How is it not? Consent to releasing information should be supported on a granular on-demand level. If I initially only need name, I'll ask the user to consent for that. If I later on need an email (lets say for some additional functionality user is trying to access), I'll ask for email separately. This is much better than being constrained to only the initial scope being respected, resulting everyone basically request everything right away, faced with a situation where they can't do it later.


I think it is great. I have seen so many dark patterns where apps request more and more things they shouldn't need.

This way everything the app will need is up-front.


I believe the opposite is true. The apps will ask for information they don't need in case they'll need it later.


Can you offer a real-world example of when this would be the case for a product where logging in is required?


You sign up for a product. No email is requested/provided.

You might later want: - to submit a support request and receive a response via email. - to get blog posts or product updates in your email. - to receive a transaction receipt

Trust is earned over time. I would much rather grant granular scopes as a product builds trust.


Even from a user standpoint... oops I clicked the "cancel" button when I meant to click "confirm" and now I have to go through the signup process all over again because the developer is not allowed to ask me again.


Last time I touched permissions the app was able to give the user a link to iOS Settings page where the user can grant previously denied permissions.


Is there a straight-forward deauthorize / re-request ux loop to allow for changes to app scope over time?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: