✏️ typos

views/bdd.md

@@ -2,7 +2,7 @@
 
 In Behavior Driven Development (BDD), the important role of software integration and unit tests is extended to serve both the purposes of designing the human-machine interaction flow (user journey in UX terms) and of laying down a common ground for interaction between designers and stakeholders. In this Agile software development methodology the software testing suite is based on natural language units that grant a common understanding for all participants and observers.
 
-To implement BDD the first step is that of mapping a series of combinable, cascading sentences to actual source code; this implementation is usually done manually by programmers that have knowledge of the higher level application protocol interface (API) that grants communication between the backend and the frontend of a software application. The BDD implementation can then be seen as an alternative frontent whose purpose is that of lowering the distance between expression and execution by means of utterances expressed in human language.
+To implement BDD the first step is that of mapping a series of combinable, cascading sentences to actual source code; this implementation is usually done manually by programmers that have knowledge of the higher level application protocol interface (API) that grants communication between the backend and the frontend of a software application. The BDD implementation can then be seen as an alternative frontend whose purpose is that of lowering the distance between expression and execution by means of utterances expressed in human language.
 
 Far from giving an exhaustive description of BDD implementations and characteristics, this brief chapter intends to summarize the features of this approach where they specifically apply to the development goals of Zencode (previously stated) and the solution provided.
 
@@ -46,9 +46,9 @@ Given("declares also to be ''", function(decl)
 end)
 ```
 
-Shows how is possible to accept multiple variables and process them through more complex transformations that also contemplate the concatenation of contents to previous states. States are in fact permanent within the scope of the execution of a single utterance and will be modified in the same deterministic order by which they are expressed across lines. What is also visible within this example implementation, which we intend to facilitate by customisations made by people who have a simple knowledge of Zenroom's API and LUA scripting, is that the `ZEN.` namespace makes available a number of utility functions to easily check states (asserts) and propagate meaningful error messages that are then part of a traceback output given to the calling application (host) on occurrance of an error.
+Shows how is possible to accept multiple variables and process them through more complex transformations that also contemplate the concatenation of contents to previous states. States are in fact permanent within the scope of the execution of a single utterance and will be modified in the same deterministic order by which they are expressed across lines. What is also visible within this example implementation, which we intend to facilitate by customisations made by people who have a simple knowledge of Zenroom's API and LUA scripting, is that the `ZEN.` namespace makes available a number of utility functions to easily check states (asserts) and propagate meaningful error messages that are then part of a traceback output given to the calling application (host) on occurrence of an error.
 
-The full implementation of Zencode available at the time of publising this document is inside the sourcecode files `zenroom/src/lua/zencode_*` and is relatively easy to maintain for the pilots analysed in our project, as well easy to extend to more usecases. At the dawn of piloting sessions, due to the lack of actual feedback so far given in field trials, this implementation does not addresses specific schemes beyond a simple Diffie-Helman asymmetric key encryption (AES-GCM) and an even simplier symmetric encryption of ciphertext by means of a PIN and KDF trasformations. On top of that, perhaps the most complex implementation of Zencode so far is the "implicit certificate" crypto scheme (Qu-Vanstone, ECQV) still limited to first order curve transformations, which applies widely to pilots requiring simple certification schemes and is illustrated in more detail in the following chapters[^ecqv].
+The full implementation of Zencode available at the time of publishing this document is inside the sourcecode files `zenroom/src/lua/zencode_*` and is relatively easy to maintain for the pilots analysed in our project, as well easy to extend to more usecases. At the dawn of piloting sessions, due to the lack of actual feedback so far given in field trials, this implementation does not addresses specific schemes beyond a simple Diffie-Helman asymmetric key encryption (AES-GCM) and an even simplier symmetric encryption of ciphertext by means of a PIN and KDF transformations. On top of that, perhaps the most complex implementation of Zencode so far is the "implicit certificate" crypto scheme (Qu-Vanstone, ECQV) still limited to first order curve transformations, which applies widely to pilots requiring simple certification schemes and is illustrated in more detail in the following chapters[^ecqv].
 
 [^ecqv] It is important to note that while the ECQV scheme was not examined by other partners in our project, it has been choosen for its stable role in the industry and for its augmented complexity within an approachable implementation, complexity which could better inform the Zencode implementation. Without that complexity and without implementation feedback by other partners, it wouldn't have been possible to work on Zencode and bring it to what it is today, since both the Petition contract and the Coconut implementation in Zenroom are not available as of today and need to be completed in a later stage of the DECODE project.
 

views/implicit_certificate.md

@@ -4,15 +4,15 @@ This section will illustrate a Zencode implementation of the Elliptic Curve Qu-V
 
 > The ECQV implicit certificate scheme is intended as a general purpose certificate scheme for applications within computer and communications systems. It is particularly well suited for application environments where resources such as bandwidth, computing power and storage are limited. ECQV provides a more efficient alternative to traditional certificates.
 
-The ECQV is identifiable as a simple yet important building block within DECODE, as it permits the efficient creation of certiciates that contain only the public reconstruction data instead of the subject’s public key and the CA’s signature, also resulting into a smaller payload than traditional certificates.
+The ECQV is identifiable as a simple yet important building block within DECODE, as it permits the efficient creation of certificates that contain only the public reconstruction data instead of the subject’s public key and the CA’s signature, also resulting into a smaller payload than traditional certificates.
 
 ECQV relates well to those DECODE pilots in need to authenticate participants according to signed credentials, where the issuance of a public key is subject to the verification of certain conditions by a Certificate Authority (CA) capable of verifying and signing those conditions. This scenarios applies well to the pilot experimentations ongoing in Amsterdam for the DECODE project, where a certificate (and a keypair) is issued based on attributes that are certified by the municipal register and then used for authentication procedures operated by third parties and based on those attributes.
 
-The limit of this implementation is the lack of threshold certification, a problem that will be solved by the Coconut [cit] implementation in Zencode language, which is still a work in progress. However it should be noted that only one pilot in DECODE (Amsterdam's Gebiedonline) may benefit from this feature, which is however not vital to the deployement.
+The limit of this implementation is the lack of threshold certification, a problem that will be solved by the Coconut [cit] implementation in Zencode language, which is still a work in progress. However it should be noted that only one pilot in DECODE (Amsterdam's Gebiedonline) may benefit from this feature, which is however not vital to the deployment.
 
 ## Differences with traditional certificates
 
-To justify the implementation and adoption of ECQV in place of traditional certificates, here are quickly listed three salient characteristcs, closely referring to the documentation offered by the SEC4-1.0 document.
+To justify the implementation and adoption of ECQV in place of traditional certificates, here are quickly listed three salient characteristics, closely referring to the documentation offered by the SEC4-1.0 document.
 
 With traditional certificates, when an entity U requests a traditional certificate for a public key, U should prove to the CA it knows the corresponding private key. This is to prevent U from choosing an arbitrary public key, that may already belong to another user, and have it certified. This situation is clearly undesirable (and may even lead to security problems).  With implicit certificates this proof is unnecessary, as there is no public key before the certificate is issued. Further, U has no control over the final value of his public key, due to the CA’s contribution, making it impossible for U to cause the confusion described above.
 

views/schema.md

@@ -39,7 +39,7 @@ AES-GCM = S.record {
 
 In this example no new validations are being used and in fact it just adds fields compared to the previous: it defines a portable packet of ciphertext data that is returned as output of AES-GCM asymmetric encryption as well is accepted as input to AES-GCM decryption. A similarity between these two examples is evident: the presence of the `schema` field. This field is a sort of "introspective" indication matching the data structure to its schema specification. If this field is not present (as it is always optional) then no validation on the data structure will take place, meaning the Zencode implementation leaves the risk (and hopefully the validation task) to the host.
 
-This chapter ends with the current implementation of schema validation data types that are currently implemented for symmetric and asymmetric encryption of ciphertexts as well for implicit certificates. The schema impementation for Zencode is maintained into the sourcecode within the source file `src/lua/zencode_schemas.lua` and can be accessed by the function `ZEN.validate(data,'schema','error')` which is a wrapper of `ZEN.assert(validate(data,schemas['schema']),'error')`.
+This chapter ends with the current implementation of schema validation data types that are currently implemented for symmetric and asymmetric encryption of ciphertexts as well for implicit certificates. The schema implementation for Zencode is maintained into the sourcecode within the source file `src/lua/zencode_schemas.lua` and can be accessed by the function `ZEN.validate(data,'schema','error')` which is a wrapper of `ZEN.assert(validate(data,schemas['schema']),'error')`.
 
 
 ```lua