diff --git a/.idea/.gitignore b/.idea/.gitignore
new file mode 100644
index 0000000..13566b8
--- /dev/null
+++ b/.idea/.gitignore
@@ -0,0 +1,8 @@
+# Default ignored files
+/shelf/
+/workspace.xml
+# Editor-based HTTP Client requests
+/httpRequests/
+# Datasource local storage ignored files
+/dataSources/
+/dataSources.local.xml
diff --git a/.idea/authBook.iml b/.idea/authBook.iml
new file mode 100644
index 0000000..5e764c4
--- /dev/null
+++ b/.idea/authBook.iml
@@ -0,0 +1,9 @@
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/.idea/modules.xml b/.idea/modules.xml
new file mode 100644
index 0000000..8b63970
--- /dev/null
+++ b/.idea/modules.xml
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/.idea/vcs.xml b/.idea/vcs.xml
new file mode 100644
index 0000000..94a25f7
--- /dev/null
+++ b/.idea/vcs.xml
@@ -0,0 +1,6 @@
+
+
+
+
+
+
\ No newline at end of file
diff --git a/Big Ideas/Topics.md b/Big Ideas/Topics.md
new file mode 100644
index 0000000..f352939
--- /dev/null
+++ b/Big Ideas/Topics.md
@@ -0,0 +1,95 @@
+# List of topics that this book can cover
+
+1. [Authentication](./Authentication.md)
+2. [Authorization](./Authorization.md)
+3. [OAuth](./OAuth.md)
+4. [OpenID](./OpenID.md)
+5. [SAML](./SAML.md)
+6. [JWT](./JWT.md)
+7. [SAML vs OAuth vs OpenID](./SAML%20vs%20OAuth%20vs%20OpenID.md)
+8. [OAuth vs OpenID](./OAuth%20vs%20OpenID.md)
+
+
+## Questions I need to answer before attempting to write this book
+
+1. Do I strictly focus on authentication or expand it to authorization and security in general?
+2.
+
+## Topics
+
+### Why listen to this guy?
+
+### What this book is
+
+### What this book is not
+
+### What are you authenticating?
+
+ * Users
+ * Anonymous
+ * System services
+ * Third parties
+ * Distributed and decentralized applications
+
+### What are you authenticating for?
+
+ * Shoppers - allowing a user to save and access their information for future use
+ * Security - applying authorization (including Paid access or limiting ability to administrate)
+ * Paid access - limiting access to paid users
+ * User tracking - do we really need to do this?
+
+### How are you authenticating
+
+ * Something you know
+ * Something you have
+ * Something you are
+ *
+
+### Layers of security
+
+The following list was derived from https://identitymanagementinstitute.org/layered-security-model/
+
+ * Physical security
+ * Network security
+ * Application security (you are here!)
+ * Data security
+ * User education on security
+
+### Developer Experience
+
+ * Consider the experience of a developer who has to apply your authentication
+ * Compare to physical security, when you make an area well lit, highly visible, and easily accessible the place by default becomes more secure when compared to a dark hidden ally-way. You didn't need to add a security guard.
+ * When your authentication infrastructure is easy to apply or applied by default, your application automatically becomes more secure.
+
+### User Experience
+
+ * Consider the user experience as a way of making your application more secure (see also physical security comparison in developer experience)
+ * Why passwords are still useful
+ * Familiarity - people have used passwords in many applications, it isn't new to them
+ * Ease of use (unless done right) - example of FHIR client
+ * Ease of implementation - low barrier to entry
+ * Inexpensive (unless hacked)
+ * Scalability
+ * No specialized hardware
+ * Versatility (standalone, or as part of a mfa system, or versatility in how it is implemented)
+ * User choice (choosing their own passwords)
+ * Encourages users to be aware of their security
+ * Ease of recovery
+ * User autonomy - users have full control over their passwords, changing them when they want
+ * Why passwords should die
+ * Weak passwords
+ * Password reuse
+ * Phishing vulnerability
+ * Credential Stuffing - using stolen creds to gain access
+ * Password management challenges - putting all passwords into a single basket (pw manager)
+ * Brute-force attacks
+ * Password recovery risks - security questions, email resets etc can be susceptible to social engineering
+ * Limited security - it is a single factor (something you know)
+ * Support costs - the trade-off you get because of the low cost of implementation
+ * Password Policy Complexity
+ * User Resistance
+ * Password hash storage
+ * Limited accountability - sharing of passwords
+ * Less convenience compared to biometrics or other technology
+ * The case for WebAuthn and other asymmetric cryptographic authentication
+ *
diff --git a/readme.md b/readme.md
index e69de29..6ce66a8 100644
--- a/readme.md
+++ b/readme.md
@@ -0,0 +1,3 @@
+# Auth Book
+
+This is a book on authentication.