Apple copied our product as "Sign in with Apple"

Avoid Premature Judgements

To quote an engineer who seem like completed only 25% of this article,

The list of similarities appears to me to be mostly surface-level trivialities of marketing copy rather than technical details, and I see no outright plagiarism.

They actually copied the technical details. It's well explained in the section titled "How Apple copying our work?".

For example, This is what our patent claim says,

This is what Apple guidelines say,

This is what Developers say,

Do you really think, Apple would ask their developers to place an App on the App Store to use it on websites if this is their original work?

The Short Version

My name is Viruthagiri Thirumavalavan. I'm the founder and principal engineer of Dombox, a privacy-focused, spamless mail system.

In February 2019, I published my entire research in a 300-page white paper and shared it in a mailing list called NANOG. Apple seem like copied my work brick-by-brick from my white paper, released it as "Sign in with Apple" without my permission in June 2019.

I have tried to reason with Apple privately. But they are completely denying it's my work. "Sign in with Apple" deals with registration, login and email communication. Those are the main pillars for an internet business. If "Sign in with Apple" breaks, then it's gonna cause economical issues. So, I'm disclosing everything here as a last resort to warn the developers.

What exactly Apple copied?

The following table describes the list of ideas copied from the paper I published. For the sake of clarity, I published my white paper in February 2019. Apple released "Sign in with Apple" in June 2019.

The column "Teleport" describes the original version from my white paper. [Note: "Teleport" is renamed as "Sign In with Dombox" for better branding.]

"OAuth Clients" are termed as "Portals".

A domain that supports our "Teleport" button is termed as "Portal Partner / Teleport Partner".

Note: This table is a simplified version. For a more detailed version that contains EVIDENCE, refer the table below titled "How Apple copying our work?"

Teleport
aka. Sign In with Dombox
[Original Version]
Sign in with Apple
[Copied Version]
Mandatory button display when other provider button is displayed [Page 149]

[Sign In With Apple Will Be Required for Apps That Offer Third-Party Sign-In Options]

[My mail to Tim Cook and Apple Lawyer on Sep 01]

[Apple added section 4.8 after my mail] [Archive Link]

[Before my mail, there is no Section 4.8] [Archive Link]

Force the button to display first [Page 124] [Apple asks developers to place its login button above Google, Facebook]
Add Domain [Page 126] [Copied Version]
Verify Domain [Page 127] [Copied Version]
Associate the domain [Page 131] [Copied Version]
Redirect Uris [Page 132] [Copied Version]
Ask the domain owner to provide a list of mail sending domains [Page 65]
[Page 66]
[Copied Version]
Mandate SPF record

[Original Requirements]

[Relaxed Requirements]

[Authorization Layer]

[Possible Results]

[Copied Version]
Check the domain is SPF/DKIM compliant [Page 128] [Copied Version]
Envelope Domain Whitelisting

[Page 65]

[Definition]

[Copied Version]

Provide only minimal data to websites and apps

[Minimal Data]

[Purpose]

[Data Classifications]

[Green Data - Page 1]

[Green Data - Page 2]

[Yellow Data]

[Red Data]

[Copied Version]

Allow the button only for Signup and Login

[Page 186]

[Page 187]

[Page 188]

[Refer video below]

Criticising "Google" and "Facebook"

[Page 182]

[Page 183]

[Page 292]

[Page 294]

[Tim Cook Says Apple Sign In Isn't "Taking a Shot at Anybody," but It Definitely Is]

[Google product director annoyed by Apple's SSO jab but encourages 'Sign in with Apple' over using passwords]

They even copied the description

[Page 117]

[Page 295]

[Copied Version]

"Sign in with Apple" Announcement

Of all the products Apple announced in their WWDC 2019 event, "Sign in with Apple" is the most talked product.

At 0:12, "We wanted to solve this, and many developers do too. So, now we have a solution" - Craig Federighi

Sign In with Apple License

The following is what "Sign in with Apple" license says: [Direct Link]

# Sign In with Apple License

**IMPORTANT:** This Sign In with Apple software is supplied to you by Apple Inc. ("Apple") in consideration of your agreement to the following terms, and your use, reproduction, or installation of this Apple software constitutes acceptance of these terms. If you do not agree with these terms, please do not use, reproduce or install this Apple software.

This software is licensed to you only for use with Sign In with Apple that you are authorized or legally permitted to embed or display on your website.

The Sign In with Apple software is only licensed and intended for the purposes set forth above and may not be used for other purposes or in other contexts without Apple's prior written permission. For the sake of clarity, you may not and agree not to or enable others to, modify or create derivative works of the Sign In with Apple software.

You may only use the Sign In with Apple software if you are enrolled in the Apple Developer Program.

Neither the name, trademarks, service marks or logos of Apple Inc. may be used to endorse or promote products, services without specific prior written permission from Apple. Except as expressly stated in this notice, no other rights or licenses, express or implied, are granted by Apple herein.

The Sign In with Apple software software is provided by Apple on an "AS IS" basis. APPLE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, REGARDING THE SIGN IN WITH APPLE SOFTWARE OR ITS USE AND OPERATION ALONE OR IN COMBINATION WITH YOUR PRODUCTS, SYSTEMS, OR SERVICES. APPLE DOES NOT WARRANT THAT THE SIGN IN WITH APPLE SOFTWARE WILL MEET YOUR REQUIREMENTS, THAT THE OPERATION OF THE SIGN IN WITH APPLE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, THAT DEFECTS IN THE SIGN IN WITH APPLE SOFTWARE WILL BE CORRECTED, OR THAT THE SIGN IN WITH APPLE SOFTWARE WILL BE COMPATIBLE WITH FUTURE APPLE PRODUCTS, SOFTWARE OR SERVICES. NO ORAL OR WRITTEN INFORMATION OR ADVICE GIVEN BY APPLE OR AN APPLE AUTHORIZED REPRESENTATIVE WILL CREATE A WARRANTY.

IN NO EVENT SHALL APPLE BE LIABLE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) RELATING TO OR ARISING IN ANY WAY OUT OF THE USE, REPRODUCTION, OR INSTALLATION, OF THE SIGN IN WITH APPLE SOFTWARE BY YOU OR OTHERS, HOWEVER CAUSED AND WHETHER UNDER THEORY OF CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, EVEN IF APPLE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF LIABILITY FOR PERSONAL INJURY, OR OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS LIMITATION MAY NOT APPLY TO YOU. In no event shall Apple's total liability to you for all damages (other than as may be required by applicable law in cases involving personal injury) exceed the amount of fifty dollars ($50.00). The foregoing limitations will apply even if the above stated remedy fails of its essential purpose.

Sign In with Apple Guidelines

Their guidelines says: [Direct Link]

When they say "Infringes or violates the intellectual property, publicity, or privacy rights of another", they are referring to our work. If you support "Sign in with Apple" button, then as of this moment you are violating our "provisional rights".

"Sign in with Apple" Conditions

This is how they force Apps to support "Sign in with Apple" button.

Apple is forcing you to violate/infringe our IP. Even the "mandating button" aspect got stolen from us.

The Timeline.

February 14, 2019

I filed a provisional patent application to record my invention in the USPTO. This is an evidence that I invented the system that's being advertised as "Sign in with Apple".

Certified copy can be downloaded from WIPO patentscope website. [Download Link]

Relevant Figures: Fig. 1004 to Fig. 1027

Relevant Pages: 75 to 106

February 17, 2019

I published a 300-page white paper.

Also published my system summary in a medium blog post.

Shared those materials in the NANOG mailing list.

June 03, 2019

Craig Federighi introduced my work as "Sign in with Apple" in Apple's WWDC event by saying "We wanted to solve this, and many developers do too. So, now we have a solution"

June 06, 2019

3 days after their product announcement, I sent an email to Apple CEO Tim Cook and Apple's Legal team.

June 10, 2019

4 days later, David Schumann from Apple responded.

Attachment

We have adopted this policy due in part to the large volume of information received and to avoid potential misunderstandings or disputes when Apple's products or marketing strategies might seem similar to ideas made available to Apple.

They actually announced a product with (a) exact steps as mine (b) exact strategy as mine (c) in the exact year as mine. But that's the best version they could come up with for copying my product (Teleport) and marketing strategy (Mandating button).

Ideas don't fall from the tree. For an inventor, it takes a very long time to come up with these ideas. Each and every step of the product conceived at a different point of time to address different issues.

I actually started my research in 2013. It was called "XMail" at that time. I even tried to acquire the domain xmail.com in 2014

I made good progress by 2016. The word "XMail" already trademarked by someone. So I changed the name to "Dombox" in 2016. I applied for trademark and described the meaning of the words "Dom" and "box".

My point is, when I published my paper in Feb 2019, there was a 5 year history. The ideas they found in my paper is the final iteration of my work. There were many failed iteration before.

So when "David Schumann" say, they built "Sign in with Apple" without reference to any of my information or writings, he is talking about some kind of "miracle".

It didn't take much time for me to figure out how they are copying my work. I'll explain this later.

September 01, 2019

I sent an email to both David Schumann and Tim Cook explaining the situation.

The PDF named "Teleport Infringement" explains how they are infringing my work. Another PDF titled "SIGNED-PCT..." is a copy of my PCT application with claims. At this point of time, I was hoping that they would stop putting these developers at risk.

This is how their guidelines page looked when I sent that mail. Pay attention: there is no "Section 4.8" [archive link]

September 12, 2019

Apple updated their guidelines page on September 12.

To quote that page:

We've updated the App Store Review Guidelines to provide criteria for when apps are required to use Sign in with Apple. Starting today, new apps submitted to the App Store must follow these guidelines. Existing apps and app updates must follow them by April 2020. We’ve also provided new guidelines for using Sign in with Apple on the web and other platforms.

This is how their guidelines page looked on September 14. [Archive Link]

Before my mail, Apple had no idea when my patent application gets published, what is the priority date, how my patent claims look like etc. Now David Schumann went into full copying mode. So much for a company that respect intellectual property of third parties.

What is the real invention?

To understand what Apple is copying, you need to understand the real invention.

When I started my research in 2013, I only wanted to find a way to address email spam issues without relying on spam filters. But along the way, I found a way to address privacy issues too. Apple copying only the "intermediate" part of my system.

Expand this section to get a quick overview about the real system I invented.

Domboxes

Domboxes deal with "Non-Conversational Mails".

Dombox is the short form for "Domain-based Isolated Mailbox".

Users are gonna create a separate mailbox for each domain. Each of this separated (i.e. Isolated) mailbox is called Dombox.

The following image shows the dombox address structure.

Dombox Domain - By default, a dombox can accept mails only from the domain it was created for. Since the domain is tied to the Dombox address it is called "Dombox Domain".

Domkey - Domkey stands for "Dombox Global Keyword". i.e. All Dombox addresses gonna use this key to make them unique. Domkey is a unique string just like a username. You set this only once. You need to set the Domkey before creating your first Dombox. This is how you set Domkey.

New Dombox - This is how you create Dombox.

Sender Alias Domains (SAD)

Now let’s go back to our dombox address structure.

{Dombox Domain}@{Domkey}.{Receiver Domain}

Let's create a Dombox for "google.com". The created Dombox address would look like this.

[email protected]

The above address can accept mails only from google.com

Direct Pass

When the Sending Domain == Dombox Domain

MAIL FROM:<[email protected]google.com>

RCPT TO:<google.com@giri123.domboxmail.com>

Sending Domain: google.com

Dombox Domain: google.com

We make sure the incoming mails are not spoofed by fetching SPF record from google.com. After this process, the mail will be accepted without any issues. Thus, it is a direct pass.

Indirect Pass

When the Sending Domain ≠ Dombox Domain, then we go for indirect check.

Google's primary domain is google.com. But Google owns hundreds of other domains as well. e.g. adsense.com, adwords.com, youtube.com etc.

We cannot force the user to create a separate Dombox for each domain. On the other hand, we cannot force Google to send mails only from google.com.

There should be some flexibility. Hence, I introduced a new DNS TXT record type called "SAD Record". If you are familiar with SPF record, then it’s the same thing. But for whitelisting domains instead of IP addresses. SPF deals with MAIL FROM domain. SAD deals with RCPT TO domain. So it can be termed as "Receiver Policy Framework".

Just to be clear, the SAD record is related to domboxes and it needs to be placed in the "Dombox Domain".

[email protected] => google.com is the "Dombox Domain"

MAIL FROM:<[email protected]youtube.com>

RCPT TO:<google.com@giri123.domboxmail.com>

Sending Domain: youtube.com

Dombox Domain: google.com

To allow mail from "[email protected]" to the google.com dombox, google.com should have the following SAD record in _sad.google.com

_sad.google.com => "v=sad1 youtube.com -all"

SAD Record can contain multiple domains.

_sad.google.com => "v=sad1 adsense.com adwords.com youtube.com -all"

Sample SMTP Chat

twitter.com connecting with its IP address [54.156.255.69]
220 mail.domboxmail.com Dombox SMTP Service Ready
HELO mail.twitter.com
250 Hello, nice to meet you, mail.twitter.com
MAIL FROM:<[email protected]>
Fetching SPF record from MAIL FROM domain twitter.com.
"v=spf1 ip4:199.16.156.0/22 ip4:54.156.255.69 -all"
IP address [54.156.255.69] is ALLOWED to send mails for twitter.com.
250 OK
RCPT TO:<[email protected]>
250 OK
RCPT TO:<[email protected]>
MAIL FROM domain is not amazon.com.
So fetching SAD record from _sad.amazon.com.
"v=sad1 amazon.co.uk amazon.ca amazon.in -all"
MAIL FROM domain twitter.com not whitelisted in amazon.com SAD.
550 SAD Failure. Refer https://domboxmail.com/solutions/sad
RCPT TO:<[email protected]>
MAIL FROM domain is not facebook.com.
So fetching SAD record from _sad.facebook.com.
No SAD record found. Falling back to SPF record.
Fetching SPF record from facebook.com.
"v=spf1 ip4:66.220.144.128/25 ip4:69.171.244.0/23 -all"
IP address [54.156.255.69] is NOT ALLOWED to send mails for facebook.com.
550 SAD Failure. Refer https://domboxmail.com/solutions/sad
QUIT
221 Bye
                

Tools

At this point, we have a proper dombox address structure that's compatible with all 300+ million internet domains. However, the end users need to visit our product, enter the domain manually to create a dombox. I wanted to simplify the process. The end result is the following products.

Sign In with Dombox - "Sign In with Dombox" is a privacy-focused alternative for "Sign in with Google" and "Sign in with Facebook". "Sign In with Dombox" offers minimal data to websites and apps. This is what Apple copied. [Learn more about the product]

Subscribe with Dombox - Our One-Click Newsletter Subscription Service. It's like "Facebook Like" button you see on websites, but for collecting subscribers. [Learn more about the product]

Contract with Dombox - This is a business-friendly variation of our product "Sign In with Dombox". Apple copied the "mandating button" aspect from this product.[Learn more about the product]

Pre-SignUp with Dombox - This is for budding entrepreneurs. To collect leads while they are working on their product. [Learn more about the product]

Generate with Dombox - Browser extensions for generating dombox address. [Learn more about the product]

Spam Solution

At this point, we offloaded all "Non-Conversational Mails" into "Dombxoes". The only thing that's left is "Conversational Mails". We deal with the "Conversational Mails" via a dedicated single email address aka. "Conversational Email Address (CEA)".

The term "Conversational Mails" can be termed as Mailbox-to-Mailbox / MX-to-MX / Human-to-Human emails.

Conversational Email Address (CEA) works just like a typical gmail address. i.e. It can accept mails from anyone on the internet. But it checks whether the sender is human by mainly relying on MX record checks.

Conversational Email Address (CEA) - To learn more about Conversational Email Address visit this page.

Sign in with Apple

Sign In with Dombox + Sender Alias Domains + Contract with Dombox = Sign in with Apple

If Apple get away with my work, then they are gonna sell more iPhones and Macbooks by saying some big words like "Privacy is a fundamental human right". But it's going to be a big loss for the world. That's because my spam solution is viable and scalable. And my privacy solution is built for everyone. Not just for Apple users.

Apple is going to heavily stifle innovation in both privacy and spam fields.

Patent Basics

Apple copying my work by forcing their "App Store" developers to support "Sign in with Apple". Most of them have no idea how patent works.

The following is a response from a "Sign in with Apple" developer when I tried to explain him what's going on.

Email masking has been around forever. You've thought of nothing new, save some weird proprietary <thing> to make your patent seemingly valid. You’d have no case anywhere since it’s in common use by many, many, many companies and has been for a long time.

You get patent for inventive steps. Not for an entire category.

It is the "nuances" that matter for patent law. If you don't know how patent works, then expand this section to get a quick overview about patents.

Patentability mainly focuses on two things. Novelty and Non-Obviousness. In some countries, the latter part is called as "Inventive Step".

Novelty - The "Novelty" principle asks whether the invention was known to the public "exactly as described" before the filing date of the patent application. Novelty is straightforward. You either invented something or you don't.

Non-Obviousness - The "Non-Obviousness" principle asks whether the invention is an adequate distance beyond what's already known to the public.

Determining "Non-Obviousness" is extremely hard. So courts sometimes have to rely on secondary considerations for determining non-obviousness. To quote Federal Circuit which is known for its decisions on patent law, "evidence of secondary considerations may often be the most probative and cogent evidence in the record".

So "non-obviousness" deals with questions like (1) Is the invention commercially successful? (2) Did others fail before? (3) Are people praising the invention, especially competitors? (4) Did the invention recognize a problem that has never been recognized before? (5) Are competitors trying to copy the invention? etc.

Prior Art - One way or another, all form of invention rely on already known ideas. For example, my "Teleport" button [or "Sign in with Apple" button if you prefer], is an improvement over buttons like "Sign in with Google" and "Sign in with Facebook".

If your invention do not have any prior art, that means you either ahead of its time (e.g. Someone invented an iPhone in the 18th century) OR you are not working on a notable problem i.e. If the problem is notable, then others tried to solve it and failed.

Any publicly available evidence which is close to the invention is called as "Prior Art". In my invention's case, it is WO2014105263A1. Apple copied my work with the help of that document. So from this point forward, the term "Prior Art" refers to WO2014105263A1.

Provisional Rights - "Provisional rights" allow a patent owner to collect damages from the infringers for activities occurring between "the date of the patent application publication" and "the patent granting date".

Patent - A patent is a government license that exclude others from making, using, or selling the invention without the inventor's permission for a limited period of time. This period is usually 20 years. Patent system's main purpose is to encourage innovation. A patented cancer cure is better than not having a cure at all.

Patent Infringement - Patent infringement occurs once the patent get granted. Patent laws are country-specific. Under US law, 35 U.S. Code § 271 states the following:

(a) Except as otherwise provided in this title, whoever without authority makes, uses, offers to sell, or sells any patented invention, within the United States or imports into the United States any patented invention during the term of the patent therefor, infringes the patent.

(b) Whoever actively induces infringement of a patent shall be liable as an infringer.

Direct Infringement - It occurs when the main party makes, uses, offers to sell, or sells the invention without the inventor's permission.

The term "main party" depends on the claim language. From the Apple perspective "Sign in with Apple" is a product. From the Developer perspective "Sign in with Apple" is a "medium" for sending mails. The "main party or parties" doesn't need to know that a patent exists in order to be held liable.

Indirect Infringement - Secondary liability, or indirect infringement, arises when a party materially contributes to, facilitates, induces, or is otherwise responsible for infringing acts carried out by the main party.

Induced Infringement - A form of Indirect Infringement where the party "cause[s], urge[s], encourage[s], or aid[s]" the infringing acts carried out by the main party. e.g. media articles and bloggers who goes like this. Why you should begin using Sign in with Apple.

How Apple copying our work?

#1

Mandatory button display when other provider button is displayed

Original Version [Page 149]
Prior Art Version [Not Found in the Prior Art]
Apple Version

[Sign In With Apple Will Be Required for Apps That Offer Third-Party Sign-In Options]

[My mail to Tim Cook and Apple Lawyer on Sep 01]

[Apple added section 4.8 after my mail] [Archive Link]

[Before my mail, there is no Section 4.8] [Archive Link]

Notes

In countries like US, you can have "business method patents". Business method patents are a class of patents which disclose and claim new methods of doing business. e.g. Amazon One-Click patent.

Since we are a startup, I had to come up with a unique business method to acquire more developers. I actually spent more than an year in shaping that idea. Here is the full version of that idea.

Since we are dealing with "Developer Acquisition", The value of this "business method" lies in the early years. When it comes to getting a patent, it takes many years due to backlog. By the time we get the patent, Apple would have captured the entire market with our idea. That's their plan.

The "Before" and "After" version of the market would look like this.

This is the transcript Apple gave to Techcrunch in June 2019.

9) When does an app have to offer Sign in with Apple?

Apple is requiring that its button is offered whenever another third-party sign-in option is offered, like Facebook’s login or Google. Note that Apple is not saying “social” login though. It’s saying “third-party,” which is more encompassing.

This requirement is what’s shocking people as it seems heavy-handed.

But Apple believes customers deserve a private choice, which is why it’s making its sign-in required when other third-party options are provided.

But developers don’t have to use Sign in with Apple. They can opt to just use their own direct login instead. (Or they can offer a direct login and Sign in with Apple, if they want.)

The following is the original version.

Don’t get us wrong. You are welcome to remove our “Teleport” button as long as you don’t allow signup / Login via any other methods. e.g. Signup Forms, Facebook connect, Google connect etc.

I used Facebook connect and Google connect as examples. Apple trying to justify their case by excluding "social login" methods. Apple is not saying “social” login though. It’s saying “third-party,” which is more encompassing..

p.s. My white paper never mentioned anywhere that it ONLY deals with "social login". In fact, there are pages that clearly shows my white paper deals with non "social login" buttons. e.g. Page 116 contains the following image.

#2

Force the button to display first

Original Version [Page 124]
Prior Art Version [Not Found in the Prior Art]
Apple Version [Apple asks developers to place its login button above Google, Facebook]
Notes

In my paper, I grouped all other signup options in a button called "Others".

The idea is that, you display our "Teleport" button first since it is a privacy-focused button. But, you put rest of the options like "Sign in with Google", "Sign in with Facebook" etc. in a button called "Others". Just to be clear, this is optional in the system I invented.

That's what Apple copied here. They are doing that in two phases.

Phase 1: Ask the developers to display their button first.

Phase 2: The "Others" button. Once "Sign in with Apple" button gets popular they will go for this phase.

#3

Add Domain

Original Version [Page 126]
Prior Art Version [Prior Art Version]
Apple Version [Copied Version]
Notes Self-Explanatory

#4

Verify Domain

Original Version [Page 127]
Prior Art Version [Not Found in the Prior Art]
Apple Version [Copied Version]
Notes

I used DNS-based domain verification method which is the typical domain verification method. They are using HTTP method to distant themselves from my invention. Refer next section to know more.

#5

Ask the "developer" to provide "whitelisted domains"

Original Version
Prior Art Version
Apple Version
Notes

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".

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".

Domain Verification

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.

HTTP Verification

My white paper disclosed the DNS-based verification method. So they are going for the HTTP verification method.

Web Platform

Apple has a separate guidelines page for Websites and Other Platforms (i.e. Non iOS platforms)

System-Provided Javascript

If you are a developer, there is a higher chance "a system-provided javascript API" part may sound odd to you. That text is added there to justify their case.

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 primary reason they are betting on "JavaScript" is because they missed a key point. When Apple released their product in June 2019, they had access to only my published white paper. The provisional application I filed before publishing my white paper had more content actually. It was not public at that time.

The following part is the primary reason why Apple betting on "Sign in with Apple JS".

Apple thought I didn't cover the "javascript-based" part in my invention. But I actually covered that part in the provisional application I filed before publishing my white paper.

This is the transcript Apple gave to Techcrunch in June 2019. [Pay attention to the "JavaScript-based" part.]

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.

This option is called Sign in with Apple JS as it’s JavaScript-based.

(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".

OAuth2 Support

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.

Android

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:

#6

Mandate SPF/DKIM record

Original Version

[Original Requirements]

[Relaxed Requirements]

[Authorization Layer]

[Possible Results]

Prior Art Version
Apple Version
Notes

SPF was introduced in 2006. DKIM was introduced in 2007. But the email system we use today, was introduced in 1982. So when both SPF and DKIM was introduced, there was a 25 year SMTP history. We can't introduce a standard today and expect all SMTP servers to support it instantly. So both SPF and DKIM are "complimentary" mechanisms. i.e. Domain owners voluntarily support SPF and/or DKIM to help the receiving mail servers.

Modern mail servers validate SPF and DKIM records, rejects the mail ONLY when the validation result is "FAIL". If the validation result is "NEUTRAL" (i.e. SPF and DKIM are not configured), then the mail rejection will not happen.

The prior art says "rejects the e-mail message if invalid". This means the system works as a typical modern mail server. i.e. The mail will be rejected if the SPF or DKIM validation results in "FAIL"

My system works very differently. Both SPF and DKIM are "mandatory" mechanisms. i.e. The domain owner MUST configure those records.

We reject both "FAIL" and "NEUTRAL" mails. Put it this way, we accept only when the mail result is "PASS". That's what "Must Pass" means in the above screenshot.

I forced all the sending domains to configure SPF/DKIM record. So the system works like "accepts the e-mail message ONLY when valid". That's what Apple copied here.

There is a difference between "rejects the e-mail message if invalid" and "accepts the e-mail message ONLY when valid". The former works in the following principle. "ALL MAILS MUST BE ACCEPTED UNLESS PROVEN GUILTY". The latter works in the following principle. "ALL MAILS MUST BE REJECTED UNTIL PROVEN INNOCENT".

#7

Check the domain is SPF/DKIM compliant

Original Version
Prior Art Version [Not Found in the Prior Art]
Apple Version [Copied Version]
Notes

Originally I wanted to mandate both SPF and DKIM. But later I removed the DKIM requirement.

SPF record is stored in the root path. i.e. A query like "dig TXT facebook.com" would reveal whether the domain support SPF or not.

But for DKIM the path looks like this. "dig TXT selector._domainkey.facebook.com". The "selector" part is an arbitrary string. It can be anything. You need to have the full email message to check whether the domain support DKIM or not. This is why my "original" version is asking the domain owner to send a test email to a randomly generated email address. Apple is going for my amended version.

#8

Provide only minimal data to websites and apps

Original Version

[Minimal Data]

[Purpose]

[Data Classifications]

[Green Data - Page 1]

[Green Data - Page 2]

[Yellow Data]

[Red Data]

Prior Art Version
Apple Version
Notes

For their "privacy" propaganda, demographic information, address and advertising preferences are not gonna be useful. So they skipped that.

#9

Allow the button only for Signup and Login

Original Version

[Page 186]

[Page 187]

[Page 188]

Prior Art Version [Not Found in the Prior Art]
Apple Version

Since they offer only name and email address, they are using "Sign in with Apple" only for Signup and Login.

Notes Self-Explanatory

#10

Criticising "Google" and "Facebook"

Original Version

[Page 182]

[Page 183]

[Page 292]

[Page 294]

Prior Art Version [Not Found in the Prior Art]
Apple Version

[Tim Cook Says Apple Sign In Isn't "Taking a Shot at Anybody," but It Definitely Is]

[Google product director annoyed by Apple's SSO jab but encourages 'Sign in with Apple' over using passwords]

Notes Self-Explanatory

Relevant Documents

Provisional Application Download Link
White Paper Download Link
Patent Application WO2020039327
Prior Art WO2014105263A1

Updates

13 April 2020

Apple gave up "domain verification" part after seeing my patent claim. [Before] [After]

My Patent Claim

Result

Contact

I'm not a lawyer. I cannot help you with legal questions. But if you have a general query, please send an email to [email protected]