See the "prior art" screenshot. The "domain policy list" part is quite vague in the prior art. That part can be interpreted as "list of redirect URLs of a domain", but also can be argued as a "list of domains". i.e. "domain policy list" = "domain list". Apple going for the latter part. Let's just assume Apple's interpretation is correct.
My system deals with emails. So the developer provide a "list of domains" for the purpose of "sending emails". In the prior art, the developer provide a "list of domains" for the purpose of preventing "fake apps". Apple copying that step, so they can argue that as "obvious".
There is one problem here. My "list of domains" deals with "envelope domains".
Email is a hop-by-hop protocol. Meaning there can be multiple mail handling servers in
between the sending server and the receiving server. e.g. Retrying server, Spam checking
server, Virus scanning server etc. So the SMTP protocol was designed to mimic our physical postal system. i.e. Anyone can
be able to transmit emails for the domain they don't own. So "envelope domain" refers to the "postman". Not the "original sender".
The following are some of the examples of "envelope domain". Pay attention to the "mailed-by" part. That's the entity carrying the mail.
On the other hand, the "from" part you see in the screenshot is the "original sender".
The term "domain policy list" in the prior art refers to developer's "own domains". i.e. The developer provides their own domains to prevent fake apps. But "envelope domains" mainly deals with "third-party domains" in my version. So prior art version is not compatible with my version.
Apple's idea is to force all developers to use only their own domains. Pay attention to the "verify" option in all domains. By asking verification in all domains, they can make sure these domains are owned by the developer.
Verify all domains, even subdomains
In my invention the developer verify only the primary domain (i.e. The domain associated with the OAuth App). This is because, the domain owner use the DNS to provide additional domains. Apple asks the developer to verify all domains even subdomains to circumvent my invention.
Known trusted place
Apple trying to convert "known trusted place" as "known verified domain". That's the reason they are going for domain verification.
Interpretation has to be reasonable and consistent with the specification. The term "known trusted place" refers to "trusted information that only server would know" in the prior art.
So the "domain policy list" doesn't deal with domain verification at all. But Apple need domain verification to argue in court.
My white paper disclosed the DNS-based verification method. So they are going for the HTTP verification method.
Apple has a separate guidelines page for Websites and Other Platforms (i.e. Non iOS platforms)
Let's go back to the prior art. The "domain policy list" in the prior art is provided for preventing fake "mobile" apps. That means, the scope is limited to the "mobile platform". But, Apple wants the "Sign in with Apple" to be cross-platform. Especially they want "Sign in with Apple" to be accessible on the web.
My white paper heavily uses "web platform" as example for describing my entire invention. Apple is looking for "gaps" here to copy my work.
The following part is the primary reason why Apple betting on "Sign in with Apple JS".
4) But what about Android? What about web apps? I use my apps everywhere!
There’s a solution, but it’s not quite as seamless.
If a user signs up for an app on their Apple device — like, say, their iPad — then wants to use the app on a non-Apple device, like their Android phone, they’re sent over to a web view.
Here, they’ll see a Sign in with Apple login screen where they’ll enter their Apple ID and password to complete the sign in. This would also be the case for web apps that need to offer the Sign in with Apple login option.
(Apple does not offer a native SDK for Android developers, and honestly, it’s not likely to do so any time soon.)
So they changed the wording to "system-provided" after realising I protected that part.
The following are some of the notable companies that displays "Sign in with Apple" on their website login/signup pages by trusting Apple. i.e. These companies are violating my IP.
Adobe, Dropbox, Airbnb, Airbnb, Medium, Spotify, WordPress, Vimeo, Meetup, Buzzfeed, Grammerly
Note: Those companies are needle in a haystack. Plenty of websites out there supports "Sign in with Apple".
To quote this page,
This past summer Apple announced their new "Sign in with Apple" feature (SIWA from here on out).
Unfortunately things aren't so streamlined for developers who want to provide SIWA for their users on websites, as Apple has deviated enough from existing standards to require custom implementation (i.e. you can't use your generic OAuth2 code).
To quote auth0 page,
Luckily for the community, Apple decided to adhere to open standards to support the Sign In with Apple feature. They don't publicly say that they are using these standards, and there is not a single mention of them in the official documentation. However, as you will see in the sections that follow, Apple is using parts of the OAuth 2.0 and OpenID Connect (OIDC) standards.
My white paper uses "OAuth2" protocol for describing my invention. [Screenshot].
Since Apple trying to copy my invention, they need to be far away from my invention to throw nonsense arguments in court. Because of that, they decided to be not compatible with OAuth2.
OpenID Connect Support
OpenID Connect relies on OAuth2.
Initially "Sign in with Apple" was not compatible with OpenID Connect. OpenID Foundation Chairman, Nat Sakimura wrote an Open Letter to Craig Federighi asking "Sign in with Apple" to be compatible with "OpenID Connect" and asked Apple to join the OpenID Foundation. Because of that, Apple is now
compatible with OpenID Connect.
HTTP POST Method
Typical "Sign in with X" type buttons uses HTTP GET method. "Sign in with Apple" on the other hand, uses HTTP POST method for delivering the data.
The following part is the reason.
Must include a domain name
They don't allow IP address or localhost for redirect uri.
The following part is the reason. i.e. Prior art deals with URL, not URI
The Web Connection
Apple's entire heist is centered around the "domain policy list" provided for preventing fake "mobile" apps. So pay attention to the "your app's accompanying website" part.
My disclosure covered the "native mobile applications" part.
Let's go back to the prior art. The "domain policy list" in the prior art is provided for preventing fake "mobile" apps. That means, the scope is limited to the "mobile platform". Not all mobile platforms. Just the mobile platform owned by the identity provider (in this case Apple iOS platform).
Apple wants you to use the same Sign in with Apple JS for Android too.
Also refer the Techcrunch answer I linked.
(Apple does not offer a native SDK for Android developers, and honestly, it's not likely to do so any time soon.)
App Store Connection
The part "your app's accompanying website" implies you already have an app in the "App Store". But when I tested their system, they didn't check whether I have an App on the "App Store" before allowing me to get credentials for web.
To my surprise, one developer already asked this question in stackoverflow. And
an engineer named DaveAMoore from "Sign in with Apple" team commented on that question.
After seeing my patent claims, Apple added the following in their guidelines.
This is my patent claim:
If you are a developer, keep these things in mind if you support "Sign in with Apple".
(1) The present version of "Sign in with Apple" requires you to place an App on their "App Store" to use it in websites and other platforms. [If you are one of the early adopters of "Sign in with Apple", they didn't perform this check. So there is higher chance you maybe violating our IP.]
(2) If you get banned from App Store OR you voluntarily remove your app from their App Store, you cannot display "Sign in with Apple" in websites and other platforms.
(3) If you get banned from App Store OR you voluntarily remove your app from their App Store, you cannot send emails to your EXISTING "Sign in with Apple" users.
(4) Apple had a history of banning apps from the App Store and it's ugly. e.g. Email app returns to Mac App Store after 8-month fight with Apple.
(5) Apple guidelines says:
Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time.
(6) In the future, "Sign in with Apple" probably not gonna work properly in other platforms, especially web and Android. So it's not really a cross platform product.
(7) You probably violating our provisional rights at the moment and gonna infringe our patent if it gets granted. That's something you should take seriously. This is because, some part of our claims directed towards you (i.e. developers). So we are talking about "Direct Infringement" here.