Detailed Transaction Flows

this section is being constructed now (it is only for the very curious to read...)

This chapter explains the details of how electronic business transactions are being conducted using the eSSIF-Lab architectural components as described in chapter 2. We keep on using the parking permit example that we introduced in section 1.1. for illustrative purposes.

Note that both parties, requester and provider, each have components as described in chapter 2. Also note that whenever we introduce another party, it too has such components. Thus, every party can play any of the traditional SSI roles ‘verifier’, ‘holder’ and ‘issuer’, and each has its own ‘wallet’ functionality. Also, they all have TVE and TRD functionality that connect these aforementioned infrastructural components with the business applications.

When reading the next sections, please be aware that when a component of one of these parties communicates with another component, this other component may be of the same party, as well as of the other party. Figure 2 only shows components that belong to a single party.

6.1. Starting a Transaction

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.

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

  • are required only after a certain condition is met (which is to be evaluated whenever the data that is entered into the form is changed)
  • must or may initially be filled in manually (i.e.: through the browser);
  • must or may initially be filled in with data from a credential;
  • may be changed manually;
  • may be changed with data from a newly supplied credential.

Because of this orchestration, the interface to the verifier component can be quite simple; it is shown in the image below:

![Generic Verification with SSI service](https://essif-lab.pages.grnet.gr/essif-lab/images/Generic Verification with SSI service.png)

The request identifier is included in messages between the TVE and verifier so as to allow them to handle different transactions at the same time.

We assume that the provider has specified the form and the associated validation- and issuing policies that make the following description work. We refer the reader to section [tbd] for an explanation of how the provider can do this.

6.2. Stating a Transaction

[text still needs to be written]

![Generic Issuing with SSI service](https://essif-lab.pages.grnet.gr/essif-lab/images/Generic Issuing with SSI service.png)