Commit 51d99cf7 authored by Rieks Joosten's avatar Rieks Joosten

Fix point 2 of Panos' review comment

parent bc75785d
...@@ -14,9 +14,9 @@ The purpose of the functional architecture and its views is to ...@@ -14,9 +14,9 @@ The purpose of the functional architecture and its views is to
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. 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. 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. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an \`**SSI-Agent**\`, and we say that the Party on whose behalf it operates is the ‘**Owner**’ of that Agent. Also, we use the term \`**(digital/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 one 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. 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 its Agents. When we say ‘Party X does Y’, this should be understood as 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. 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.
...@@ -24,11 +24,15 @@ Also, to serve the aforementioned purposes, we cannot fix the architecture (and ...@@ -24,11 +24,15 @@ Also, to serve the aforementioned purposes, we cannot fix the architecture (and
## 2. Functional Architecture Overview ## 2. Functional Architecture Overview
Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, context and (functional) components each of which is an Agent for the same Party (meaning that they are all part of the same Organization as defined above, and they are all (digital) ‘Colleagues’ of one another). Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, context and *functional* components each of which is a (*functional*) Agent for the same Party (meaning that they are all part of the same Organization as defined above, and they are all (digital) ‘Colleagues’ of one another).
However, the participants of a business transaction are different Parties, which means that the negotiation, commitment and execution thereof is done by Agents of different Parties. Assuming that a single transaction has two participating Parties, we will use the term ‘**Peer Party (of a specific Party, in the context of a single transaction)**’ to refer to the participating Party in that transaction that is not the specific Party itself. Please be aware that *functional* capabilities, components, Agents, etc. do not necessarily coincide with *technical* capabilities, components, Agents, etc. The technical components can be deployed (downloaded, installed, run), whereas a functional component is a provider of a specified set of capabilities/functionalities an implementation of which can be made part of a technical component. So it is conceivable that a technical component contains an implementation of wallet, holder and verifier functional components as well as other functionalities that are not described here, e.g. related to UX, setting preferences, and more. In this functional architecture, the default type of components, Agents etc. are *functional*.
Every Agent that communicates with another Actor for the purpose of progressing a transaction with a Peer Party, will need to be sufficiently certain (to the extent necessary for the value of the transaction) that the Actor that it is communicating with, is in fact an Agent of the Peer Party (through the membership of the Agent's Owner). We will use the term ‘**Peer Agent (of a specific Agent, in the context of a single transaction)**’ to refer to an Actor with which the specific Agent has a communications session, and for which it has obtained sufficient assurance that it is an Agent of the Peer Party. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is. Since the participants of a business transaction are different Parties, the negotiation, commitment and execution of that transaction will be done by Agents of these different Parties. Assuming that a single transaction has two such Parties, we will use the term ‘**Peer Party (of a specific Party, in the context of a single transaction)**’ to refer to the participating Party in that transaction that is not the specific Party itself.
When an Agent is involved in such a transaction, it will be communicating with a component that it assumes to be an Agent of the Peer Party of its Owner (the Agent may obtain further assurances for that, but that's outside the scope for now). We will use the term ‘**Peer Agent (of a specific Agent, in the context of a single transaction)**’ to refer to an Actor with which the specific Agent has a communications session. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is.
The figure below is an overview of the most important *functional* components that any Party needs to conduct electronic business transactions.
![eSSIF-Lab Single Party Functional Architecture Overview](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture.png) ![eSSIF-Lab Single Party Functional Architecture Overview](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture.png)
...@@ -350,7 +354,7 @@ When reading the next sections, please be aware that when a component of one of ...@@ -350,7 +354,7 @@ When reading the next sections, please be aware that when a component of one of
The requester starts the transaction by pointing his web-browser to a web-page of the provider that (a) explains how to get a parking permit, and (b) provides a parking-permit application form that needs to be filled in. Technically, this means that the browser does a GET request to an endpoint that is serviced by the providers TVE component. The requester starts the transaction by pointing his web-browser to a web-page of the provider that (a) explains how to get a parking permit, and (b) provides a parking-permit application form that needs to be filled in. Technically, this means that the browser does a GET request to an endpoint that is serviced by the providers TVE component.
The TVE services this request by creating an empty form of a type appropriate for the request. Then, it continues with requesting data to fill in the form (and providing data as requested by the other Party). It starts this by providing a web page that includes the form to be filled in, as well as a deep-link, QR-code or something similar that allows the requester’s browser (plug-in) or SSI-app to contact the provider-endpoint and set up a secure communications channel through which both can communicate electronically. From then on there are two channels between the requester and the provider: one is a traditional (manual) web-browser - web-server channel, the other is one within which the SSI-Agent components of various Parties will be communicating. The TVE services this request by creating an empty form of a type appropriate for the request. Then, it continues with requesting data to fill in the form (and providing data as requested by the other Party). It starts this by providing a web page that includes the form to be filled in, as well as a deep-link, QR-code or something similar that allows the requester’s browser (plug-in) or SSI-app to contact the provider-endpoint and set up a secure communications channel through which both can communicate electronically. From then on there are two channels between the requester and the provider: one is a traditional (manual) web-browser - web-server channel, the other is one within which the SSI-Agents of various Parties will be communicating.
It is a task of the TVE to orchestrate the inputs: different parts of the form may be filled in and subsequently changed in different ways. Some parts It is a task of the TVE to orchestrate the inputs: different parts of the form may be filled in and subsequently changed in different ways. Some parts
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment