Is it currently not possible to use standard OpenID clients for "Sign-in with Apple" authentication ? Does Apple not provide some sort of SDK that makes this easy ? And if so, what is the advantage of "Sign-in with Apple" being interoperable ?
Using standards has some advantages like not having to test dozens of authentication systems/clients doing basically the same thing. If you would have read the document you would have found that you can't use standard openID clients due some issues with Apple's implementation. Some of the issues have security implications.
Not really...
For example, the lack of a discovery document means that a lot of the essential configuration cannot be discovered programmatically.
The lack of a UserInfo endpoint means that applications which are used to using that will need to get the user info out of the id_token.
edit: not “no expense report”; i actually meant “you don’t have to ask anyone first (but will have to file a report about it later)”, which is not quite the same thing.
You're probably joking, but in case you're not this isn't right. If a company had a policy like that they would have difficulty demonstrating to the IRS that all their expenses really were for their business, and they would have a hard time protecting themself from embezzlement. The company needs to be keeping a receipt and a business justification for the expense.
$15k is something like 0.000006% of Apple's cash on hand.
Some sort of accompanying commentary from OIDF people, explaining the reasoning behind the letter, would be appreciated.
It's also pretty weird to borrow 95% of a spec, miss out on a half dozen important security features, not acknowledge the relationship between your work and the spec, and not contribute back to the community that funded the spec.
they all been doing this all the time
So I asked my friend if he knew about these other companies, again all very well known in the specific market for AR developer tools, and he said he didn't and they don't actively look for companies they might be impacting when making product decisions.
And I don't want to downplay the innovative additions Apple made to the whole thing (browser integration etc.), but it doesn't make an honest impression if you don't mention that your revolutionary product is a based on a well-known standard.
"Use the OpenID Connect Self Certification Test Suite to improve the interoperability and security of Sign In with Apple."
Give us a bunch of money and maybe we'll let you join our little group and you can have our mark of quality that you are now secure. Wow, really? Thanks.
It's a little like a lot of the spam I get as an Android developer from "marketers" and just general weirdos trying to get rich off my hard work.
But it's mostly not their work - Apple's protocol is basically a bad implementation of OpenID Connect.
https://github.com/openid-certification/oidctest
Apple are absolutely 100% free to run the tool and fix any issues found without any payment to anyone except their own engineer's time.
(There is a fee to pay for the 'OpenID Certified' logo and to be listed as certified, but in my opinion just running the free tool and fixing any interoperability issues is a major benefit by itself.)
> Oh, you've all agreed on USB type-c? Well we're going to use thunderbolt. Except for when we don't and our customer have to buy a type-c to thunderbolt adapter.
> Two button mouse with a scroll wheel? How about a 1 button mouse that you click with two fingers.
> Linux? Sure, but it's called MacOsx and doesn't have a native package manager.
They've always done stuff like this.
Assuming you're referring to Lightning, that predates USB-C, and the reason why Apple hasn't replaced it yet is probably because of agreements with accessory makers over how long they are going to remain using that connector.
> Two button mouse with a scroll wheel? How about a 1 button mouse that you click with two fingers.
I believe macOS originally didn't have the concept of right click, but rather ctrl-click. Eventually they supported both, and mice sold by Apple have supported right click for almost 10 years.
> Linux? Sure, but it's called MacOsx and doesn't have a native package manager.
Linux (the kernel) doesn't have a package manager, and many distributions don't have a package manager either. The primary use of macOS is not the command line, and developers are better served by third party package managers/repositories, with a cadence independent of the OS release lifecycle. (Just like on Ubuntu, where you frequently need to add PPAs for anything newer/different from what's available upstream)
The only one I am aware of is LFS (Linux From Scratch), which is more like a manual on how to build your own distribution than a distribution like others. Anything more mainstream?
OsX was built on NeXTSTEP, first demoed in 1988 and released in 1989.
Linus started working on a minix clone in 1991, with the first complete distributions (Slackware and Debian) not appearing before 1993.
The Unix personality on top of Mach was derived from BSD 4.3, released in 1983. BSD itself was started around 1977. It all is derived from the original Unix.
Not talking about classic MacOs
It's never felt as natural on their mice though.
I could see someone making the choice where they would elect not to manage a nonce because its permuting effect was achieved by other parts of the protocol. Apple also has keys in a TEE, and a nonce generated and synchronized outside of that could have been interpreted as creating additional attack surface.
If the OpenID letter is correct, there are exploitable vulnerabilities in Apples implementation that could be demonstrated. If they are not correct, they could just be angry Apple is leveraging its TEE to assert it doesn't need governance from this standards body because the standard is written for products without a separate hardware keystore.
Also
>Are there live production deployments of OpenID Connect? Yes. Some examples include Google, Gakunin (Japanese Universities Network), Microsoft, Ping Identity, Nikkei Newspaper, Tokyu Corporation, mixi, Yahoo! Japan and Softbank. There are also mature deployments underway by Working Group participant organizations, such as Deutsche Telecom, AOL, and Salesforce.
For an example of OpenID Connect at work, look at Google+ Sign-In, Google’s flagship social-identity offering, which is entirely based on OpenID Connect.
The typical driver is that the standard is a poor fit for purpose because it was originally designed by companies operating under a more limited set of constraints and use cases. In some of the cases I've been involved in, the deviations required to make it fit for purpose would immediately save millions of dollars per year versus following the strict letter of the standard, so the value of deviating was not academic. The reason you keep any deviation close to the standard instead of designing a new one is to minimize the interoperability gap in practice.
If you are able to articulate why the standard is not fit for purpose to the standards organizations, they may use it as a driver for a new standard. However, this frequently runs into strong political resistance from the existing member base because they rarely benefit from the increased scope -- all downside, no upside. Nonetheless, the standards organizations are invested in maintaining relevance. As a practical matter, unless you go into these discussions with the standards orgs with an existing implementation of an alternative that threatens their existing standard, they are very reluctant to move.
I'm not saying any of this applies to Apple's case but the above happens a lot in my experience. It would be nice if it was easy to work with the standards organizations if you need to make a standard work for other use cases but in practice it is an extremely difficult and political uphill battle.
I think that for people outside of HN, that's OK. Not everyone trusts the open source community, or open source organizations.
If something goes wrong with something important, it's normal for people to want something or someone to blame. If that something is Apple, that's useful. If it's some rando on the internet contributing code to a code repository, it's significantly less useful to the ordinary person.
For the average person, entrusting Apple with their logins is a better option than using password1234 or some other coping mechanism. People know Apple. Nobody knows OpenID. It's the same reason people used to trust Microsoft (and many still do!) with their personal information. Microsoft is a known quantity.
It's like having a neighbor watch your pets while you're on vacation, or signing up with some random service on the internet to watch your pets. Those random services get bonded and insured for the peace of mind of the user. There is no such level of assurance from OpenID other than it uses the word "open" in its name, and as a culture we value the word "open" more than "closed."
And their laptop overheating.
And the price of their monitor stands.
Or their lack of a <5" screen phone.
No, hacker news is happy to bitch about apple all day long and I don't know how one could possibly think otherwise.
If I had to guess, the criticism here comes from the same strain of criticism of the GPL that has been growing over the past years. The tech community has grown a lot, and has attracted a lot of people mostly interested in money. Ideas such as open standards or non-commercial collaboration have lost some appeal.
It's not really an "invitation" if they expect Apple to give them money.
Even if someone has paid for something, the seller does not have to recognise that a transaction has taken place and would not have to enter or execute the contract. This is especially important in times where there might be a pricing error or something.
Quoting wikipedia for convenience:
"OAuth 2.0 has had numerous security flaws exposed in implementations.[17] The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable.[18][19]".
The contributor referred to (John Bradley) as saying that OAuth 2.0 implementation mistakes are almost inevitable is one of the authors of the OpenID Connect spec, and if you follow the citation link ( https://mailarchive.ietf.org/arch/msg/oauth/WuT1tmFoxs8S_2v7... ) you'll see him mention that the flaw referred to is fixed in OpenID Connect.
OpenID Connect is not an authentication solution by the way. It's at best a few standard requests and parameters, all of which are optional, that could be used to interconnect authentication systems if that's what you're trying to do. Authentication and most of everything is left to the implementation.
After a few cases, the unpleasant memory hops to the dataset as a whole, leading to a fixed view of HN. But people with opposite likes have the opposite fixed view. When people tell how they see HN, they're really telling the story of themselves. It's fascinating how solid this principle turns out to be. I'm sure it extends to things that are far less trivial than an internet forum.
'Not Invented Here syndrome'.
