Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se.
The previous HN discussion about the spec violations:
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 service provider, without the identity provider being able to see the transaction [3]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying.
The fact that the identity provider is not at all involved with the transaction is an enormous privacy win compared to OpenID Connect, especially in the case of centralizing providers such as Apple – and less so in for example the domain of education single sign-on.
It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated.
Any website could use BrowserID by including cross-domain JavaScript that sent cookies to a third party (browserid) and hand the session token over for auth and then get it back. This went poorly versus the modern web’s hostility to third-party cookies.
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.
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]
Currently, IRMA is indeed still phone-only. We're quite aware that not everybody owns or wants to use a smartphone. Our software is not very tightly bound to the iOS and Android platforms, and we've explored various options over the years (smartcards, random-reader'esque devices). However, executing one of those options will only be possible if we see more adoption in general.
So I don't currently use Apple products, does this mean that people can use their own OpenID Connect identity providers with Apple (like if I run an Open ID Connect server at idp.example.com, I can add it as an authentication source) or is this just for using Apple's Identity Provider to allow your own apps to log-in via your Apple account?
Open ID Connect is essentially a an OAuth2 implementation. The original Open ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead:
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 ...?
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 of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course).
If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX.
Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider.
Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.
> 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 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"))
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.
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.
I'm mostly trying to clarify if the parent poster knew about something more than Webfinger, since his post mentions "DNS/http(s) services"; wasn't sure if that referred to Webfinger, or something else.
> How would/should/could a service be expected to take my email and determine what services it is associated with?
By following the OIDC standard, namely, using Webfinger discovery. I was mostly confused since, AFAIK, OIDC only mentions webfinger, not DNS, so I was curious if the parent to my post knew something I did not.
> as an end-user I don’t particularly want that to be possible anyway
I don't see why not. Note that this is discovering who the identity provider associated with an email is in an automated way — this is not discovering what services you log in to with that identity. That is, for "example@gmail.com", Webfinger would discover that Google is the identity provider. This is something a human can — roughly — already discern from the email anyways; this just provides an automated means. Moreover, it provides a means for the service wanting to log you in to then subsequently redirect you to; there are certain configuration parameters needed beyond just the email.
The idea is to make it simple for the average user: just enter your email.
> just because my email address is something@gmail.com, does that mean Google should be used as the OAuth provider?
Not necessarily, but I think the OIDC flow there is pretty good. One could imagine an implementation whereby GMail allowed you to specify an alternative IdP for your email, and then responded to with that when queried. This is more to do with Google's implementation. (Which, AFAIK, doesn't implement Webfinger at all, so it is kind of moot. And while I doubt they'd ever implement this sort of thing, the point is more that an IdP under your control could / that nothing in the spec prohibits it.)
> Maybe I use that same email address as an Apple ID and as a Microsoft ID as well.
I think OIDC supports this. The Webfinger query is not limited to a single result. (Though, given the paucity of webfinger implementations, I don't know how well UIs would handle this. But again, implementation vs. specification.) Even if that didn't work, you could always enter your IdP hostname directly into the RP, and it could either Webfinger that, or just see if that hostname is the IdP by attempting to pull the metadata from it.
(It is sad that most OIDC implementing RPs only give you a few hand-selected buttons leading to major IdPs to choose from.)
Microsoft's online login is probably the most prominent example of translating "user@domain.com" into a SSO login/redirect that uses Azure AD or another SSO provider for signon that I can think of.
I know it's based on DNS and/or HTTP(S) entries for the common SSO, just don't recall all the specs off hand.
For the google/apple and other very common cases you can detect by a whitelist for the domain part. For others, if there isn't a discovery mechanism in place, would have to defer to internal (password) created accounts.
It's a bit of a mess, fortunately there's a handful of TLDs that account for over 95% of public users. IIRC, when I worked at emailage, it was something like >85% of requests were from 20 domains, and 95% or so were from 100.
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.
More generally, and as hinted to by floatingatoll, the the 'X minutes ago' is also a permalink meaning after you click on it you can bookmark it in any bokmarking system you use. (I use pinboard.in)
Also FWIE, going to the permalink for a comment also gives you access to the flag feature.
`OpenID Connect` (OIDC) is not `OpenID`, despite the confusingly similar name. For the most part, `OpenID Connect` prefers to the wall full of Sign-In Options buttons/logos for determining ID Provider, instead of a user entering some specific address (as `OpenID` used to) and a lookup process, because there is more ceremony involved in establishing trust between an ID Provider and Relying Party as OIDC is built on top of OAuth APIs and generally you need an OAuth token or API key for your application (Relying Party) to initiate the API calls to login (even if those API calls themselves are standardized and can share a lot of library code by `OpenID Connect`).
(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.
Yes, there is a way to do the dynamic functionality of OpenID 2.0 on Connect by using Metadata, WebFinger, and Dynamic Client Registration, but most of the large providers do not support all three of these.
Google (for instance) wants a relying party to do some amount of registration/click through first in a web browser before their site can rely on Google. Apple (for their part) hangs your ability to support Sign in with Apple off of an app registration, which requires a developer or enterprise account and thus an annual fee.
Yes, hence, "for the most part, prefers". Since it's an optional part of the spec and because basically no major OIDC IdP supports it nor plans to ever support it, it's basically nonexistent functionality.
Huh? Maybe you mean @icloud.com or @me.com. There is also a discovery/query mechanism that should tell you if x email is registered on a specific idp but I don't think Apple implemented it. Anyway there are various UI/UX solutions. Check gigya and related openID SaaS providers.
It is usually button "Sign in with...". In your app, each identity provider has to be configured (and your app has to be enrolled with the identity provider). Similar, as with Google, Github, etc.
> So I don't currently use Apple products, does this mean that people can use their own OpenID Connect identity providers with Apple ... or is this just for using Apple's Identity Provider to allow your own apps to log-in via your Apple account?
The latter - like other IDPs that support OIDC, an website can now use Apple for authentication with the same libraries as they use for Google, Microsoft, etc.
> Open ID Connect is essentially a an OAuth2 implementation.
OpenID Connect is an OAuth2 profile.
> The original Open ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead.
The functionality is there, but is optional. As a result, it is seldomly used.
OpenID 1.0 supported using arbitrary OPs, but there was no actual organizational trust there:
- if the OP and RP had an interoperability issue, the first time it would be seen would be with an end-user. In many cases, the only way the OP/RP would know there was an issue would be when the end-user reported it.
- if the OP messed up authentication and let the wrong person in, the RP had no recourse.
- if the OP went away, you could very well have no alternative mechanism to recover the user account on the RP side
- neither side necessarily took responsibility for the user education of how a URL ("what is a Earl?") could be used for authentication
Even in its heyday, there were 10x more OpenID 2.0 OPs than RPs because of these challenges. In my opinion, it was more that the very concept was not ready for the market. That is why with OpenID Connect, most parties have not deployed this sort of user-centric Bring-your-own-OP approach even though it is a capability of the profile.
OpenID Connect’s most frustrating aspect is its naming, reminding me of a time when OpenID (1.0) was more commonplace.
With OpenID Connect, users only get the benefit if the site implements a particular identity provider... a continued move to the walled-gardenism of the net.
Decentralization always fails, centralization is inherent to society and human nature. That's why we generally centralize around areas that turn into huge metropolitan cities, and why 99% of git usage is on Github, Gitlab or Bitbucket. We're a centralization-loving race. So OAuth 1.0's dream of decentralization resulted in only a few OAuth providers ever lasting long.
Except that TCP/IP, email, and the web has shown that it can also be otherwise. Big sites come and go. I don’t think you can always state general rules along these lines (cities are different from hosting source code). You have to look at the friction vs advantages per scenario. The web, for example, has little friction due to Google providing the grease, and massive long-tail advantages in decentralization. OpenID has a lot of friction in its implementation, and few known identity providers exist for most individuals... not to mention trade offs in the implementation and profile details available per provider create incentive for developers to only put a “sign in with Facebook/google” button on their sites/apps.
On the last point... in general, a lot of sites, in order to let users participate only really care about having a name and email address or phone for contact needs. Most don't really even care about that. Why not let any number of other systems take care of that. For that matter, they also handle validation.
I'd rather let FB/Google/Twitter and now Apple deal with verification details, and let them participate in a site. It also means, on doesn't have to deal with persisting or dealing with passwords (that can be breached) etc.
Of course, I'm still inclined to allow local/passworded accounts and ensure salt+hashing of passphrases, etc. It's just in a lot of ways much easier as a user.
Depending on the site, I'd often prefer Twitter (until my short account ban/lock, which made life more difficult for a few days... FYI, don't rile up the communists too much).
I wonder if people "centralize", i.e. gather, around cities to enjoy the more and varied (decentralized, even?) opportunities afforded. Many rural areas force centralization of, say, one grocery store or one hardware store. There is generally one town center, whereas in larger metropolitan areas one can choose from many, many different social circles, markets, and to some extent even governmental centers. That strikes me as a big win for decentralization.
Even your example of git seems counter to your point— can you imagine if all version control ground to a halt whenever GitHub went down?
I realize this is off-topic, but it is an interesting thought.
There are a lot of corporate or "free" projects that are on self-hosted platforms; plus, there are a number of other players with smaller but non-negligible share such as SourceForge.
Its a mix, fully centralized takes power away from people and sucks. Fully decentralized is not stable enough to survive as something useful. The trick is finding the right balance between. Generally its safe to bias towards decentralization because so much historically has overly tended towards centralization.
This is really great. So many people were up in arms about Apple releasing an implementation that didn't comply with OpenID. Good on Apple for addressing the issues.
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 users and ships physical products – our payment providers and shipping providers all need to be able to contact our customers if they choose to use those services, but this would be essentially impossible (or a prohibitive amount of technical work at scale).
I think maybe if everybody selling something didn’t make the audacious assumption that I’m also providing my email address because I really want you to spam the shit out of me with all of your announcements and promotions, it wouldn’t have to come to this.
I certainly don’t want anybody I buy from having my Apple ID email, and they should not assume that just because it is a user identifier, that does not mean it’s even used for email. Some retailers do this with things like paypal, and actually overwrite the supplied email address with the one from paypal. Really annoying.
The correct pattern is to ask the user for the email address that they would like you to have. And preferably, never send email to it again.
In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. You can register up to 10 domains and communication emails.
I've rarely seen vendors sharing e-mails with payment and shipping companies, and would consider it somewhat icky for privacy reasons, especially when done without the user's consent.
It also seems that you could set up your own relay allowing those providers to contact your customers. In fact, that would be the privacy-conscious alternative even to your current implementation.
Many delivery providers need to be able to contact the person they are delivering to. This is standard practice. The same is true for many non-trivial payment providers (such as PayPal/Klarna).
This data is shared for the legitimate interests of the customer. You've bought something and asked to a) pay for it, and b) have it delivered. I think it's reasonable to expect that the companies involved in this can contact you for the purposes of fulfilling your request.
This is all done under GDPR. The companies hold the data only for as long as they need, for the purposes explicitly requested by the user. This will all be included in privacy policies.
> It also seems that you could set up your own relay allowing those providers to contact your customers.
This might be technically possible, but introduces many concerns such as deliverability and spam ratings. Relaying email in this way is non-trivial when you're doing it at scale. For services sending ~100k emails a month or more, this requires careful planning because it's very easy to become filtered as spam.
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 sharing E-mail addresses in your past user research.
> 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.
> I've rarely seen vendors sharing e-mails with payment and shipping companies
If it was done correctly, odds are good you wouldn't even know those emails originated from a third party vendor. Plenty off stuff you order is fulfilled by third party vendors who specialize in payment & logistics.
For example, if you ever ordered contact lenses from costco, the whole damn thing is driven from vendor called "WVA"[0]. I'm pretty sure it is completely turn-key. Only way I figured out what was going on was looking at the return address in streetview.
I ordered a lockpicking from an online vendor and it was fulfilled by some logistics provider on the east coast. Same kind of thing...
So I'm not actually sure what your problem is, but plenty of businesses have a need to share your contact information with their vendors.
> 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.
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.
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.
I wish Apple would actually publish the configuration document too (under the well-known URL, as listed in the peculiarities). It makes it one less step for OpenID clients to follow.
I wonder what their rationale is, for not doing that (given how easy it is, compared to all the other things they fixed).
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 identity that Apple owns.
I would say that's slightly inaccurate.. it's ultimately identity information that Apple owns. And of course, Apple owns your account with Apple.
But the minute you "sign in with Apple" to any service, they too are creating a local identity for you (sans password). That identity begins with the information provided by Apple (e.g. name, email address, etc.), but can expand over time to include additional information provided by the user, not Apple.
You are correct in that quite often who implements provider vs consumer depends largely on market position. There is technically no reason Apple can't become a consumer, other than they aren't interested in doing so. Also consider that, should Apple choose to eliminate your account, then you've lost whatever you use Apple to sign in with unless those downstream providers offer some kind of recovery mechanism.
> Also consider that, should Apple choose to eliminate your account, then you've lost whatever you use Apple to sign in with unless those downstream providers offer some kind of recovery mechanism.
Yes, some kind of recovery mechanism, some ability to set a local credential post-registration, or some ability to link and unlink external accounts, e.g. Sign in with Apple, then link your Google, FB, and Github accounts. Then, if you lose access to your Apple account, you still have additional options for authentication.
The latter two options are something I wish more organizations offered..!
> 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?!
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.
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.
So they actually responded by fixing those issues? I wonder if they went as far delaying the release for that. If that’s the case, +1 to Apple for privacy
has sign in with Apple launched yet? It was the Big Thing in iOS 13 that I was personally most excited about but honestly, if it has launched, I haven't seen it yet.
edit: from the comments it sounds like it has launched, but currently being implemented in a voluntary manner. Looked at the 9to5Mac article on iOS 13 support of apps and it looks like I just don't use any of them unfortunately.
Love the idea still and hoping it gains heavily in adoption.
Mandatory so long as the app supports other third party authentication. If they exclusively use only their own accounts, it isn't required. (There are a couple other exceptions for business and education apps)
Yes, that was the first time I saw it, and it's exactly the kind of app that I'd rather not give my PII to, so kudos to that developer for offering the option.
Houzz appears to support Sign in with Apple in their iPhone app, but not yet on their https://www.houzz.com/ website. So I created an account on my phone that I can't use on their site.
It's no harder to change than using any other identity provider. If you want to change, the service just needs to provide some way for you to link your existing account to a new sign-in mechanism.
Classically, this is done merely by detecting that you've signed in on two different mechanisms using the same email address. That can still be done with Sign In With Apple for users that have opted to give the service their email address, but for users that opted to use Apple's email redirector, the service will simply need a way for the user to explicitly link it to another account (or to manually provide their email address).
OpenID Connect is a profile of OAuth 2 that adds authentication and identity information. Sign in with Apple was a partial implementation of OpenID Connect, for sharing authentication as well as an email address and the user's name between Apple and other apps/services.
As a partial implementation, there were both difficulties using existing third party libraries and known security issues in Apple's implementation. This was shown initially by manual inspection, then by Apple's implementation failing the freely available certification test suite published by the OpenID Foundation (I believe run by third parties, not Apple themselves).
The OpenID Foundation published an open letter both to ask Apple to fix these issues, and to inform other operators that there were security issues with Apple's implementation.
A complete implementation solves known security and interoperability issues.
OpenID Connect is a protocol for any site (and other software) to ask an identity provider who the user accessing the site is. Generally the user chooses one provider among those supported by the site (e.g. Google, Facebook, etc) and gets redirected to it, so it can authorize the authentication, then gets sent back to the site, and the site can now get info about them (usually some ID, and an email address).
This allows the site/user to avoid having to provide and store a password, since the site can just create an account and login the user based on the ID given by the provider.
Apple started using that protocol, allowing sites to authenticate users with them, but it broke a few parts of the standard, which meant the site developers couldn't use their normal libraries to connect to Apple's identity provider.
Say I have a web service with users but don't offer an email service with my core offering. Im guessing by using this I wouldn't be able to build iCloud Mail into my main service; allow my users to view, receive and send iCloud Mail through my web service?
"Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se."
That list of "peculiarities" is pretty disappointing. The lack of a discovery endpoint is sad; it isn't that difficult to provide and it greatly reduces the obscurity of configuring RPs.
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 to supply my password along with answers to my 3 secret questions. Additionally my recovery email cannot be the same as my account email.
Why Apple's online is terrible compared to their hardware/software?
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 completely "security oblivious" customer.
I am talking about the basic user experience for my iTunes music, video and apps. Apple's "protection" of my account isn't better or stronger than other popular online services, such as, Facebook, Dropbox, or Gmail. I have more sensitive data in my Dropbox and Gmail accounts than Apple's. And yet I go through trouble each week to unlock my account. Why do I need to be troubled by it to get access to things I paid for?
So here is a real story why I complained about requiring a different email address than the primary one. So a few years ago my apple account got locked due to their extra "protection". I tried to reset my password. I was given two options: to recovery by email or answer secret questions. Unfortunately I no longer had access to my works email and my answers weren't matching. It took another year till I could remember the exact answer I entered at the beginning. Till then my hundreds dollar of digital goods were locked out.
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.
https://bitbucket.org/openid/connect/src/default/How-Sign-in...
Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se.
The previous HN discussion about the spec violations:
https://news.ycombinator.com/item?id=20311000