Document Identity Discussion
Issue-ID: AAF-429
Change-Id: I9c217d0e19c65e9178f4c839d0426338a863e05c
Signed-off-by: Instrumental <jonathan.gathman@att.com>
diff --git a/docs/sections/architecture/aaf_architecture.rst b/docs/sections/architecture/aaf_architecture.rst
index 815a5a4..e806fb6 100644
--- a/docs/sections/architecture/aaf_architecture.rst
+++ b/docs/sections/architecture/aaf_architecture.rst
@@ -15,6 +15,55 @@
:height: 600px
:width: 800px
+Philosophy of Identity
+======================
+
+It may seem out of place to use the word "Philosophy" in a technical document, but given that philosophy is the study of knowledge, reality and existence, perhaps it is not so strange after all. When you combine this with the fact that the stereotypical "computer guy" also spends a lot of time reading/watching Science Fiction, then perhaps it is extraordinarily appropriate instead.
+
+In security, the two main tasks are to establish the validity to a claim of Identity (Authentication), and subsequently to relay what that Identity may do in certain contexts (Authorization).
+
+What is Identity?
+-----------------
+
+Fundamentally, Identity is the direct association of a name to some object, person or concept. The goal of naming is to make a consistent reference point to the same object, person or concept, and be able to share that via communications betwween a community. Thus, in a conversation, someone might bring up the name Charles de Gaulle in conversation, and the person and work of the French Minister of Armed Forces in France should come to mind. There is an anchor point in the minds of both persons while discussing this person. Even if one of the parties knows little about Charles de Gaulle, it becomes an anchor point to start gathering information, and can be returned to in future converstations.
+
+"Person and work" are polite ways of referring to people, who they are (or were), and what they do (or did). We will be more succint, and refer to Identity and Function, and apply this in the context of an Organization.
+
+Identity in Context
+-------------------
+
+A common experience for most people is "getting a job". Upon acceptance, the new person is added to company records, and assigned certain unique names so that the money you receive can be in direct association to the work you accomplish. The same is true for Schools, volunteer organizations. The existing Organization assigns this name, typically known as an "ID". It may or may not be created with any other names in it, but it associated with other names in records. Even when you are born, you are born into a family, and the parents choose the name, and record it within the country (Birth Certificate).
+
+Thus, the key element is that the Organization itself, delegated by the ultimate Authority of that Organiaztion, determines the name that you will use in Context. That name remains throughout the association with that Organization. Even if your ID is changed, that is usually recorded, so that records can be associated with past and present records.
+
+Computer Identity
+-----------------
+
+Whether or not you follow Science Fiction stories about Robots, are facinated by Isaac Azimov's Three Laws of Robotics, or think those who do are hopelessly socially inept, you will need to wrestle a bit with how much in common a human created machine with a human being. Without moral or religious implications, Identity can be discussed without stepping on the minefields that Science Fiction typically explores.
+
+An Application still must be named, and the name must be controlled within the Context of the Organization defining the name. Where the Application can affect Organzation Resources (i.e. Data), it must have the Authorization to do what it is doing, the question of being sentiently driven need not come up. (sorry sci-fi fans).
+
+Therefore, from an Organization Context, the very same Authentication and Authorization questions apply whether the Identity in question is "Carbon Based Life Form" or "Silicon Based Life Form".
+
+Sum of Parts
+------------
+
+For a human, it is pretty clear, of our purposes, that it is the mind that focuses into Identity. Any given Employee might lose an arm or leg during the period of employment, and, as long as they can type or vocalize a voice-print, there is no discernable difference
+n whether the person is still the person.
+
+Computer Applications may be different. Typically, an Application is built of separate parts, and with the advent of MicroServices as a goal, the question whether each part needs a separate identity or not is actually a valid question. When a Programmer is writing his App, and making the parts, do they need to stand on their own as an Identity or not.
+
+The trick is, as an Architect, is to determine whether these individual components really are separate, or can be considered as a part of the whole.
+
+As a rule of thumb, look at you App. If you follow a Model-View-Controller method, it is hard to argue for a need to separate identities... They are clearly three parts to the whole. On the other hand, if you want to consider each Component as a separate Robot, where one may NOT do just anything that the others do, then you should create separate Identities for each.
+
+A clue to this kind of model is if you consider having different groups creating an managing the apps, with a view towards more separateness. If you believe your components are more separate, and the grouping is more by topic (i.e. a group of robots tasked with collectively doing something), the separate Identities may be more appropriate.
+
+Enjoy stretching your mind
+--------------------------
+
+AAF can support models of either side. In the meantime, enjoy the use of your mind to comtemplate things beyond tickets and this will help drive what you need to ask for in terms of Identities for your Apps.
+
Certificate Manager
===================