Commit f98dbbee authored by Rieks Joosten's avatar Rieks Joosten

minor updates

parent baecca75
Pipeline #17206 passed with stage
in 2 minutes and 19 seconds
......@@ -161,7 +161,7 @@ and it needs to consist of the following structure:
---
id: term
title: Term page
hoverText: This hover text will appear in the documentation page that you reference this term
hoverText: "This hover text will appear in the documentation page that you reference this term."
---
### Term explanation
......
......@@ -26,11 +26,11 @@ Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, c
Please be aware that *functional* capabilities, components, %%agents|agent%%, etc. do not necessarily coincide with *technical* capabilities, components, %%agents|agent%%, 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 %%issuer|issuer%%, %%wallet|wallet%%, %%holder|holder%% and %%verifier|verifier%% functional components as well as other functionalities that are not described here, e.g. related to UX, setting %%preferences|policy%%, and more. In this functional architecture, the default type of components, %%agents|agent%% etc. are *functional*.
Since the %%participants|participant%% of a %%business transaction|transaction%% are different %%parties|party%%, the negotiation, commitment and execution of that %%transaction|transaction%% will be done by %%agents|agent%% of these %%parties|party%%. Assuming that a single %%transaction|transaction%% has two such %%parties|party%%, we will use the term '%%Peer Party|peer-party%% (of a specific %%party|party%%, in the context of a single %transaction)' to refer to the participating %%party|party%% in that %%transaction|transaction%% that is not the specific %%party|party%% itself.
Since the %%participants|participant%% of a %%(business) transaction|transaction%% are different %%parties|party%%, the negotiation, commitment and execution of that %%transaction|transaction%% will be done by %%agents|agent%% of these %%parties|party%%. Assuming that a single %%transaction|transaction%% has two such %%parties|party%%, we will use the term '%%Peer Party|peer-party%% (of a specific %%party|party%%, in the context of a single %transaction)' to refer to the participating %%party|party%% in that %%transaction|transaction%% that is not the specific %%party|party%% itself.
When an %%agent|agent%% is involved in such a %%transaction|transaction%%, it will be communicating with a component that it assumes to be an %%agent|agent%% of the %%peer party|peer-party%% of its %%principal|principal%% (the %%agent|agent%% may obtain further assurances for that, but that's outside the scope for now). We will use the term '%%peer agent|peer-agent%% (of a specific %%agent|agent%%, in the context of a single %%transaction|transaction%%)' to refer to an %%actor|actor%% with which the specific %%agent|agent%% has a communication session. Note that establishing whether or not an %%actor|actor%% is a %%Peer Agent|peer-agent%% does not necessarily require knowing who the %%peer party|peer-party%% actually is.
The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%business transactions|transaction%%.
The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%(business) transactions|transaction%%.
<img
alt="eSSIF-Lab Single Party Functional Architecture Overview"
......@@ -47,7 +47,7 @@ The remainder of this chapter describes the layers and their components at a hig
At the top of the figure are two business-related layers. Both are within the scope of the eSSIF-Lab project/architecture, yet they are outside the scope of the eSSIF-Lab infrastructure/architecture - that is because they are too business-specific.
The top layer (in the red rounded rectangle) has the functions of actual %%business transactions|transaction%%: it starts with a %%transaction form|transaction-form%%, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a %%business transaction|transaction%%, and that has everything necessary to actually execute that %%business transaction|transaction%%. The (administrative) results of such a %%business transaction|transaction%% are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct %%business transactions|transaction%%.
The top layer (in the red rounded rectangle) has the functions of actual %%transactions|transaction%%: it starts with a %%transaction form|transaction-form%%, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a %%transaction|transaction%%, and that has everything necessary to actually execute that %%transaction|transaction%%. The (administrative) results of such a %%transaction|transaction%% are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct %%transactions|transaction%%.
The lower business layer contains two functional components, one for initiating %%transactions|transaction%% and the other for stating %%transaction|transaction%% results (as per the [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) method), each of which with an associated business %%policy|policy%% that contains business-specific %%policies|policy%%.
......
......@@ -63,7 +63,7 @@ and it needs to consist of the following structure:
id: term
title: Term page
stage: draft
hoverText: This hover text will appear in the documentation page that you reference this term
hoverText: "This hover text will appear in the documentation page that you reference this term."
---
### Term explanation
......
---
id: business-transaction
title: "Business Transaction"
scopeid: essifLab
type: concept
typeid: business-transaction
stage: draft
hoverText: "Business Transaction: a Transaction that constitutes business of its participating Parties."
glossaryText: "See: %%transaction^transaction%%)."
---
See: %%transaction^transaction%%
......@@ -5,8 +5,8 @@ scopeid: essifLab
type: concept
typeid: digital-communication-channel
stage: draft
hoverText: "Digital Communication Channel: a digital means by which two Digital Actors can exchange messages with one another"
glossaryText: "a digital means by which two %%digital actors^digital-actor%% can exchange messages with one another"
hoverText: "Digital Communication Channel: a digital means by which two Digital Actors can exchange messages with one another."
glossaryText: "a digital means by which two %%digital actors^digital-actor%% can exchange messages with one another."
---
:::info Editor's note
......
......@@ -5,8 +5,8 @@ scopeid: essifLab
type: concept
typeid: transaction-proposal
stage: draft
hoverText: "Transaction (Agreement) Proposal: a Transaction Agreement that is 'in-the-making' (ranging from an empty document to a document that would be a Transaction Agreement if it were signed by all Participants)"
glossaryText: "a %%transaction agreement^transaction-agreement%% that is 'in-the-making' (ranging from an empty document to a document that would be a %%transaction agreement^transaction-agreement%% if it were signed by all %%participants^participant%%)"
hoverText: "Transaction (Agreement) Proposal: a Transaction Agreement that is 'in-the-making' (ranging from an empty document to a document that would be a Transaction Agreement if it were signed by all Participants)."
glossaryText: "a %%transaction agreement^transaction-agreement%% that is 'in-the-making' (ranging from an empty document to a document that would be a %%transaction agreement^transaction-agreement%% if it were signed by all %%participants^participant%%)."
---
:::info Editor's note
......
---
id: transaction
title: "(Business) Transaction"
title: "Transaction"
scopeid: essifLab
type: concept
typeid: transaction
stage: draft
hoverText: "(Business) Transaction: the exchange of goods, services, funds, or data between some Parties (called Participants of the Transaction)."
hoverText: "Transaction: the exchange of goods, services, funds, or data between some Parties (called Participants of the Transaction)."
glossaryText: "the exchange of goods, services, funds, or data between some %%parties^party%% (called %%participants^participant%% of the %%transaction^transaction%%)."
---
import useBaseUrl from '@docusaurus/useBaseUrl'
### Short Description
A **business transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These %%parties|party%% are called the %%participants of the transaction|participant%%. A typical %%business transaction|transaction%% consists of three phases. In the first phase, a %%transaction agreement|transaction-agreement%% is negotiated between the participants. That phase ends when either participant quits the negotiation, or all participants commit to the transaction, which basically is a promise to the other participants that it will keep up its end of the %%transaction agreement|transaction-agreement%%. In the second phase, the participants work to fulfill their promise. That phase ends when they deliver the results, and inform their peers of that they're done. In the final phase, participants check whether or not they have received what was promised, and that it conforms the criteria in the transaction agreement. This may lead to some discussion and possible rectifications. The final phase ends either when one of the participants escalates (e.g. goes to court), or all results are accepted. This way of looking at %%business transactions|transaction%% has been described extensively in the [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) transaction model.
A **transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These %%parties|party%% are called the %%participants of the transaction|participant%%. A typical %%business transaction|transaction%% consists of three phases. In the first phase, a %%transaction agreement|transaction-agreement%% is negotiated between the participants. That phase ends when either participant quits the negotiation, or all participants commit to the transaction, which basically is a promise to the other participants that it will keep up its end of the %%transaction agreement|transaction-agreement%%. In the second phase, the participants work to fulfill their promise. That phase ends when they deliver the results, and inform their peers of that they're done. In the final phase, participants check whether or not they have received what was promised, and that it conforms the criteria in the transaction agreement. This may lead to some discussion and possible rectifications. The final phase ends either when one of the participants escalates (e.g. goes to court), or all results are accepted. This way of looking at %%business transactions|transaction%% has been described extensively in the [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) transaction model.
:::info Editor's note
TNO (or others) to provide further content/revisions.
......
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