Commit 80d25c3d authored by Rieks Joosten's avatar Rieks Joosten

fixing errors in %%-notation

parent d0761c80
Pipeline #16378 passed with stage
in 2 minutes and 50 seconds
......@@ -73,7 +73,7 @@ This layer requires %%governance|governance%%.
The lower business layer contains two functional components, one for initiating transactions and the other for stating 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 that contains business-specific policies/preferences.
The task of the %%Transaction Data Collector|transaction-data-collector%% (or %%Transaction Data Collectortransaction-data-collector%%) is to handle and initiate requests from/to Peer Agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a Peer Agent to provide data that its Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the Transaction Data Collector must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
The task of the %%Transaction Data Collector|transaction-data-collector%% (or %%Transaction Data Collector|transaction-data-collector%%) is to handle and initiate requests from/to Peer Agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a Peer Agent to provide data that its Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the Transaction Data Collector must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
The task of the %%Transaction Data Discloser|transaction-data-discloser%% (or %%Transaction Data Discloser|transaction-data-discloser%%) is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
......
......@@ -9,7 +9,7 @@ hoverText: "Business Transaction: the exchange of goods, services, funds, or dat
---
### Short Description
A **business transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These parties are called the %%participants of the transaction|participant%%. A typical business 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%%. 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 has been described extensively in the [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) transaction model.
A **business transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These parties are called the %%participants of the transaction|participant%%. A typical business 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 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.
......
......@@ -9,12 +9,12 @@ hoverText: "eSSIF-Glue: interface layer that allows components with Transaction
---
### Short Description
The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%Transaction Data Collectortransaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand.
The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%Transaction Data Collector|transaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand.
Ultimately, we would like to see these APIs standardized. Having such APIs allows different Parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit.
### Purpose
The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%Transaction Data Collectortransaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%%
The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%Transaction Data Collector|transaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%%
### Criterion
The set of API's described at https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs.
......@@ -18,7 +18,7 @@ Within eSSIF-Lab, governance is pretty much limited to the governance of various
### Purpose
The purpose for a %%party|party%% of having a **governance** process is that it enables him to reflect on the ways that it makes decisions. A typical topic for governance is the maintenance of the set of rules, working-instructions, preferences and other guidance that %%actors|actor%% are supposed, or required to use when executing specific %%actions|action%% on behalf of that %%party|party%%.
For %%digital-actors%% such guidance consists of %%digital policies|digital-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
For %%digital-actors|digital-actor%% such guidance consists of %%digital policies|digital-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
......
......@@ -36,7 +36,7 @@ A **Transaction Data Collector** is a functional component in the [eSSIF-Lab fun
- can use any appropriate communication channel with a %%peer agent|peer-agent%% to:
- request for data that, according to the %%Transaction Data Collector Policy|transaction-data-collector-policy%% is needed to decide whether or not to commit to the transaction;
- process the responses to such requests, in an orchestrated way, thereby complying with the rules of its %%principal's|principal%% %%Transaction Data Collector Policy|transaction-data-collector-policy%%, the result of which (in the end) is a set of %%validated data|validated-data%% that can serve the purpose of deciding whether or not to commit to the transaction;
- receive similar requests from its %%peer-party%%, and respond to such requests in compliance with the rules of its %%principal's|principal%% %%Transaction Data Collector Policy|transaction-data-collector-policy%%;
- receive similar requests from its %%peer party|peer-party%%, and respond to such requests in compliance with the rules of its %%principal's|principal%% %%Transaction Data Collector Policy|transaction-data-collector-policy%%;
- has a mechanism to ensure that within a %%transaction|business-transaction%%, it uses the latest (most receent) %%Transaction Data Collector Policy|transaction-data-collector-policy%% of its %%principal|principal%%.
### Deprecated - TVE Functionality
......@@ -88,7 +88,7 @@ As long as data is needed, the Transaction Data Collector can intermittently req
TNO to revise the footnote markers
:::
[^1x]: In the same way that the Transaction Data Collector needs to collect data in order to be able to decide whether or not to commit, %%agents|agent%% of the %%peer party|peer-party%% need to collect data for making a similar %%commitment decision|commitment-decision%%. Requests for such data are to be processed by the %%Transaction Data Discloser component|transaction-data-discloser%% under guidance of its %%transaction-data-discloser-policy%%.
[^1x]: In the same way that the Transaction Data Collector needs to collect data in order to be able to decide whether or not to commit, %%agents|agent%% of the %%peer party|peer-party%% need to collect data for making a similar %%commitment decision|commitment-decision%%. Requests for such data are to be processed by the %%Transaction Data Discloser component|transaction-data-discloser%% under guidance of its %%Transaction Data Discloser Policy|transaction-data-discloser-policy%%.
[^1a]: If the %%Transaction Data Collector policy|transaction-data-collector-policy%% specifies that data is to be collected for other purposes, the %%Transaction Data Collector|transaction-data-collector%% should then be provided a means to inform its %%peer party|peer-party%% of such purposes, and the policy should not specify that such data is required to make the commitment decision.
......
......@@ -14,7 +14,7 @@ A **Verifier** is is an (architectural) function (a functional component in the
It does so by:
- creating %%Presentation Requests|presentation-request%% (or Presentation Definition as it is called in the [draft DIF specfication for Presentation Exchange](https://identity.foundation/presentation-exchange)) that ask for such credentials,
- sending them to an %%agent|agent%% of that other %%party|party%% that provides %%holder|holder%% functionality,
- receiving a response from that %%agent|agent%% to the %%presentation-request%% (i.e. a '%%Presentation|presentation%%'),
- receiving a response from that %%agent|agent%% to the %%presentation request|presentation-request%% (i.e. a '%%Presentation|presentation%%'),
- verifying that %%presentation|presentation%%, i.e. checking the signature and other proofs of the veracity of both the construction of the presentation and its contents
- returning the data that the %%Transaction Data Collector|transaction-data-collector%% requested, optionally with a report about which verification checks succeeded and/or which failed.
......
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