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.
If that looks rude to the counterpart, it doesn't really matter; everyone knows any politeness is fundamentally insincere anyway, because if one had not wanted to ruffle their feathers, one wouldn't have published anything in the first place.
The lack of nonce makes replay protection impossible. The lack of c_hash opens up vulnerabilities in connect flows where the service incorrectly assumes the two tokens refer refer to the same user. Returning the id token on the query leaks it in the Referer header.
Apple are actually following the OpenID standard, that's why the list is differences is concise and to the point. Several of the pieces that are missing/different are items that were added to OpenID to prevent attacks that have been used against pure OAuth 2.
Many of the potential attacks relate to fooling the third party sites as to what happened, so it is difficult/impossible to mitigate them with magic on Apple's side.
(disclaimer: I'd listed as a contributor on above doc. I'm writing here in a purely personal capacity.)
>In particular it's "signing with apple on the web" that they've analysed, which is open for anyone to analyze using the developer tools in a browser etc.
Why is it I am getting the idea Apple just aren't very good with the web. I am reading it as Sign In with Apple ID is secure on the devices, iOS and App, but not when used on the web.
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.
Really curious for the reason behind that. If they would've mentioned it there probably would have been quite a bit less of lock-in criticism for the product. But maybe they are also banking on the devs not realizing that they aren't that locked in and have an easy option to move away.
The main requirement therein I would say is that you can't use OpenID to describe an implementation unless it implements the mandatory-to-implement parts of the relevant protocol specification (and all the specifications are 100% free; e.g. https://openid.net/specs/openid-connect-core-1_0.html ). That's more about interoperability than anything else.
"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.
But the reason is because "optics" and "perspective" don't mean the same thing.
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.)