diff --git a/webgoat-lessons/idor/src/main/resources/lessonPlans/en/IDOR_mitigation.adoc b/webgoat-lessons/idor/src/main/resources/lessonPlans/en/IDOR_mitigation.adoc
index f92324e39..15e60830a 100644
--- a/webgoat-lessons/idor/src/main/resources/lessonPlans/en/IDOR_mitigation.adoc
+++ b/webgoat-lessons/idor/src/main/resources/lessonPlans/en/IDOR_mitigation.adoc
@@ -1,10 +1,58 @@
 == Secure Object References
 
+=== Start with the end in mind
+Do you have your access control documented? If you don't, how can you enforce it?  Access control is defined
+by the business logic that guides the application and/or privacy and other laws.
+
+==== Horizontal and Vertical Access Control
+Often times we think of access control in terms of 'roles' (user, power-user, admin, etc.).
+However, as noted in the previous exercises, users with the same 'role' can access each other's data. This is
+horizontal access control.  Both should be enforced.
+
+.Access Control Matrix Example
+|===
+|Endpoint | Method | Description | Roles, Access Rules | Notes, Caveats
+
+| /profile
+| GET
+| view user profile
+| Logged in User, can only view their own role
+| Admin roles must use diff Url to view others' profiles (see below)
+
+| /profile/{id}
+| GET
+| view user profile of a given user
+| Logged in User can view their own profile by {id}, admins can also view
+| n/a
+
+| /profile/{id}
+| PUT
+| edit user profile. profile object submitted from client with request
+| Logged in User can edit their own profile by {id}, admins can also edit.
+| Admin edit must be logged
+|===
+
+==== Audit Access
+As displayed in the above example, your access control rules should include provisions of what access is logged.
+For example, if a super-user or admin can edit other's profiles ... That is something that should be logged. Other
+examples would include detected violations or attempts to violate access control mechanisms.
+
 === Using Indrect References
-In some cases, using an indirect reference may help. This of course may make the application harder to trouble shoot and may also affect performance.
+Not many applications employ it, but you can use *indirect* refrences. In this case you can run your references across a hahsing,
+encoding or other function on the server so that the id that the client sees is not the actual reference
+which the server handles.  This will reduce efficiency some (a common trade-off for security) and is still subject to being
+guessed, brute-forced or reverse engineered.
 
-=== Access Controls
-Since the root of 'Insecure' of IDOR's s really in controlling access to the objects referenced, the key to making them secure is implementing vertical and horizontal access control.
+This approach should not be the only protection used. It can be used as an additional layer. Your server must
+implement the logic of mapping client (indirect) to server (direct) references.
 
-==== Knowing How Things Should be Secured
+=== APIs
+Many time, APIs or RESTFul endpoints rely on obscurity , a static 'key', or lack of imagination on the user's part to control access.
+Good options such as digitally signed JSON Web Tokens (https://jwt.io) are a good option for API authentication & access control using a
+combination of the claims and a digital/cryptographic signature to validate the consumer.  Other emerging standards such as
+Secure Token Binding promise a 'cryptographic state' for web services in the request headers ...
+https://tools.ietf.org/html/draft-ietf-tokbind-protocol-10
 
+https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-05
+
+https://tools.ietf.org/html/draft-ietf-tokbind-https-06