81–90 of 121 posts
Earlier quoted context omitted.
I wish there was an easy way to save a hackernews comment for later
Click on the 'X minutes ago' permalink on the comment, and then select 'favorite'. It will show up under 'favorited ... comments' linked from your profile page while logged in.
Shameless plug (but I hope that's okay, again): IRMA Authentication is an open-source app [1] and protocol that offers privacy-friendly attribute based authentication and signing using Camenisch and Lysyanskaya's Idemix [2]. It's currently heavily focused towards The Netherlands, where citizens can obtain attributes such as name, home address and age. These attributes can then be selectively disclosed directly to a s…
I find lots of cool shit on hn because people decide to share their side projects that I wouldn't otherwise have seen.
It only becomes a problem when people don't disclose they have a bias or connection to a product when they should.
Earlier quoted context omitted.
What value would they enter at what prompt in order to activate the Apple Accounts process? For example, "openid.apple.com" or "some_email_address@openid.apple.com" or ...?
Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons. ---- Aside, in terms…
I'm aware of OIDC's webfinger discovery mechanism; IIRC, it lets you translate "person@example.com" into a valid login. (But I don't think I've ever seen anyone implement this.) Is there something else?
I think you could also implement just a DNS identifier to OIDC discovery which would let you translate something like "apple.com" into an OIDC flow, but you would need the provider to publish a OIDC discovery document, which Apple's implementation does not do. (Why, IDK, since that seems like a really easy thing to do. But Google — which does have one, technically — also isn't "google.com" or "gmail.com", so entering this seems a bit hard for a user to enter. (It's under "accounts.google.com"))
Earlier quoted context omitted.
You can allow people with apple accounts to login into your website without to write Apple specific code. Just use whatever lib you've been using to allow people to auth with their Google accounts or any other 3rd party openid connect idp
What value would they enter at what prompt in order to activate the Apple Accounts process? For example, "openid.apple.com" or "some_email_address@openid.apple.com" or ...?
(You need a Facebook API key to enable "Sign in with Facebook" on your website, you need a Google API key to enable "Sign in with Google", and so forth.)
So users are just trained to look for "Sign in with Apple" buttons, and websites get encouraged to add "Sign in with Apple" to their wall of sign-in options. Apple is going to make it a requirement for large categories of iOS apps in near future, so that will probably bubble out into website adoption in general.
Slightly off topic, but it's been frustrating to me that large organizations only want to implement OpenID providers and not consumers. What Apple has done makes it easier to bring your Apple identity across the internet, but it's ultimately an identity that Apple owns.
Basically, if you're a large org, you must be an OpenID Provider (OP). Optionally, you might also be a consumer. If an org supports social login, for instance, they are likely a consumer and a provider. The user authenticates at an external OP (like Apple or Google), but a local account (or "identity") is always created by the service provider, which should be stored in an OpenID Provider. > but it's ultimately an id…
Shameless plug (but I hope that's okay, again): IRMA Authentication is an open-source app [1] and protocol that offers privacy-friendly attribute based authentication and signing using Camenisch and Lysyanskaya's Idemix [2]. It's currently heavily focused towards The Netherlands, where citizens can obtain attributes such as name, home address and age. These attributes can then be selectively disclosed directly to a s…
This sounds very similar to Mozilla's BrowserID. Is there any document contrasting the two?
For a website to use IRMA, it looks like they have to stand up a server component on their web server - it’s not enough to simply include Javascript like browserid, but it also isn’t subject to the third-party cookie failure of browserid.
I'm glad they've got the tech right for the actual authentication, but their email relay is still far from usable. It's limited in very fundamental ways, that will prevent many companies of any scale from using it. It's very difficult to make it work with an email service such as SendGrid, and it's limited to 10 domains you can prove ownership of, and 10 specific email addresses. I work for a company that charges use…
It is technically 10 DNS lookups and you can list as many IP addresses as you need on top of it.
Is Apple's policy is any different than this?
Earlier quoted context omitted.
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 reques…
Can you offer a real-world example of when this would be the case for a product where logging in is required?
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.
Earlier quoted context omitted.
What stops the user from consensually providing this information in a form field at checkout, if they wish for such contact?
1. You already gave those downstream vendors your contact information so they can, you know, ship your package to your home and charge your credit card. 2. 99.99% of all users probably want to be emailed tracking information or payment confirmation information. Adding such a checkbox only adds friction to their funnel in order to please an incredibly small minority of people using their site.