Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Successfully Implements OpenID Connect with Sign in with Apple

openid.net

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#101

Post by OkGoDoIt »

deathanatos wrote: post #83
tracker1 wrote: post #59

Earlier quoted context omitted.

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…

> There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. 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 s…

My Apple ID is a personal email address at a custom domain name. I also use the same email address as a Microsoft ID. How would/should/could a service be expected to take my email and determine what services it is associated with? I assume that’s not really possible, and as an end-user I don’t particularly want that to be possible anyway.

But let’s take a simpler scenario, just because my email address is something@gmail.com, does that mean Google should be used as the OAuth provider? Maybe I use that same email address as an Apple ID and as a Microsoft ID as well.

There’s a lot of confusing edge cases with OIDC.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#102

Post by Twisell »

OkGoDoIt wrote: post #101
deathanatos wrote: post #83

Earlier quoted context omitted.

> There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. 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 s…

My Apple ID is a personal email address at a custom domain name. I also use the same email address as a Microsoft ID. How would/should/could a service be expected to take my email and determine what services it is associated with? I assume that’s not really possible, and as an end-user I don’t particularly want that to be possible anyway. But let’s take a simpler scenario, just because my email address is something@g…

If I understand correctly AppleID is supposed to obfuscate your real email such that the website you connect to will only see a hhfyguihry636357484@privacy.apple.com or something similar.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#103

Post by QuamStiver »

I just implemented this for an app, and was glad that for the most part Apple followed a standard here, but some of these “peculiarities” referenced are a PITA.

Most notably imo:

> The scope value of only the very first request by an application is respected.

This means if you require an email address and something goes wrong before persisting it (e.g. the app crashes), there’s nothing you can do except ask the user to sign into their account on Apple’s website, revoke the app’s permissions, and start over.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#104

Post by lwyr »

Confiks wrote: post #57

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…

Mobile ecosystem issues aside, IRMA looks excellent. Could IRMA's decentralization and selective disclosure features somehow be combined with OpenID? For example, could the IRMA application serve as a standalone OpenID provider, perhaps using OpenID Connect Federation to establish trust? [0]

[0] https://openid.net/specs/openid-connect-federation-1_0.html

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#105

Post by oarsinsync »

danpalmer wrote: post #40

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…

> In order to perform this we share basic user details with them only for the purpose of performing this check, and on the basis of this check the provider will either agree or decline to offer the credit.

> How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address.

> [...] Unfortunately this is completely ineffective for the pay-later scenario, which depends on being able to correlate user accounts.

I'm finding it hard that an organisation that is capable of doing a credit check on me (which doesn't rely on my email address) is unable to account for multiple debts without using my email address.

Infact, if they are only using my email address, that is absurd, as one email address != one person.

> Services that use dynamic domains (for example thread.foobar.com) will be unable to authenticate all of their domains.

Services that use dynamic domains (for example thread.youjustgotphished.com) will be unable to be authenticated by end users as being legitimate. Dont do it.

> Best practice for email deliverability suggests that senders should send from a different domain per category of email that they send8. This mostly applies to larger products, but 10 domains is too limiting.

Because our industry is rampant with spam, we have created new ways to try and bypass spam filters. Nope, go away.

> In the EU where GDPR restricts what companies may do with customer data, this leaves Apple’s SSO providing little to no benefit over what is already required by law.

Another layer of protection against companies that fail to abide by the law (and companies that wilfully neglect their obligations under the law) is more valuable than "little to no benefit" to end users.

Sorry to be really blunt, but these are just the highlights. As an end user, all I have for [the retailer] is a tiny violin. Retailers at large have demonstrated a fundamental lack of respect for end users. Apple's service looks like it lacks respect for the new-norms that retailers have adopted.

Good.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#106

Post by danpalmer »

oarsinsync wrote: post #105
danpalmer wrote: post #40

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…

> In order to perform this we share basic user details with them only for the purpose of performing this check, and on the basis of this check the provider will either agree or decline to offer the credit. > How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address. > [...] Unfortunately this is completely ineffective for the pay-later scenario, which depend…

I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this.

What we're talking about here is not spam. We're talking about transactional email that a user wants. I know that when we fail to send order dispatch emails users shout "Scam!" because it looks like we've taken their money without doing anything. I know that users like being able to pick up their order at a local store (with a security code). I know that users like to be able to pay with a range of payment options.

We're not talking about marketing here, we're talking about the minimum of communication for a user to feel that they can trust a retailer.

Yes the industry abuses email, but these examples are not that.

As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal. I don't want to speak for the service provider, but this sounds like one good approach to me.

> Apple's service looks like it lacks respect for the new-norms that retailers have adopted.

Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#107

Post by danpalmer »

ryandrake wrote: post #90
spookthesunset wrote: post #65

Earlier quoted context omitted.

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.

Thanks for that . A couple of things: 1. I don’t think an E-mail address is really necessary in order to ship a package or charge a credit card. 2. Friction and convenience used to be acceptable reasons to collect personal info without consent but maybe that’s starting to change. I highly doubt the 99.99% figure but having no data of my own I won’t dispute it. I trust that you have seen such an opt-in rate for sharin…

> I don’t think an E-mail address is really necessary in order to ship a package or charge a credit card.

For credit cards, no it's not (but would be for pay-later, PayPal perhaps, Alipay, AmazonPay, maybe).

For shipping, most shipping companies have the option to handle the customer communication. When creating an order you provide them an email address and/or phone number, and they will send notifications. Many use these channels to provide the user the ability to reschedule deliveries, select delivery windows, change their delivery address, etc. This process is often also white-labelled so you may not realise that it's actually with the delivery company.

These details are not stored long term, only for the purposes of doing the delivery, any applicable returns process, and any insurance claims, etc.

It is possible to not do this, but assuming the retailer wishes to provide the same level of communication it means a much deeper level of integration, as tracking data needs to be ingested by the retailer. Given the industry has no standards for this, and "integrations" are SFTP + cron jobs once a day + CSVs, this can be pretty difficult, error prone, and result in a poor UX where you don't actually have the granularity of data to send an email when the package has been delivered.

> Friction and convenience used to be acceptable reasons to collect personal info without consent but maybe that’s starting to change.

We have found that it is within the user's expectation that we will share contact details to the third parties necessary to complete their order in this manner. It's in our privacy policy that we do this. We also check that all of our suppliers understand their GDPR responsibilities.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#108

Post by freehunter »

floatingatoll wrote: post #47
scient wrote: post #35

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?

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.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#109

Post by freehunter »

pojzon wrote: post #98
antimora wrote: post #97

Apple's online credential/auth* user experience is terrible. I can't wait till Apple fixes their account auto-lock feature. On weekly basis I have to unlock my account because someone is trying to login with my email. I contacted the customer service to see if something could be done to avoid auto-locking. The only suggestion was to pick another email address that's not common. Also in order for me to unlock I have t…

To be honest I read all your complaints as a "screw Apple for protecting me".. pretty disrespectful. Their answer is expected. If your email is something like "john.smith@gmail.com" - there are like few hundred thousends of Smiths there.. And the complaint that recovery email cannot be the same as account email - so you want your account to be compromised without ANY way to recover it? Those seem like complaints of a…

On the other hand, if a provider is saying "there is nothing we ca do to prevent a denial of service that's impacting your account", that's not a great response.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#110

Post by oarsinsync »

danpalmer wrote: post #106
oarsinsync wrote: post #105

Earlier quoted context omitted.

> In order to perform this we share basic user details with them only for the purpose of performing this check, and on the basis of this check the provider will either agree or decline to offer the credit. > How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address. > [...] Unfortunately this is completely ineffective for the pay-later scenario, which depend…

I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this. What we're talking about here is not spam. We're talking about transactional email that a user wants. I know that when we fail to send order dispatch emails users shout "Scam!" because it looks like we've taken their money without doing anything. I know that users like being able to pick up their order at a local store (with a sec…

Thank you for taking the time to reply. Appreciate it.

> I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this. What we're talking about here is not spam ... We're not talking about marketing here ... Yes the industry abuses email, but these examples are not that.

> Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.

Unfortunately, while that may be true of your business, it's not true of others. You know the saying about bad apples spoiling barrels, right?

In the case of any legitimate email from third parties, your business can now be the relay for those emails. Instead of @ emailing me about a purchase from legitimateretailer.com, moving forward only *@legitimateretailer.com (and up to 9 more domains...) can email me about that purchase. And on top of that, legitimateretailer.com is required to do the bare minimum to try and reduce spoofing off their domain. Ideally DKIM and DMARC would be mandatory as well, and not just SPF!

For it to be any different, Apple would need to certify every partner in the chain used by any retailer. Every time a new partner is engaged, Apple would need to be notified and that partner certified. That seems even more onerous.

> As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal

KYC requirements in financial businesses are pretty strict. If losing this signal is a problem for your business, you're probably violating regulatory requirements. See previous remarks about value provided & legal requirements.

Post reply on HN