jogu

The auto updates are actually quite broken and the lead up to this release has been a poorly communicated mess (see https://www.reddit.com/r/backblaze/comments/de1179/macos_610338_manual_vital_upgrade_prompt_lack_of/?utm_source=share&utm_medium=ios_app&utm_name=iossmf ).

I really hope backblaze up their game as a result of this. I really don’t care if my backup app looks nice on high resolution displays or not, but it hugely worries me that they don’t seem to feel it necessary to apply normal engineering practices like issuing change logs or having the app tell  users when auto updating is failing.

(That said, they’re still miles ahead of crashplan - I evaluated crashplan for our company and quickly realised it is a security nightmare we shouldn’t touch with a barge pole.)

mjtomlin said:

Since no one outside of Apple knows exactly how "Sign in with Apple" works anything said or compared is purely conjecture.

It's literally documented on Apple's developer website how it works.

I seriously doubt Apple "copied" OpenID...

See the Apple documentation. Apple return an id_token that is exactly the same format as the one defined by the OpenID Connect standard, right down to the field names. There's no reason you'd do that unless you were basing your tech on OpenID Connect.

They are very capable of coming up with their own implementation even if some of things happen to "appear" similar. Anyone who's every designed anything knows there's a huge difference between implementation and appearance.

They are, but if they want it to be interoperable then they need to follow existing standards (and they do seem to want this, so that it's easy for third party website backends to support sign in with apple; otherwise as you say they would have invented something completely new).

OpenID obviously has an issue with Apple (probably not joining their group), otherwise, what would they care? This reaction reminds me a lot of CurrentC.

As long as we have an option that is NOT Google or Facebook, (or any group supported by either) count me in!

OpenID's issue is with Apple's implementation being incomplete and not including the mitigations for some known security/privacy issues. This is because the very goal of the OpenID Foundation is to promote interoperable implementation. That's why they make testing tools available for free & open source, and why all the standards are 100% free to read / implement / use. I'm guessing you didn't read the link I shared, or had trouble understanding it. Here it is again: https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md

 I 100% agree that it's brilliant Apple are doing SIWA - I'm massively looking forward to as many apps as possible supporting SIWA.

luxuriant said:

The OpenID Foundation has pointed out that Apple's technology bears a lot of similarities with OpenID Connect, but has serious gaps affecting security and development.
Given its membership (https://openid.net/foundation/sponsoring-members/) I regret that I have to take any pronouncement from this source with a large grain of salt.

Regardless of your views on the motives of the members, Apple apparently consider the OpenID Connect protocol (which was created by the OpenID Foundation) a good enough protocol that they copied 99% of it.

Luckily the foundation published the full technical details of how they differ from the standard implementation here:

https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md

You're very welcome to review that and form a considered opinion as to whether or not Apple has issues in their implementation of OpenID Connect that could cause security and interoperability issues or not.

godofbiscuits said:

I trust OpenID if they say there are security holes. And given the importance and visibility to Apple, I’m sure they’ll address the security issues before releasing SIWA. 

‘As for compatibility with generic OpenID?  Nice for OpenID, but it would only muddy the waters when it comes to customers understanding what SIWA is all about. Id be surprised if Apple makes that a priority. 

None of this really matters to customers (beyond as you say, the 'is SIWA on the web, which already uses OAuth2 and much of OpenID Connect, vulnerable to known attacks on OAuth2 and OpenID Connect' question - and at this point I would agree that the commentary that the OpenID Foundation provided suggests that it is vulnerable, and I would imagine Apple will fix these issues before SIWA comes out of beta).

Compatibility with OpenID Connect matters for developers and anyone that wants to add 'Sign In With Apple' to their website. OpenID compatible means it's a tweak to configuration to add an extra OpenID provider (if the website already has OpenID integrated, e.g. has 'sign in with google') - if SIWA isn't OpenID compatible then it will require changes at the source code level, which may mean waiting for an upstream software vendor to release a version of their product that is compatible with the SIWA oddities and (depending how long it is since they last upgraded) a potentially long test / fix cycle before they can roll out SIWA support.

As an end user, I would personally prefer that Apple did everything in their power to make 'Sign in with Apple' as easy for developers to use as they can, and I think being interoperable with existing OpenID Connect libraries would help with that, especially as Apple are already using the OpenID standard.

I really really want to see app developers supporting SIWA rather than having to create new accounts, verify emails, etc, every time I install a new app that needs an account creating. (And whilst SIWA is going to be mandatory for apps that supported third party logins, it will be completely optional for apps that use their own first-party login system - it's this category of apps that have the choice of whether to adopt SIWA or not, and that choice will be a lot easier if SIWA is easy to implement for developers.)