set up process oriented answers file

.idea/codeStyles/codeStyleConfig.xml

@@ -0,0 +1,5 @@
+<component name="ProjectCodeStyleConfiguration">
+  <state>
+    <option name="PREFERRED_PROJECT_CODE_STYLE" value="Default" />
+  </state>
+</component>

Big Ideas/1-preface.md

@@ -0,0 +1,12 @@
+# Preface
+
+*"A scout is Trustworthy"*
+
+-The first attribute of The Scout Law (Boy Scouts of America)
+
+In my college town, there was an auto shop called Honest-1 Auto Repair, I never once took my car to that auto shop. I didn't trust them. I have no idea if the shop was any good. but the whole idea of putting "Honest" in your name in order to make me trust you, immediately made me not trust them. In our society, we depend on trust. We trust our family members. We trust our friends. We trust that money will buy things. Human Society has always relied on trust. How do people earn our trust? How do we learn to trust others? How can we help them trust us? And most importantly, for the sake of this book, how do we trust others in an interconnected world when we communicate digitally? The answer is Authentication. Authentication is the act of providing proof something is true. Types of authentication we rely on today range from the keys to your house, to cryptographic keys to unlock a bank account, to the nuclear launch codes. Believe it or not, even our dogs authenticate us with location, sound and smell.
+
+
+
+My purpose in writing this book is to help system engineers and software engineers understand how to properly use authentication and authorization tools. I want to help them learn when to use different forms of authentication and when they are not required. My hope is that you take this book, highlight what stands out to you, write your own notes in the margin and use the worksheets provided to help you design the perfect authentication and authorization system for your projects and businesses.
+

Big Ideas/2-Authentication.md

@@ -0,0 +1,28 @@
+# Authentication
+
+## Identify who/what you need to authenticate
+
+
+
+## Identify who/what you need to authenticate to
+
+## Level of Confidence in your Authentication
+
+## How long should you trust an Authentication?
+
+## Authentication Design Worksheet
+
+1.  Identify the users and systems you need to authenticate
+
+------------------------
+
+2. Identify the users and systems you need to authenticate to answer number 1
+
+------------------------
+
+3. Decide the levels of confidence you need to establish between the two answers above
+
+------------------------
+
+4. How long can I trust someone after they've authenticated?
+------------------------

Big Ideas/Topics.md

@@ -1,13 +1,15 @@
 # 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)
+1. [Preface - "A scout is Trustworthy"](./1-preface.md)
+1. [Authentication](./2-Authentication.md)
+1. [Authorization](./Authorization.md)
+1. [Audit/Accountability](./audit.md)
+1. [OAuth](./OAuth.md)
+1. [OpenID](./OpenID.md)
+1. [SAML](./SAML.md)
+1. [JWT](./JWT.md)
+1. [SAML vs OAuth vs OpenID](./SAML%20vs%20OAuth%20vs%20OpenID.md)
+1. [OAuth vs OpenID](./OAuth%20vs%20OpenID.md)
 
 
 ## Questions I need to answer before attempting to write this book
@@ -120,3 +122,15 @@ The following list was derived from https://identitymanagementinstitute.org/laye
   * bcrypt, pbkdf2 and other hashing and storing suggestions
   * Securing your database
 
+### Authentication for 1st and 3rd Parties
+
+#### OAuth2
+
+#### OpenID Connect
+
+#### SAML 2.0
+
+#### CAS?
+
+### Single Sign-on
+

Outline/Foundational answers.md

@@ -0,0 +1,52 @@
+## Foundational Answers
+
+1. Core Principles: What are the core principles you believe every software company should follow when implementing authentication and authorization?
+   * More powerful authentication signals to business customers you are designed for them
+   * Companies should have ongoing education around security.
+   * Following best practices for security - don't do anything funky, you might get it wrong
+   * The sneakiest part of good security is Good User Experience
+   * Least privilege by default plus easy requesting and granting
+2. Common Pitfalls: What are the most common mistakes or oversights you’ve seen companies make in this area?
+   * ParentLink:
+     * Ease of implementation was prioritized over user experience
+     * Users were not the paying customer, so their needs were de-prioritized, ultimately weakening the stickiness of their product.
+   * Domo:
+     * Custom implementations of standards (even when using a library) can make adding new integrations, service providers, or identity providers a repetitive, slow, laborious and tedious task.
+     * Even the most technical enterprises needed hands on help to get SAML integrated correctly.
+     * Underinvesting in development can prevent a polished outcome.
+     * Need to keep up-to-date on security landscape changes. e.g. third party cookie rule changes, browser and mobile app behavior differences.
+   * Storm:
+     * Sometimes you don't need the added complexity of OAuth or other standards
+   * Weave:
+     * Third party auth providers will squeeze you once they know they have you.
+     * Using a third party still requires you to have knowledge about all things authentication.
+     * Third parties, especially the large and well known ones, are usually larger and more attractive targets for hackers. You end up being a by-stander to your own security.
+     * Companies need the ability to end a user's session remotely and revoke their authentication.
+     * Audit logs are your friend. They are different from application logs, they log individual actions taken by users rather than generic events.
+3. Security First: How do you prioritize security without compromising user experience? Do you have a guiding philosophy or process for balancing these two?
+   * The trick to good security without losing user experience is that good user experience can actually encourage good security. Like an open park verses a dark alley.
+   * Passkeys are more secure and easier to use for a user. They are a bit more involved to implement.
+   * IDPs are the same way, though it can open you up to the security issues of that provider.
+4. Industry Standards: Which industry standards (e.g., OAuth, SAML, JWT) do you consider essential? How do you decide which ones to use or recommend to clients?
+   * If integrating with any third party systems, be it for user federation, identification, authentication or any other reason, you should use an open industry standard specification.
+     * OIDC > SAML (but...):
+       * OIDC
+         * is newer and uses REST
+         * uses OAuth
+         * has a fixed definition of standard fields for a user's profile
+         * it has highly supported automated exchange of setup info between systems
+         * can support custom fields when needed
+       * SAML
+         * Older and uses SOAP (less well known)
+         * Dark corner cases crop up because of its long legacy
+         * Enterprises LOVE it.
+         * Many software products implement SAML before they implement OIDC
+         * Customers using an IDP for their users will likely have other SAML integrations and so will be familiar with it.
+         * custom fields abound but can cause configuration issues
+     * FHIR
+       * Essential for authenticating to healthcare data systems within the United States
+     * User profiles
+       * You should use the OpenID Connect standard claims for all fields of your profiles, you can extend the 'claims' by adding your own, but a large body of engineers have already identified the most common fields for user profiles. No need to re-invent the wheel here.
+     * Password storage - Technologies change over time by as of the time of this writing bcrypt is my preferred password storage, but some regulatory bodies still require PBKDF2.
+       * Bcrypt - stores a salt, hash, the iteration count and all things needed in a standard format that can fit in a text field in a database. It does not require special implementations that can go wrong. In Golang it is as simple as it can get with just a single call to create a hash and a single call to validate a hash.
+       * PBKDF2 - is a fantastic and secure way to store your passwords. But I've experienced a few non-standard formats for storage which made it hard to make interops between new and old systems. Regulatory bodies have been known to require this type of password storage in order to work with their systems. Usually, they have more standardized specifications for you to implement when working with them.

Outline/Process-Oriented Answers.md

@@ -0,0 +1,4 @@
+## Process-Oriented Answers
+
+1. Assessment: When you first engage with a client, how do you assess their current authentication and authorization setup? What key factors do you evaluate?
+   * 

Outline/Questions for building a methodology.md

@@ -0,0 +1,26 @@
+That sounds like a great focus area! Let’s start by exploring the foundational aspects of your methodology:
+
+### Foundational Questions
+1. **Core Principles**: What are the core principles you believe every software company should follow when implementing authentication and authorization?
+2. **Common Pitfalls**: What are the most common mistakes or oversights you’ve seen companies make in this area?
+3. **Security First**: How do you prioritize security without compromising user experience? Do you have a guiding philosophy or process for balancing these two?
+4. **Industry Standards**: Which industry standards (e.g., OAuth, SAML, JWT) do you consider essential? How do you decide which ones to use or recommend to clients?
+
+### Process-Oriented Questions
+1. **Assessment**: When you first engage with a client, how do you assess their current authentication and authorization setup? What key factors do you evaluate?
+2. **Implementation Steps**: What are the high-level steps you follow to implement a secure and scalable authentication system? Can these be broken down into phases or stages?
+3. **Customization**: How do you tailor your approach to different types of companies, whether they are startups, mid-sized companies, or large enterprises?
+4. **Tools and Technologies**: What specific tools, libraries, or technologies do you prefer for different stages of the process (e.g., identity management, access control, monitoring)?
+
+### Methodology Differentiators
+1. **Unique Approach**: What sets your methodology apart from others in the industry? Do you have a specific framework, technique, or tool that you’ve developed or refined?
+2. **Client Collaboration**: How do you work with clients throughout the process? What strategies do you use to ensure that your solutions align with their business goals and technical needs?
+3. **Adaptability**: How does your methodology adapt to the ever-changing landscape of security threats and compliance requirements?
+4. **Education and Empowerment**: How do you educate and empower your clients to maintain and evolve their authentication and authorization systems after your engagement ends?
+
+### Results and Outcomes
+1. **Success Metrics**: How do you measure the success of your authentication and authorization implementations? What metrics or KPIs do you track?
+2. **Case Studies**: Do you have any success stories or case studies that illustrate the impact of your methodology? What were the key challenges, solutions, and outcomes?
+3. **Long-Term Maintenance**: What do you recommend for ongoing maintenance and security updates? How do you ensure that your clients stay protected over time?
+
+These questions should help you start to form a comprehensive methodology that you can later refine and expand into your book and consulting work.

Outline/Suggested outline - Daniel Priestly.md

@@ -0,0 +1,44 @@
+1. Who is the book for?
+   * List of all the things that frustrate them
+   * List of all the questions they have asked
+   * List of their hopes, drams, wishes outcomes, desires
+   * List of all the things that have frustrated them in the past
+
+# Key sections:
+
+## Intro
+in the opening of the book, sell the reader that they should finish the book.
+* What are they going to get from the book?
+* What problems is it going to solve?
+* What questions is it going to answer?
+* What methodology is it going to reveal?
+* Bonuses for the end of the book (maybe)?
+
+## Distruption
+* 3-4 chapters that disrupt people about how they are approaching their problem wrong.
+* e.g. Your best thinking for 5 years ago is your baggage today.
+* e.g. your entrepenural journey is predictable and there are certain steps you can take along the way.
+
+## Insights
+* 5 or 6 key High level ideas, sharing the new ways of thinking
+* High level ideas, new frameworks, new ways of thinking of things.
+* At the end of the insights section add a call to action such as a scorecard. Help them benchmark how far along the path they are.
+  * The CTA also helps you turn them into a warm lead.
+
+## Methodology
+* This should be completely unique to you. How to achieve the result.
+* Share enough that they can go directionally correct and see that you know what you are talking about.
+* They can feel comfortable that they can reach out to you to get further details, or use your company to get solutions
+
+## Objection Handling
+* Address all the reasons people would not adopt your methodology.
+* People want it to be easier, but they'll have to do something for the result.
+* You want to handle the objections that might come up.
+* Second CTA, give them exactly what you want them to do in order to get started on the methodology.
+
+## Leave people on an inspirational high
+Talk about the big picture of getting this done.
+* What is the real reason that you want people to act?
+* What is on the other side of the pain?
+* What is on the otherside of commitment and discipline?
+