Commit 7a7fef7a authored by Georgios D. Tsoukalas's avatar Georgios D. Tsoukalas

Address some of essif_lab_review.md comments

parent 92129440
...@@ -94,9 +94,9 @@ It is expected that there are already some interfaces out there that may turn ou ...@@ -94,9 +94,9 @@ It is expected that there are already some interfaces out there that may turn ou
There are two interface layers in this architecture There are two interface layers in this architecture
The \`**ESSIF Glue**\` interface layer consists of a set of API’s between the Transaction (Validation) Engine and Transaction Result Dispatcher on the one hand, and the WHIV components on the other hand. The specification of these API’s can be found in \[reference needed\]. The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the Transaction Result Dispatcher and Transaction (Validation) Engine. Ultimately, we would like to see these API’s 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. The \`**ESSIF Glue**\` interface layer consists of a set of APIs between the Transaction (Validation) Engine and Transaction Result Dispatcher on the one hand, and the WHIV components on the other hand.<!-- The specification of these APIs can be found in \[reference needed\].--> The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the Transaction Result Dispatcher and Transaction (Validation) Engine. 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.
The **SSI Tech APIs** interface layer is the union of the interfaces that the components that are in it provide. Any standardization in there is outside the scope of eSSIF-Lab. 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.
## 3. eSSIF-Lab Infrastructure Functional Components ## 3. eSSIF-Lab Infrastructure Functional Components
...@@ -136,11 +136,9 @@ In order to make the TVE work, a Validation Policy (or TVE Policy) is created by ...@@ -136,11 +136,9 @@ In order to make the TVE work, a Validation Policy (or TVE Policy) is created by
- the mapping between fields in such credentials and fields in the form to be filled in. - the mapping between fields in such credentials and fields in the form to be filled in.
- (anything else?)
The Policy must be designed in such a way that it is extendable as new features will be called for in the future. The 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 TVE Policy enable the TVE to request the Verifier component of its owner to obtain credentials of the types that it can use to fill in the transaction form when they satisfy the verification and validation requirements of its owner. The specification of such requests is given in \[reference needed\]. The ability to create new transaction contexts and the availability of the TVE Policy enable the TVE to request the Verifier component of its owner to obtain credentials of the types that it can use to fill in the transaction form when they satisfy the verification and validation requirements of its owner.<!-- The specification of such requests is given in \[reference needed\]. -->
When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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-specific and hence come from the TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human agents of its owner by providing an appropriate validation user interface. When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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-specific and hence come from the TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human agents of its owner by providing an appropriate validation user interface.
...@@ -148,7 +146,7 @@ As long as data is needed, the TVE can intermittently request the verifier to pr ...@@ -148,7 +146,7 @@ As long as data is needed, the TVE can intermittently request the verifier to pr
----- -----
[TVE.1] This feature ensures that the transaction is really two-way, and both parties can request credentials from the other. For example, a web-shop can then ask for a (delivery)address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). [TVE.1] This feature ensures that the transaction is really two-way, and both parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website).
[TVE.2] It may well be that this functionality can somehow be split off in the (near) future. [TVE.2] It may well be that this functionality can somehow be split off in the (near) future.
...@@ -178,7 +176,6 @@ This request message should contain at least ...@@ -178,7 +176,6 @@ This request message should contain at least
- the (credential type, issuer) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the issuer issues such credentials, the maximum age of the credential, etc. - the (credential type, issuer) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the issuer issues such credentials, the maximum age of the credential, etc.
- meta-data that may be useful for the holder (or its owner), 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”. - meta-data that may be useful for the holder (or its owner), 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 owner, 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 owner to obtain proof that the Verifiers owner 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). - a signature of the Verifiers owner, 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 owner to obtain proof that the Verifiers owner 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).
- (anything else?)
The request message must be designed in such a way that it is extendable as new features will be called for in the future. The request message must be designed in such a way that it is extendable as new features will be called for in the future.
...@@ -203,7 +200,6 @@ In order to make the Holder component work, a Holder Policy/Preferences object i ...@@ -203,7 +200,6 @@ In order to make the Holder component work, a Holder Policy/Preferences object i
- whether or not credentials may be collected ‘on the fly’; - whether or not credentials may be collected ‘on the fly’;
- how to choose between credentials that all satisfy a presentation request (and whether the Holder can make such choices by itself, or whether or not human interaction is required); - how to choose between credentials that all satisfy a presentation request (and whether the Holder can make such choices by itself, or whether or not human interaction is required);
- the kinds of events and data to write to a holder-audit-log. - the kinds of events and data to write to a holder-audit-log.
- (anything else?)
### 3.4. Transaction Result Dispatcher and Issuing Policy ### 3.4. Transaction Result Dispatcher and Issuing Policy
...@@ -259,7 +255,6 @@ The primary purpose of the Wallet Component is to (securely) store data, and in ...@@ -259,7 +255,6 @@ The primary purpose of the Wallet Component is to (securely) store data, and in
- 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, and - 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, and
- (private) keys e.g. for signing/sealing data on behalf of its owner. - (private) keys e.g. for signing/sealing data on behalf of its owner.
- \[anything else?\]
Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense. Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense.
...@@ -273,7 +268,7 @@ By ‘securely storing data’ we mean that such data ...@@ -273,7 +268,7 @@ By ‘securely storing data’ we mean that such data
It is expected that components other than the Holder and Issuer will (arise and) need access. One example could be a component that is capable of securely signing data on behalf of the owner. Another example could be a component that implements some kind of credential revocation functionality. It is expected that components other than the Holder and Issuer will (arise and) need access. One example could be a component that is capable of securely signing data on behalf of the owner. Another example could be a component that implements some kind of credential revocation functionality.
Human Beings cannot directly access any Wallet component, not even the ones they own. They need an electronic agent that is capable of authenticating them as (an agent of) the party that owns the Wallet component, and upon successful authentication provides a User Interface through which the Human Being can instruct this electronic agent to manage the Wallet’s contents. Human beings cannot directly access any Wallet component, not even the ones they own. They need an electronic agent that is capable of authenticating them as (an agent of) the party that owns the Wallet component, and upon successful authentication provides a User Interface through which the Human Being can instruct this electronic agent to manage the Wallet’s contents.
In order to make the Wallet component work, a Wallet Policy/Preferences object is created by, or on behalf of the owner, the contents of which remains to be specified. In order to make the Wallet component work, a Wallet Policy/Preferences object is created by, or on behalf of the owner, the contents of which remains to be specified.
......
...@@ -34,7 +34,7 @@ The figure below is a high-level visualization of the filling in and validation ...@@ -34,7 +34,7 @@ The figure below is a high-level visualization of the filling in and validation
![eSSIF-Lab - vision context](https://essif-lab.pages.grnet.gr/framework//images/vision-context.png) *Figure 1. High-level visualization of the filling in and validation of a form.* ![eSSIF-Lab - vision context](https://essif-lab.pages.grnet.gr/framework//images/vision-context.png) *Figure 1. High-level visualization of the filling in and validation of a form.*
The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent *RA*, i.e. an SSI-aware app on his mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third party, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *PA* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure communications channel (e.g. SSL, DIDComm) and agree on the specific form that needs to be filled in. The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent, *the Requestor Agent (RA)*, i.e. an SSI-aware app on their mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third party, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *Provider Agent (PA_* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure communications channel (e.g. SSL, DIDComm) and agree on the specific form that needs to be filled in.
After the *RA* and *PA* have established a communications channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy<sup>[3]</sup>. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data. After the *RA* and *PA* have established a communications channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy<sup>[3]</sup>. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data.
......
...@@ -7,15 +7,6 @@ Also, eSSIF-Lab Framework repository => eSSIF-Lab Framework Repository ...@@ -7,15 +7,6 @@ Also, eSSIF-Lab Framework repository => eSSIF-Lab Framework Repository
# https://gitlab.grnet.gr/essif-lab/framework/-/blob/master/docs/essif-lab-vision-and-purpose.md # https://gitlab.grnet.gr/essif-lab/framework/-/blob/master/docs/essif-lab-vision-and-purpose.md
The requestor has one electronic agent RA => spell out (explain) RA
(is it Requestor Agent?)
on his mobile phone => on their mobile phone (here and in all
documents please use gender-neutral expressions).
The provider has two agents: one is an SSI-aware component PA =>
spell out (explain) PA (is it Provider Agent?)
a secure communications channel (e.g. SSL, DIDComm) => Give reference a secure communications channel (e.g. SSL, DIDComm) => Give reference
to DIDComm. to DIDComm.
...@@ -26,8 +17,6 @@ capitalized; for example we may see "owner" or "Owner". For ...@@ -26,8 +17,6 @@ capitalized; for example we may see "owner" or "Owner". For
consistency and ease of understanding, all such terms should be consistency and ease of understanding, all such terms should be
capitalized. capitalized.
and every of its agents => and every one of its agents
Figure 1 shows the initial functional eSSIF-Lab architecture, and its Figure 1 shows the initial functional eSSIF-Lab architecture, and its
scope, context and (functional) components each of which is an agent scope, context and (functional) components each of which is an agent
for the same party (meaning that they are all part of the same for the same party (meaning that they are all part of the same
...@@ -42,32 +31,12 @@ In section 2.4, we have Transaction (Validation) Engine and ...@@ -42,32 +31,12 @@ In section 2.4, we have Transaction (Validation) Engine and
Transaction Result Dispatcher spelled out in full, while previously Transaction Result Dispatcher spelled out in full, while previously
their acronyms were used. Better to be consistent and use acronyms. their acronyms were used. Better to be consistent and use acronyms.
consists of a set of API’s => consists of a set of APIs
The specification of these API’s can be found in [reference needed]. The specification of these API’s can be found in [reference needed].
=> reference is missing. => reference is missing.
Ultimately, we would like to see these API’s standardized. =>
Ultimately, we would like to see these APIs standardized.
he SSI Tech APIs interface layer is the union of the interfaces that
the components that are in it provide. => Does not read properly.
(anything else?) (in section 3.1) => I suppose this has to go.
The specification of such requests is given in [reference needed]. => The specification of such requests is given in [reference needed]. =>
Missing reference. Missing reference.
(delivery)address credential, => (delivery) address credential,
(anything else?) (in section 3.2) => I suppose this has to go.
(anything else?) (in section 3.3) => I suppose this has to go.
[anything else?] (in section 3.6) => I suppose this has to go.
Human Beings => Human beings
Concerning section 4, Initial SSI-Agent Network Architecture, I did Concerning section 4, Initial SSI-Agent Network Architecture, I did
not really understand it or its purpose. not really understand it or its purpose.
......
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