Merge branch 'patch-1' into 'master'

Add starting point for SSI standards

See merge request !10

SSI-standards.md

+<p align="center"><img src="images/EU-flag.jpg" height="80";" /> <img src="images/eSSIF-Lab logo.png" height="80";" /></p>
+
+eSSIF-Lab is funded by the European Commission, as part of the Horizon 2020 Research and Innovation Programme, under Grant Agreement Nº 871932 and it’s framed under[ ](http://ngi.eu/)[*Next Generation Internet Initiative*](http://ngi.eu/).
+
+
+
+# eSSIF-Lab Functional Architecture
+<p align="center">Author(s): Rieks Joosten (TNO)</p>
+
+
+
+The purpose of the functional architecture and its views is to
+
+-   **provide mental models** that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this;
+-   help **inventory and subsequently address any (other) concerns and issues** of every one of its stakeholders;
+-   help **achieve interoperability** both at the technical and at the business levels.
+
+
+
+## 1.  Basic Terminology
+
+In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘**party**’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘**actor**’ for that). This means that an organization is always a party, whereas we consider a person to be a party at one time and an actor at another time, and computers/robots (and SSI components) are always an actor.
+
+This distinction is necessary because actors do things that parties are accountable for. In order to know which party is accountable for what actions, we need the ability to link parties and actors. When an actor acts and a (single) specific party is accountable for that, we say that the actor is an ‘**agent**’ for or of that party (at that particular point in time). We say that this actor acts ‘**on behalf of**’ that party. When an SSI component acts as an agent for/on behalf of some party, we call it an \`**SSI-agent**\`, and we say that this party is the ‘**owner**’ of that component. Also, we use the term \`**(electronic or human) colleague (of an agent)**\` to refer to any other (electronic or human) agent that acts on behalf of the same party as this agent.
+
+Given these definitions, it is obvious that parties are not necessarily capable of acting. However, we also would like to be able to generically use phrases such as ‘party X does Y’. To this end we introduce the term \`**organization**\` as the collection of one specific party and every of its agents, and when we say ‘party X does Y’, we mean to say that there is an agent that does Y, where that agent belongs to the same organization as the specified party..
+
+We caution that the notions of being an ‘agent’, ‘owner’, ‘colleague’, and being part of an ‘organization’ are dynamic; they may frequently change over time and are never self-evident.
+
+Also, to serve the aforementioned purposes, we cannot fix the architecture (and the fact that eSSIF-Lab is an experimentation environment already implies this). We see it is a first attempt to describe an architecture that will be regularly updated as we - i.e. the eSSIF-Lab consortium and all subgrantees and perhaps some others - work together as an ecosystem-in-formation to realize the aforementioned vision.
+
+## 2.  Functional Architecture Overview
\ No newline at end of file