diff --git a/docs/functional-architecture.md b/docs/functional-architecture.md index 35ca742257613f03f1bd48759f56634f26334e15..27b116dc0999460506c3acedddf5c1d846b33ebf 100644 --- a/docs/functional-architecture.md +++ b/docs/functional-architecture.md @@ -9,28 +9,28 @@ import useBaseUrl from '@docusaurus/useBaseUrl' ## 1. Purpose -It is the intention of the eSSIF-Lab project to develop this functional architecture into a generic, and common basis that parties from different backgrounds can use e.g. for: -- thinking and arguing about SSI-related topics and how it contributes to business transactions; -- creating technological components that provide functionalities that fit into the architecture and hence have a great chance to be, or quickly become, interoperable with tech components that other parties have developed; +It is the intention of the eSSIF-Lab project to develop this functional architecture into a generic, and common basis that %%parties|party%% from different backgrounds can use e.g. for: +- thinking and arguing about SSI-related topics and how it contributes to %%business transactions|business-transaction%%; +- creating technological components that provide functionalities that fit into the architecture and hence have a great chance to be, or quickly become, interoperable with tech components that other %%parties|party%% have developed; - discussing and resolving issues related to interfaces and protocols for tech components that provide such functionalities; -- designing and developing technical applications that support businesses, not only as they conduct business transactions, but also as the govern the policies that are needed to make the technology work as intended by such businesses. +- designing and developing technical applications that support businesses, not only as they conduct %%business transactions|business-transaction%%, but also as the govern the %%policies|policy%% that are needed to make the technology work as intended by such businesses. To this end, this document provides an overview of -- the functions (capabilities) that individual parties need in order to electronically support busines transactions; -- the interactions between these functions that make such business transactions happen; -- the various policies that parties have to govern, and put in place in order for the technical components that provide these capabilities to function in accordance with their (subjective) rules, working-instructions and other guidance. +- the functions (capabilities) that individual %%parties|party%% need in order to electronically support %%business transactions|business-transaction%%; +- the interactions between these functions that make such %%business transactions|business-transaction%% happen; +- the various %%policies|policy%% that %%parties|party%% have to govern, and put in place in order for the technical components that provide these capabilities to function in accordance with their (subjective) rules, working-instructions and other guidance. ## 2. Functional Architecture Overview -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). +Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, context and *functional* components each of which is a (*functional*) %%agent|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). -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 issuer, 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*. +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 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. +Since the %%participants|participant%% of a %%business transaction|business-transaction%% are different %%parties|party%%, the negotiation, commitment and execution of that %%transaction|business-transaction%% will be done by %%agents|agent%% of these %%parties|party%%. Assuming that a single %%transaction|business-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|business-transaction%% that is not the specific %%party|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 principal (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 communication session. Note that establishing whether or not an actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is. +When an %%agent|agent%% is involved in such a %%transaction|business-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|business-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 needs to conduct electronic business transactions. +The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%business transactions|business-transaction%%. eSSIF-Lab Single Party Functional Architecture Overview @@ -47,13 +47,13 @@ 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: it starts with a 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, and that has everything necessary to actually execute that business transaction. The (administrative) results of such a business 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. +The top layer (in the red rounded rectangle) has the functions of actual %%business transactions|business-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|business-transaction%%, and that has everything necessary to actually execute that %%business transaction|business-transaction%%. The (administrative) results of such a %%business transaction|business-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|business-transaction%%. -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 lower business layer contains two functional components, one for initiating %%transactions|business-transaction%% and the other for stating %%transaction|business-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%%. -The task of the Data Collector (or 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 principal needs, and providing data on behalf of its principal 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 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 Data Collector (or Data Collector) is to handle and initiate requests from/to %%peer agents|peer-agent%% to engage in some kind of %%transaction|business-transaction%%, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a %%transaction|business-transaction%% form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the %%transaction|business-transaction%%. Note that negotiating a %%transaction|business-transaction%% has two parts: requesting a %%peer agent|peer-agent%% to provide data that its %%principal|principal%% needs, and providing data on behalf of its %%principal|principal%% that a %%peer agent|peer-agent%% requests. After all, a %%business transaction|business-transaction%% can only start after all %%parties|party%% 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 data collector must ensure that the %%transaction|business-transaction%% context is properly maintained if it chooses to exchange data through different communication channels. -The task of the data discloser (or 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. +The task of the data discloser (or data discloser) is to state the (various, sometimes intermediary) results of %%transactions|business-transaction%%, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%parties|party%%. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state. Note that both components are within scope of eSSIF-Lab architecture, but NOT in scope of the eSSIF-Lab infrastructure, as they are too business-specific. @@ -63,19 +63,19 @@ The SSI Roles Layer contains functional components that provide the functionalit Apart from each having a specific task, as described below, implementations that are being deployed by one party should be aligned in that they support the same (sub)set(s) of SSI Protocols and Crypto features, as described in the following section. -The **issuer** functionality includes the issuing of what we will generically call 'credentials', i.e. sets of (related) statements/claims (e.g. as produced by the data discloser) that have metadata (e.g. date of issuing) and a digital signature by which third parties can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. +The **issuer** functionality includes the issuing of what we will generically call 'credentials', i.e. sets of (related) statements/claims (e.g. as produced by the data discloser) that have metadata (e.g. date of issuing) and a digital signature by which third %%parties|party%% can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. -The **wallet** functionality includes the (secure) storage of credentials - both those that have been issued by the issuer (i.e. self-signed credentials) and those that have been obtained from issuers of other parties. Another task of the wallet is to (securely) store (private) keys that can be used to sign or seal data on behalf of its principal. Perhaps the most important task of the wallet is to ensure that credentials and keys can only become available to another component if they have the same (single) principal, and will become available if such other component implements a functionality that needs it. +The **wallet** functionality includes the (secure) storage of credentials - both those that have been issued by the issuer (i.e. self-signed credentials) and those that have been obtained from issuers of other %%parties|party%%. Another task of the wallet is to (securely) store (private) keys that can be used to sign or seal data on behalf of its %%principal|principal%%. Perhaps the most important task of the wallet is to ensure that credentials and keys can only become available to another component if they have the same (single) %%principal|principal%%, and will become available if such other component implements a functionality that needs it. -The **verifier** functionality is to support the data collector as it tries to acquire credentials from some other party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests (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 a holder component of another party, receiving a response to such a request (which we call a 'Presentation'), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the Data Collector with verified data. +The **verifier** functionality is to support the data collector as it tries to acquire credentials from some other party for the purpose of negotiating a %%business transaction|business-transaction%%. 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 a holder component of another party, receiving a response to such a request (which we call a '%%presentation|presentation%%'), verifying the %%presentation|presentation%%, i.e. checking the signature and other proofs of the veracity of both the construction of the %%presentation|presentation%% as well as its contents, thus providing the Data Collector with verified data. -The task of the **holder** is to handle presentation requests that it receives from verifier components (both of its principal, and of other parties). Typically, this means looking for the requested data in the principal's wallet, and using it to construct a Presentation (=response). However, if the wallet doesn't have it, the holder may negotiate a transaction with a component of the designated issuer for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the presentation. +The task of the **holder** is to handle %%presentation requests|presentation-request%% that it receives from verifier components (both of its %%principal|principal%%, and of other %%parties|party%%). Typically, this means looking for the requested data in the %%principal's|principal%% wallet, and using it to construct a %%presentation|presentation%% (=response). However, if the wallet doesn't have it, the holder may negotiate a %%transaction|business-transaction%% with a component of the designated issuer for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the %%presentation|presentation%%. ### 2.3. SSI Protocols and Crypto Layer While represented as a layer, the SSI Protocols and Crypto Layer can be seen more as a set of libraries that can be used by wallet, holder, issuer and %%verifier|verifier%% (WHIV) components for the purpose of actually implementing some/all of the functionality that they need to provide. Each 'Component' in this layer implements a specific technology, and any implementation of any of the WHIV components may choose which of these to use. Of course, if one of the WHIV components implements a technology, it would seem that the others would need to do so, too. -Technologies may come as a (proprietary or open source) library, as a service (offered by one or more Parties), or both. There are way too many to mention here, but to give you an idea, here is a classification of such underlying/supporting technologies that seems to be useful. While we do mention some technologies explicitly, this should in no way be interpreted as that this would be necessary to support, or that others are not to be considered. +Technologies may come as a (proprietary or open source) library, as a service (offered by one or more %%parties|party%%), or both. There are way too many to mention here, but to give you an idea, here is a classification of such underlying/supporting technologies that seems to be useful. While we do mention some technologies explicitly, this should in no way be interpreted as that this would be necessary to support, or that others are not to be considered. First, we have **credential-related technologies**, most often in the form of libraries, basically for the creation, (storing,) and verification of specific kinds of %%credentials|credential%% such as [*Verifiable Credentials*](https://www.w3.org/TR/vc-data-model/) (VCs), [*Attribute Based Credentials*](https://abc4trust.eu/index.php/pub)[ABC] (ABCs), [*X.509 Attribute Certificates*](https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.509-201210-S!!PDF-E), [*OIDC*](https://openid.net/developers/specs/) tokens, etc. Various projects/implementations can already be used here, such as [*Hyperledger Aries*](https://www.hyperledger.org/projects/aries), [*IRMA*](https://privacybydesign.foundation/irma-en/), [*OpenCerts*](https://opencerts.io/), [*BlockCerts*](https://www.blockcerts.org/), and more. @@ -91,7 +91,7 @@ It is expected that there are already some interfaces out there that may turn ou [ABC] Its origins lie with the [*ABC4Trust project*](https://abc4trust.eu/). Extensive [*documentation*](https://abc4trust.eu/index.php/pub) is available, e.g. an [*Architecture for Attribute-based Credential Technologies*](https://abc4trust.eu/download/Deliverable_D2.2.pdf) (also one [*for developers*](https://abc4trust.eu/download/ABC4Trust-H2.2_ABC4Trust_Architecture_for_Developers.pdf)). -[eIDAS5] [*"Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC"*](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG). *EUR-Lex*. The European Parliament and the Council of the European Union. +[eIDAS5] [*"Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic %%transactions|business-transaction%% in the internal market and repealing Directive 1999/93/EC"*](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG). *EUR-Lex*. The European Parliament and the Council of the European Union. ------ @@ -99,7 +99,7 @@ It is expected that there are already some interfaces out there that may turn ou There are two interface layers in this architecture -The '**ESSIF Glue**' interface layer consists of a [documented set of APIs](https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs) between the %%Data Collector|data-collector%% and %%data discloser|data-discloser%% on the one hand, and the WHIV components on the other hand. The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%data discloser|data-discloser%% and %%Data Collector|data-collector%%. Ultimately, we would like to see these APIs standardized. Having such APIs allows different %%parties|party%% 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. +The '**ESSIF Glue**' interface layer consists of a [documented set of APIs](https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs) between the %%data collector|data-collector%% and %%data discloser|data-discloser%% on the one hand, and the WHIV components on the other hand. The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%data discloser|data-discloser%% and %%data collector|data-collector%%. Ultimately, we would like to see these APIs standardized. Having such APIs allows different %%parties|party%% 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|party%% can then select such WHIV components as they see fit. The **SSI Tech APIs** interface layer is the union of the interfaces of the components within it. Any standardization in there is outside the scope of eSSIF-Lab. @@ -118,27 +118,27 @@ This section details the functional specifications of the components that are in ### 3.1. Data Collector and Validation Policy -The purpose of the %%data collector|data-collector%% is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%principal|principal%% to decide whether or not to engage in a (new) transaction of the specified type. +The purpose of the %%data collector|data-collector%% is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%principal|principal%% to decide whether or not to engage in a (new) %%transaction|business-transaction%% of the specified type. -Typically, the %%data collector|data-collector%% would start a transaction either +Typically, the %%data collector|data-collector%% would start a %%transaction|business-transaction%% either -- when it receives a request from some %%agent|agent%% of another %%party|party%% for engaging in a transaction of a specific kind. -- when it is instructed by, or on behalf of its %%principal|principal%%, to request a specific kind of transaction to some %%agent|agent%% of another %%party|party%%.[^DC.1] +- when it receives a request from some %%agent|agent%% of another %%party|party%% for engaging in a %%transaction|business-transaction%% of a specific kind. +- when it is instructed by, or on behalf of its %%principal|principal%%, to request a specific kind of %%transaction|business-transaction%% to some %%agent|agent%% of another %%party|party%%.[^DC.1] -In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a '**transaction-id**' must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the %%agent|agent%% that requested the transaction, but also with other %%agents|agent%% from the same %%principal|principal%% and/or using different %%communication channels|communication-channel%%. +In either case, a %%transaction|business-transaction%% form (object, context) has to be created that matches the kind of %%transaction|business-transaction%%, and a '**transaction-id**' must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this %%transaction|business-transaction%%, enabling communications to remain congruent, not only with the %%agent|agent%% that requested the %%transaction|business-transaction%%, but also with other %%agents|agent%% from the same %%principal|principal%% and/or using different %%communication channels|communication-channel%%. -Handling/managing the various %%communication channels|communication-channel%% through which data can be exchanged is also a task of the Data Collector[^DC.2]. One reason for this is that negotiating a transaction not only requires data to be acquired, but also to be provided to the %%peer party|peer-party%%. Another reason is that the %%peer party|peer-party%% may use multiple %%agents|agent%% to provide such data, e.g. human %%agents|agent%% (that might use web-browsers, social-media apps, phones, or physical visits), %%SSI-agents|ssi-agent%% (that use the SSI infrastructure), or other %%electronic agents|digital-agent%% (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens). +Handling/managing the various %%communication channels|communication-channel%% through which data can be exchanged is also a task of the Data Collector[^DC.2]. One reason for this is that negotiating a %%transaction|business-transaction%% not only requires data to be acquired, but also to be provided to the %%peer party|peer-party%%. Another reason is that the %%peer party|peer-party%% may use multiple %%agents|agent%% to provide such data, e.g. human %%agents|agent%% (that might use web-browsers, social-media apps, phones, or physical visits), %%SSI-agents|ssi-agent%% (that use the SSI infrastructure), or other %%electronic agents|digital-agent%% (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens). -Thus, the %%Data Collector|data-collector%% is generally considered capable of obtaining data through different %%communication channels|communication-channel%%. However, the technical tracks of eSSIF-Lab will exclusively focus on the %%communication channel|communication-channel%% through which %%credentials|credential%% can be requested and obtained. Any extensions or business productization of %%Data Collector|data-collector%% designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section. +Thus, the %%data collector|data-collector%% is generally considered capable of obtaining data through different %%communication channels|communication-channel%%. However, the technical tracks of eSSIF-Lab will exclusively focus on the %%communication channel|communication-channel%% through which %%credentials|credential%% can be requested and obtained. Any extensions or business productization of %%data collector|data-collector%% designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section. -In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the %%data collector|data-collector%% needs to know what kinds of %%credentials|credential%% it should ask for, which %%parties|party%% its %%principal|principal%% trusts to issue such %%credentials|credential%%, what kinds of verification proofs for such %%credentials|credential%% must hold and which may be disregarded.[^DC.3] Also, when the %%data collector|data-collector%% gets a %%credential|credential%% that satisfies the necessary verification proofs, it needs a way to map the contents of that %%credential|credential%% to the structure of the transaction context that is used internally by (other systems of) its %%principal|principal%%.[^DC.4] Also, as the %%data collector|data-collector%% gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^DC.5] +In order to acquire data through SSI mechanisms for filling in a form for a specific kind of %%transaction|business-transaction%%, the %%data collector|data-collector%% needs to know what kinds of %%credentials|credential%% it should ask for, which %%parties|party%% its %%principal|principal%% trusts to issue such %%credentials|credential%%, what kinds of verification proofs for such %%credentials|credential%% must hold and which may be disregarded.[^DC.3] Also, when the %%data collector|data-collector%% gets a %%credential|credential%% that satisfies the necessary verification proofs, it needs a way to map the contents of that %%credential|credential%% to the structure of the %%transaction|business-transaction%% context that is used internally by (other systems of) its %%principal|principal%%.[^DC.4] Also, as the %%data collector|data-collector%% gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^DC.5] -In order to make the %%data collector|data-collector%% work, a %%Validation Policy|validation-policy%% (or %%data collector policy|data-collector-policy%%) is created by, or on behalf of the %%principal|principal%%, which specifies at least: +In order to make the %%data collector|data-collector%% work, a %%validation policy|validation-policy%% (or %%data collector policy|data-collector-policy%%) is created by, or on behalf of the %%principal|principal%%, which specifies at least: -- the kinds of transactions the %%principal|principal%% is willing to (electronically) engage in, from both the requester and the provider perspectives; -- for each such transaction type: +- the kinds of %%transactions|business-transaction%% the %%principal|principal%% is willing to (electronically) engage in, from both the requester and the provider perspectives; +- for each such %%transaction type|transaction-type%%: - - the criteria (business rules) that should be used to determine that the form is 'clean', i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a transaction commitment decision. + - the criteria (business rules) that should be used to determine that the form is 'clean', i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a %%transaction|business-transaction%% commitment decision. - the kinds of %%credentials|credential%% and %%issuers|issuer%% that the %%principal|principal%% is willing to accept as sources for valid data; (optionally?), the endpoint URI at which issuing %%parties|party%% do the actual %%credential|credential%% issuing may be specified[^DC.6]. @@ -148,23 +148,23 @@ In order to make the %%data collector|data-collector%% work, a %%Validation Poli The %%policy|policy%% must be designed in such a way that it is extendable as new features will be called for in the future. -The ability to create new transaction contexts and the availability of the %%data collector policy|data-collector-policy%% enable the %%data collector|data-collector%% to request the %%verifier|verifier%% component of its %%principal|principal%% to obtain %%credentials|credential%% of the types that it can use to fill in the transaction form when they satisfy the verification and validation requirements of its %%principal|principal%%.[^DC.7] +The ability to create new %%transaction|business-transaction%% contexts and the availability of the %%data collector policy|data-collector-policy%% enable the %%data collector|data-collector%% to request the %%verifier|verifier%% component of its %%principal|principal%% to obtain %%credentials|credential%% of the types that it can use to fill in the %%transaction form|transaction-form%% when they satisfy the verification and validation requirements of its %%principal|principal%%.[^DC.7] -When the %%verifier|verifier%% returns such data (which comes with a list of proofs that the %%verifier|verifier%% has checked), the %%data collector|data-collector%% must then validate that data, i.e. determine whether or not it is valid for the specific transaction it is assembling the data for. The validation rules are %%party|party%%-specific and hence come from the %%data collector policy|data-collector-policy%%. For simple cases, validation can simply consist of checking whether or not all verification proofs succeeded. At the other end of the validation spectrum, the %%data collector|data-collector%% itself must make validation decisions, either electronically (according to the %%data collector policy|data-collector-policy%%) or by 'outsourcing' such decisions to human %%agents|agent%% of its %%principal|principal%% by providing an appropriate validation user interface. +When the %%verifier|verifier%% returns such data (which comes with a list of proofs that the %%verifier|verifier%% has checked), the %%data collector|data-collector%% must then validate that data, i.e. determine whether or not it is valid for the specific %%transaction|business-transaction%% it is assembling the data for. The validation rules are %%party|party%%-specific and hence come from the %%data collector policy|data-collector-policy%%. For simple cases, validation can simply consist of checking whether or not all verification proofs succeeded. At the other end of the validation spectrum, the %%data collector|data-collector%% itself must make validation decisions, either electronically (according to the %%data collector policy|data-collector-policy%%) or by 'outsourcing' such decisions to human %%agents|agent%% of its %%principal|principal%% by providing an appropriate validation user interface. As long as data is needed, the %%data collector|data-collector%% can intermittently request the %%verifier|verifier%% to produce it (or it can use other %%communication channels|communication-channel%%, which is outside scope for now). It does so until it times out, or the form has become 'clean'. ----- -[^DC.1]: This feature ensures that the transaction is really two-way, and both %%parties|party%% can request %%credentials|credential%% from the other. For example, a web-shop can then ask for a (delivery) address %%credential|credential%%, and the customer can ask for a %%credential|credential%% issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). +[^DC.1]: This feature ensures that the %%transaction|business-transaction%% is really two-way, and both %%parties|party%% can request %%credentials|credential%% from the other. For example, a web-shop can then ask for a (delivery) address %%credential|credential%%, and the customer can ask for a %%credential|credential%% issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). [^DC.2]: It may well be that this functionality can somehow be split off in the (near) future. -[^DC.3]: For high-value transactions, verification proofs are more important than for low-value transactions. This is to be decided by the %%principal|principal%% of the %%data collector|data-collector%%. An example from the physical world: in order to obtain a visa for China, it is required that your passport (%%credential|credential%%) remains valid for 3 months after the end of your visit. But in order to identify yourself at the reception desk of a hotel, your passport may have expired several years. +[^DC.3]: For high-value %%transactions|business-transaction%%, verification proofs are more important than for low-value %%transactions|business-transaction%%. This is to be decided by the %%principal|principal%% of the %%data collector|data-collector%%. An example from the physical world: in order to obtain a visa for China, it is required that your passport (%%credential|credential%%) remains valid for 3 months after the end of your visit. But in order to identify yourself at the reception desk of a hotel, your passport may have expired several years. [^DC.4]: For example, a %%credential|credential%% that contains an address uses a specific schema to specify addresses, e.g. the 'PostalAddress' as defined by schema.org. This schema differs quite a bit from that of Dutch addresses as [*defined*](https://bag.basisregistraties.overheid.nl/def/bag) by the official (authentic) Dutch Registration of Addresses and Buildings (BAG). It may also well differ from the structure of addresses that databases of the %%principal|principal%% have implemented. Mapping allows such cases to be accommodated for. -[^DC.5]: Inconsistent or incoherent data is necessary for various purposes. First, it allows for correct further processing of the transaction. A non-existent postal code, or one that doesn't match the delivery address, may hinder a fluent transaction processing, resulting in additional costs and processing times. Another purpose is the early warning or detection of possible fraud/abuse. Remember that part of the data is being asked for reducing transaction risk, and checking consistency/coherence of such data is part of the risk mitigation process. +[^DC.5]: Inconsistent or incoherent data is necessary for various purposes. First, it allows for correct further processing of the %%transaction|business-transaction%%. A non-existent postal code, or one that doesn't match the delivery address, may hinder a fluent %%transaction|business-transaction%% processing, resulting in additional costs and processing times. Another purpose is the early warning or detection of possible fraud/abuse. Remember that part of the data is being asked for reducing %%transaction|business-transaction%% %%risk|risk%%, and checking consistency/coherence of such data is part of the risk mitigation process. [^DC.6]: This enables the %%data collector|data-collector%% to pass the endpoint URI on to the %%verifier|verifier%% when it requests for such a %%credential|credential%%, which in turn can send it to the %%holder|holder%% of other %%parties|party%% enabling them to obtain the %%credential|credential%% from that %%issuer|issuer%% endpoint if that other %%party|party%% does not have that %%credential|credential%% in its %%wallet|wallet%%. The endpoint URI can in fact be put in the %%policy|policy%%, because the (human) %%agent|agent%% that creates/maintains the %%policy|policy%% would need to know that the issuing %%party|party%% is actually issuing such %%credentials|credential%%, what their contents means, etc., and hence is capable of tracking down the URI where that %%party|party%% issues the %%credentials|credential%%. @@ -174,17 +174,17 @@ As long as data is needed, the %%data collector|data-collector%% can intermitten ### 3.2. Verifier Component, and its Policy/Preferences -The purpose of the %%verifier|verifier%% component is to support the %%data collector|data-collector%% by providing it with a single, simple API that it can use to request and obtain data that it needs to produce a clean transaction form, as well as the results of checking verification proofs (this is also why it is called the '%%verifier|verifier%%' component). +The purpose of the %%verifier|verifier%% component is to support the %%data collector|data-collector%% by providing it with a single, simple API that it can use to request and obtain data that it needs to produce a clean %%transaction form|transaction-form%%, as well as the results of checking verification proofs (this is also why it is called the '%%verifier|verifier%%' component). -Typically, the %%data collector|data-collector%% would ask the %%verifier|verifier%% to provide a %%credential|credential%% that it can use to fill in a (coherent set of) field(s) in the transaction form. It is realistic to think that %%credentials|credential%% from different %%issuers|issuer%% - trusted by the %%verifier's|verifier%% %%principal|principal%% - can be used for this purpose. However, it is also realistic that such %%credentials|credential%% will not use the same %%credential type|credential-type%% - they might well use different schemes to provide such data. Therefore, the %%data collector|data-collector%% should specify a list of pairs (%%credential-type|credential-type%%, %%issuer|issuer%%) instances of which could all be used to provide the data it needs - which it can obtain from the %%data collector policy|data-collector-policy%%. +Typically, the %%data collector|data-collector%% would ask the %%verifier|verifier%% to provide a %%credential|credential%% that it can use to fill in a (coherent set of) field(s) in the %%transaction form|transaction-form%%. It is realistic to think that %%credentials|credential%% from different %%issuers|issuer%% - trusted by the %%verifier's|verifier%% %%principal|principal%% - can be used for this purpose. However, it is also realistic that such %%credentials|credential%% will not use the same %%credential type|credential-type%% - they might well use different schemes to provide such data. Therefore, the %%data collector|data-collector%% should specify a list of pairs (%%credential-type|credential-type%%, %%issuer|issuer%%) instances of which could all be used to provide the data it needs - which it can obtain from the %%data collector policy|data-collector-policy%%. -Then, the %%verifier|verifier%% needs to know the address and protocol that it can use to reach a %%holder|holder%% component owned by the %%party|party%% that its %%principal|principal%% is trying to negotiate the transaction with. The %%data collector|data-collector%% specifies this as part of the request - and it can do so because it has received the original request, and does all %%communication channel|communication-channel%% handling. +Then, the %%verifier|verifier%% needs to know the address and protocol that it can use to reach a %%holder|holder%% component owned by the %%party|party%% that its %%principal|principal%% is trying to negotiate the %%transaction|business-transaction%% with. The %%data collector|data-collector%% specifies this as part of the request - and it can do so because it has received the original request, and does all %%communication channel|communication-channel%% handling. %%verifiers|verifier%% are not expected to handle every kind of %%credential|credential%% (e.g. VC's, ABC's, etc.) that exists, but rather a specific subset. For (at least one of) the %%credential types|credential-type%%, the %%verifier|verifier%% can construct a so-called %%presentation request|presentation-request%%, i.e. a message that is specific for the %%credential type|credential-type%% and/or associated protocol, which it can then send to the %%holder's|holder%% address. This request message should contain at least -- the transaction-id, so that when it is copied into the associated response message, the latter can be associated to the transaction it belongs to. Also, it should contain the +- the %%transaction-id|transaction-id%%, so that when it is copied into the associated response message, the latter can be associated to the %%transaction|business-transaction%% it belongs to. Also, it should contain the - the (%%credential type|credential-type%%, %%issuer|issuer%%) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the %%issuer|issuer%% issues such %%credentials|credential%%, the maximum age of the %%credential|credential%%, etc. - meta-data that may be useful for the %%holder|holder%% (or its %%principal|principal%%), e.g. texts stating the purpose(s) for which the data will be used ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.b), or requesting consent ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 7.2) “in an intelligible and easily accessible form, using clear and plain language”. - a signature of the %%verifiers|verifier%% %%principal|principal%%, for the purpose of showing compliance with the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) (e.g. Art 28.3.h), and enabling the %%holder's|holder%% %%principal|principal%% to obtain proof that the %%verifiers|verifier%% %%principal|principal%% has violated the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)'s minimization principle asked for data for a particular purpose, which can be used in an argument in disputes about data minimization ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.c). @@ -195,15 +195,15 @@ In order to make the %%verifier|verifier%% component work, a %%verifier policy|v A response to this request (called a %%presentation|presentation%%) will be obtained from a %%holder|holder%% component of the %%peer party|peer-party%%. This response will contain a reference to the request, allowing the %%verifier|verifier%% to combine them. The %%verifier|verifier%% will then check that the data in the response is a %%credential|credential%% that it has asked for (correct type/%issuer%), verify the proofs that are provided (predominantly the digital signature), and do some additional checks (e.g. whether or not the %%credential|credential%% has expired, is revoked, and such). -Then, the %%verifier|verifier%% will send a message to the %%data collector|data-collector%%, containing the transaction-id, the data it has received, and the results of the various checks. +Then, the %%verifier|verifier%% will send a message to the %%data collector|data-collector%%, containing the %%transaction-id|transaction-id%%, the data it has received, and the results of the various checks. ### 3.3. Holder Component, and its Policy/Preferences -The purpose of the %%holder|holder%% component is to handle %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (both of its own %%principal|principal%%, and of other %%parties|party%%), and responding to such requests. +The purpose of the %%holder|holder%% component is to handle %%presentation requests|presentation-request%% that it receives from %%verifier|verifier%% components (both of its own %%principal|principal%%, and of other %%parties|party%%), and responding to such requests. Typically, a %%holder|holder%% component would access its %%principal's|principal%% %%wallet|wallet%% to check if it has a %%credential|credential%% that it can use to construct a %%presentation|presentation%% (i.e. response) that satisfies the received request. -It may happen that the %%wallet|wallet%% does not have such a %%credential|credential%%. However, for every (%%credential|credential%%, %%issuer|issuer%%) pair, the request should specify the URI that is capable of issuing such a %%credential|credential%%. If or when the %%holder policy|holder-policy%% permit this, the %%holder|holder%% then requests its %%principal's|principal%% %%data collector|data-collector%% to initiate a new transaction that will get the %%credential|credential%% from that %%issuer|issuer%%, for which a clean transaction form would then consist of one that contains said %%credential|credential%%. The %%holder|holder%% would then store it in its %%principal's|principal%% %%wallet|wallet%%, and then proceed to service the %%presentation|presentation%% request as if it had obtained that %%credential|credential%% from its %%principal's|principal%% %%wallet|wallet%%. +It may happen that the %%wallet|wallet%% does not have such a %%credential|credential%%. However, for every (%%credential|credential%%, %%issuer|issuer%%) pair, the request should specify the URI that is capable of issuing such a %%credential|credential%%. If or when the %%holder policy|holder-policy%% permit this, the %%holder|holder%% then requests its %%principal's|principal%% %%data collector|data-collector%% to initiate a new %%transaction|business-transaction%% that will get the %%credential|credential%% from that %%issuer|issuer%%, for which a clean %%transaction form|transaction-form%% would then consist of one that contains said %%credential|credential%%. The %%holder|holder%% would then store it in its %%principal's|principal%% %%wallet|wallet%%, and then proceed to service the %%presentation|presentation%% request as if it had obtained that %%credential|credential%% from its %%principal's|principal%% %%wallet|wallet%%. It may also happen that the %%wallet|wallet%% has multiple %%credentials|credential%% that satisfy the request, in which case the %%holder|holder%% must choose the one to use for constructing the %%presentation|presentation%%. Again, the %%holder policy|holder-policy%% will specify how this choice needs to be made, and whether or not this can be done automatically by the %%holder|holder%%. If not, the %%holder|holder%% will need to provide for an interaction with a human Colleague that will make such decisions. @@ -217,7 +217,7 @@ In order to make the %%holder|holder%% component work, a %%holder policy|holder- The purpose of the %%data discloser|data-discloser%% component is to state the (various, sometimes intermediary) results of %%transactions|business-transaction%%, by collecting data from the Business Data Stores, and creating a set of (related) %%statements/claims|assertion%% that can subsequently be issued to other %%parties|party%%. A special kind of result is the (provisioning of) a %%credential|credential%% that its %%principal|principal%% already has created. -Typically, and at any point in time, %%parties|party%% are capable of expressing %%statements|assertion%% about %%entities|entity%% that they know to exist. They could express %%statements|assertion%% about individuals, about themselves, the state of transactions, and so on. We will use the term '**subject (of a %%statement|assertion%% of a %%party|party%%)**' to refer to the %%entity|entity%% that this %%party|party%% knows to exist, and about whom/which the %%statement|assertion%% has been made. +Typically, and at any point in time, %%parties|party%% are capable of expressing %%statements|assertion%% about %%entities|entity%% that they know to exist. They could express %%statements|assertion%% about individuals, about themselves, the state of %%transactions|business-transaction%%, and so on. We will use the term '**subject (of a %%statement|assertion%% of a %%party|party%%)**' to refer to the %%entity|entity%% that this %%party|party%% knows to exist, and about whom/which the %%statement|assertion%% has been made. We will use the term '**subject-id (of a %%statement|assertion%% of a %%party|party%%)**' to refer to the representation that this %%party|party%% has chosen to use for referring to the subject in said %%statement|assertion%%. A subject-id must have the property of being an %%identifier|identifier%% within every administrative context that this %%party|party%% uses. It need not be humanly interpretable (and preferably is not). @@ -241,7 +241,7 @@ The %%data discloser|data-discloser%% may either push %%credential|credential%% The purpose of the %%issuer|issuer%% component is to issue '%%credentials|credential%%', i.e. digital constructs that contain - sets of (related) %%statements/claims|assertion%% (e.g. as produced by the %%data discloser|data-discloser%%) -- metadata (e.g. type of %%credential|credential%%, date of issuing and expiration, endpoints, e.g. for revocation checking, %%credential type|credential-type%%, credential advertisements, credential enforcement policy, etc.) +- metadata (e.g. type of %%credential|credential%%, date of issuing and expiration, endpoints, e.g. for revocation checking, %%credential type|credential-type%%, credential advertisements, credential enforcement %%policy|policy%%, etc.) - proofs (e.g. a digital signature by which third %%parties|party%% can prove its provenance and integrity. Another purpose that an %%issuer|issuer%% might serve is to provide a means that allows any other %%agent|agent%% that somehow has obtained a copy or %%presentation|presentation%% of a %%credential|credential%%, to verify whether or not the data therein is conformant to the business administration of its %%principal|principal%%. We will use the term 'revocation service' to refer to such means. Whether or not an %%issuer|issuer%% provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its %%principal|principal%% should make, and specify in the %%issuer policy|issuer-policy%%. @@ -288,9 +288,9 @@ In order to make the %%wallet|wallet%% component work, a %%wallet policy|wallet- *The eSSIF-Lab functional architecture is not final. This chapter is an example of how work that is currently being done may already be documented for the purpose of furthering discussions and providing inspiration to readers.* ::: -%%parties|party%% need to deploy (technical) components that act as their %%agents|agent%%. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of %%holder|holder%%, %%verifier|verifier%% and %%issuer|issuer%%. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second %%(digital) agent|digital-agent%%. An individual might also have (cloud) servers that %%agents|agent%% of other %%parties|party%% may contact for conducting transactions without the need for the individual itself to do something. All of this holds equally well for larger %%organizations|organization%%. +%%parties|party%% need to deploy (technical) components that act as their %%agents|agent%%. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of %%holder|holder%%, %%verifier|verifier%% and %%issuer|issuer%%. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second %%(digital) agent|digital-agent%%. An individual might also have (cloud) servers that %%agents|agent%% of other %%parties|party%% may contact for conducting %%transactions|business-transaction%% without the need for the individual itself to do something. All of this holds equally well for larger %%organizations|organization%%. -It is conceivable that the set of SSI functions is spread over multiple %%(digital) agents|digital-agent%%, in which case there is going to be a need for such %%agents|agent%% to contact one another, and conduct transactions in a way that may differ from doing that with %%agents|agent%% of other %%parties|party%%. Basically, this can be seen as %%colleagues|colleague%% interacting with one another to get things done within one %%organization|organization%%. Seen from the outside, it looks like every %%organization|organization%% has a (smaller or larger) network of %%agents|agent%%. This chapter provides more details on this topic. +It is conceivable that the set of SSI functions is spread over multiple %%(digital) agents|digital-agent%%, in which case there is going to be a need for such %%agents|agent%% to contact one another, and conduct %%transactions|business-transaction%% in a way that may differ from doing that with %%agents|agent%% of other %%parties|party%%. Basically, this can be seen as %%colleagues|colleague%% interacting with one another to get things done within one %%organization|organization%%. Seen from the outside, it looks like every %%organization|organization%% has a (smaller or larger) network of %%agents|agent%%. This chapter provides more details on this topic. The SSI-Agent Network Architecture has two viewpoints: @@ -302,7 +302,7 @@ An individual %%party|party%% may use the single-%%party|party%% SSI viewpoint t - How can electronic components be onboarded as an %%agents|agent%% of this %%party|party%%? - How can the integrity of such %%electronic agent|digital-agent%% be stated in a trustworthy manner (do such components need some kind of accreditation certificate, do we need to come up with a service that can remotely test the integrity of a component and have it issue ephemeral integrity-certificates/%credentials%, …)? - How can the %%party|party%% specify which of its %%agents|agent%% may talk with which other %%agents|agent%%, and for what purposes? -- How should a %%party|party%% specify the policies for the various SSI functionalities - what kind of support would be useful here? +- How should a %%party|party%% specify the %%policies|policy%% for the various SSI functionalities - what kind of support would be useful here? - … %%parties|party%% that want (their %%agents|agent%%) to interact with one another may use the multi-%%party|party%% SSI viewpoint to come to grips with concerns related to the interoperability of the functionalities that their components implement. The set of concerns would include: @@ -326,7 +326,7 @@ This chapter explains at a high level how electronic %%business transactions|bus *Figure 3: High-level transaction overview.* -The adjacent figure shows how a transaction is conducted at the highest abstraction level. One %%party|party%%, called the 'Requester', sends a request for a product or service to another %%party|party%% (that we will call the 'Provider'). Then, they start to negotiate a 'transaction agreement', which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate transaction risks, etc., all of which is necessary for the %%parties|party%% to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase. +The adjacent figure shows how a %%transaction|business-transaction%% is conducted at the highest abstraction level. One %%party|party%%, called the 'Requester', sends a request for a product or service to another %%party|party%% (that we will call the 'Provider'). Then, they start to negotiate a 'transaction agreement', which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate %%transaction|business-transaction%% %%risks|risk%%, etc., all of which is necessary for the %%parties|party%% to (individually/subjectively) decide whether or not to commit to the %%transaction|business-transaction%%. Section 3.2 provides more detail about this phase. After commitment, the producer works to provide the product or service, and the requester arranges the compensation. This phase is entirely up to the business, and hence out of scope of this document. @@ -334,11 +334,11 @@ When all is done, %%parties|party%% may issue a (signed) %%statement|assertion%% In the example of the parking permit, a citizen (requester) sends a request to its municipality (provider) for obtaining a parking permit (the product/service). Then, the citizen fills in an online form (and uploads necessary PDFs) to enable the municipality to decide whether or not to produce the requested permit. The eSSIF-lab architecture adds a secondary, %%electronic communication channel|digital-communication-channel%% that allows citizens to fill in the forms by using e.g. an SSI app on their phone. When the form is complete, the municipality decides whether or not to produce and issue the permit, which it can do as usual. It can also issue a %%credential|credential%% that states the result of the %%transaction|business-transaction%%, i.e. contains the details of the parking permit. -Please note that while %%transactions|business-transaction%% are symmetrical in nature (i.e. both requester and provider need data from the other so as to decide whether or not to commit to the transaction), there is an implicit asymmetry in that activities that %%parties|party%% perform are ordered in time, which implies e.g. that the commitment decisions of both %%parties|party%% cannot be done at the same time. Also, in practice, it often happens that a %%party|party%% requires the other %%party|party%% to have executed (and stated) its part of the transaction before it actually commits to the transaction. For example, a provider may require the requester to have paid for the product before it is being shipped out. Consequently, the protocols for exchanging data/%credentials% will need to support such 'asynchronous' ways of working. +Please note that while %%transactions|business-transaction%% are symmetrical in nature (i.e. both requester and provider need data from the other so as to decide whether or not to commit to the %%transaction|business-transaction%%), there is an implicit asymmetry in that activities that %%parties|party%% perform are ordered in time, which implies e.g. that the commitment decisions of both %%parties|party%% cannot be done at the same time. Also, in practice, it often happens that a %%party|party%% requires the other %%party|party%% to have executed (and stated) its part of the %%transaction|business-transaction%% before it actually commits to the %%transaction|business-transaction%%. For example, a provider may require the requester to have paid for the product before it is being shipped out. Consequently, the protocols for exchanging data/%credentials% will need to support such 'asynchronous' ways of working. ### 5.2. Transaction Negotiation Phase -This phase starts by the requester sending a transaction request to the provider, and ends whenever either one of the %%parties|party%% quits, or both %%parties|party%% commit. +This phase starts by the requester sending a %%transaction request|transaction-request%% to the provider, and ends whenever either one of the %%parties|party%% quits, or both %%parties|party%% commit.