#1

Mandatory button display when other provider button is displayed

[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]

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

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

#4

Verify Domain

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"

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 Requirements]

[Relaxed Requirements]

[Authorization Layer]

[Possible Results]

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

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

[Minimal Data]

[Purpose]

[Data Classifications]

[Green Data - Page 1]

[Green Data - Page 2]

[Yellow Data]

[Red Data]

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

[Page 186]

[Page 187]

[Page 188]

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

#10

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]