Merge branch 'main' into fix/scala-steward-dco

docs/decisions/20221005-using-tapir-library-as-a-dsl-for-openapi-specification.md

@@ -8,25 +8,25 @@
 Related ADR/AIP: [Introduce REST HTTP for existing Node services](https://input-output.atlassian.net/wiki/spaces/AV2/pages/3454500948/AIP+-+001)
 
 ## Context and Problem Statement
-PRISM Platform v2 will contain the REST API. The decision was made by team consensus during the first AOH meeting to follow "OpenAPI specification first" approach and generate stubs, server side and client side code based on OAS.
+Identus Platform will contain the REST API. The decision was made by team consensus during the first AOH meeting to follow "OpenAPI specification first" approach and generate stubs, server side and client side code based on OAS.
 Following this strategy we currently have 4-5 OAS files (Castor, Pollux, Mercury, Configuration).
 
 The following tool was selected for code generation: [OpenAPI Tools](https://github.com/OpenAPITools/openapi-generator)
 
 Instead of using the yaml file as OpenAPI specification and openapi-generator for server and client stub generation - this ADR proposes to use [Tapir](https://tapir.softwaremill.com/en/latest/index.html) Scala library as DSL for OpenAPI specification, `interpret` the endpoint defitions as Scala server and client stub, generate the yaml file, and use openapi-generator for client stubs.
 
-Technology stack that is going to be used in PRISM v2 backend: Scala 3 + ZIO ecosystem
+Technology stack that is going to be used in the Identus platform backend: Scala 3 + ZIO ecosystem
 
-Akka framework after version 2.6.x cannot be used because [Lightbend changed the license type to BSL 1.1](https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka). 
+Akka framework after version 2.6.x cannot be used because [Lightbend changed the license type to BSL 1.1](https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka).
 
 Looks like Akka 2.6.x still can be used according to [License FQA](https://www.lightbend.com/akka/license-faq)
 
-Currently, we have a code generation for Akka that is wrapped up into ZIO. Code generation mustache templates for ZIO-http are not available in OpenAPI tools. 
+Currently, we have a code generation for Akka that is wrapped up into ZIO. Code generation mustache templates for ZIO-http are not available in OpenAPI tools.
 
-Mustache templates and code generation doesn't work out of the box, so the original templates where copied to the project and fixed by @Shota and @Pat. 
+Mustache templates and code generation doesn't work out of the box, so the original templates where copied to the project and fixed by @Shota and @Pat.
 Current templates and generator contains constraints that were reported by [@Pat](https://docs.google.com/document/d/1WhUtflM_o-5uSx9LW76lycz2kbk071cVZiv6EtVwhAQ/edit#heading=h.ywcvgffenpz) and [@Shota](https://input-output-rnd.slack.com/archives/G018JE9NHAM/p1664563129397819), this requires engineering time to adopt the OAS for a code generation. @Ben says that we can live with these constraints
 
-Generally, OAS files are written by the engineers with different experience and different view on formatting, schemas, normalization, datatype. For instance, in current templates don't have 
+Generally, OAS files are written by the engineers with different experience and different view on formatting, schemas, normalization, datatype. For instance, in current templates don't have
 - a consistent way for paginating the entities
 - standard Responses for 4xx and 5xx errors
 - normalized data types (we use ```anyOf```, ```allOf```)
@@ -57,21 +57,21 @@ Quality and formatting of autogenerated code depend on the template (not all tem
 - reuse endpoint definitions for creating server and client stubs in Scala
 - align the server side of REST API with the current technology stack (ZIO + ecosystem)
 - have a control over the codebase and data types
-- reduce time-of-maintenance of the code (either OAS should be adapted for generator or mustache templates should be fixed) 
+- reduce time-of-maintenance of the code (either OAS should be adapted for generator or mustache templates should be fixed)
 - functional way of implementation of non-functional requirement (metrics, tracing, logging)
 - straight forward generation of Swagger UI, Redoc documentation and Async API documentation based on endpoint definitions
 
 ## Considered Options
 
-- use OpenAPI tools (edit OAS manually, generate server stub for Akka and client stubs for any other languages) 
+- use OpenAPI tools (edit OAS manually, generate server stub for Akka and client stubs for any other languages)
 - use OpenAPI tools, but generate code for other server-side library (Play, Finch, Lagom)
 - use Tapir library (edit endpoint definitions as Scala code, reuse endpoint definitions for server stubs, generate OAS based on endpoint definitions, generate client stubs for any other language)
 
 ## Decision Outcome
 
 Chosen option:"use Tapir library" till the end of the year, evaluate this solution in 2023
 
-All endpoint definition are written in Tapir DSL. 
+All endpoint definition are written in Tapir DSL.
 
 OpenAPI specification generated based on endpoint definition and is published as an artefact. (must be a part of CI)
 

docs/decisions/20221006-store-private-keys-of-issuers-inside-prism-agent.md

@@ -1,30 +1,30 @@
-# Store private keys of Issuers inside prism-agent
+# Store private keys of Issuers inside the cloud-agent
 
 - Status: accepted
 - Deciders: Benjamin Voiturier, Pat Losoponkul, Miloš Džepina, Shailesh Patil, Shota Jolbordi, Bart Suichies, Ezequiel Postan, Yurii Shynbuiev, David Poltorak
 - Date: 2022-10-05
 
 ## Context and Problem Statement
 
-While each holder has a wallet application on the phone (edge agent) to store private keys, contacts, and credentials, PRISM 2.0 will provide a custodial solution to Issuers and Verifiers. Thus they won't have their wallets or store/manage keys. There needs to be storage for the private keys of issuers and Verifiers on the PRISM side.
+While each holder has a wallet application on the phone (edge agent) to store private keys, contacts, and credentials, Identus Cloud Agent will provide a custodial solution to Issuers and Verifiers. Thus they won't have their wallets or store/manage keys. There needs to be storage for the private keys of Issuers and Verifiers on the Cloud Agent side.
 
 
 ## Considered Options
 
-- Having issuers store and manage their own keys on the edge wallet (prism 1.4 approach)
-- Storing keys in a dedicated wallet application that is connected to prism-agent (cloud agent)
-- Having prism-agent store and manage keys directly 
+- Having issuers store and manage their own keys on the edge wallet (Prism 1.4 approach)
+- Storing keys in a dedicated wallet application that is connected to cloud agent
+- Having cloud agent store and manage keys directly
 
 
 ## Decision Outcome
 
-Chosen option: Option 3, because it is the simplest approach that satisfies the needs of providing the Issuer and Verifier with key storage while also not requiring them to manage their own keys. Option 3 was chosen instead of Option 2 because it achieves the same goal but does not require work on integrating another wallet application, so in short, it is simpler and faster to implement.     
+Chosen option: Option 3, because it is the simplest approach that satisfies the needs of providing the Issuer and Verifier with key storage while also not requiring them to manage their own keys. Option 3 was chosen instead of Option 2 because it achieves the same goal but does not require work on integrating another wallet application, so in short, it is simpler and faster to implement.
 
 ### Negative Consequences <!-- optional -->
 
-While Option 3 is simpler to implement then Option 2 and provides basic functionality required to solve the problem emphasized in [ Context and Problem Statement](#context-and-problem-statement), it does not provide full functionality and security of widely used and well tested wallet application. Therefore this decision is considered to be temporary and made only in the interest of solving the problem as fast as possible. 
+While Option 3 is simpler to implement then Option 2 and provides basic functionality required to solve the problem emphasized in [Context and Problem Statement](#context-and-problem-statement), it does not provide full functionality and security of widely used and well tested wallet application. Therefore this decision is considered to be temporary and made only in the interest of solving the problem as fast as possible.
 
 
 ## Links
 
-- [Recording of the meeting where decision was made](https://drive.google.com/file/d/120YyW2IEpl-F-6kF0V0Fau4bM7BbQ6mT/view?usp=sharing) 
+- [Recording of the meeting where decision was made](https://drive.google.com/file/d/120YyW2IEpl-F-6kF0V0Fau4bM7BbQ6mT/view?usp=sharing)

docs/decisions/20230118-quill-library-for-sql-statement-generation.md

@@ -1,15 +1,15 @@
 # Quill library for SQL statement generation and validation
 
 - Status: accepted
-- Deciders: Yurii Shynbuiev, Fabio Pinheiro, Benjamin Voiturier 
-- Date: [2023-01-17] 
+- Deciders: Yurii Shynbuiev, Fabio Pinheiro, Benjamin Voiturier
+- Date: [2023-01-17]
 - Tags: DAL, SQL, Postrgresql, Typesafe
 
 ## Context and Problem Statement
 
-PostgreSQL is essential to the Atala PRISM technology stack, where most entities are stored.
+PostgreSQL is essential to the Identus platform technology stack, where most entities are stored.
 
-Backend services: PRISM Agent, PRISM Mediator, and PRISM Node use PostgreSQL.
+Backend services: Identus Cloud Agent, Identus Mediator, and PRISM Node use PostgreSQL.
 
 [Doobie](https://tpolecat.github.io/doobie/index.html) library is currently used in Scala code to communicate with Postgresql. Quotes from the website
 
@@ -37,7 +37,7 @@ Quill provides a Quoted Domain Specific Language (QDSL) to express queries in Sc
 4. Compile-time query validation: If configured, the query is verified against the database at compile time, and the compilation fails if it is not valid. The query validation does not alter the database state.
 ```
 
-There are [Slick](https://scala-slick.org/) and [ScalikeJDBC](http://scalikejdbc.org/) libraries as well. 
+There are [Slick](https://scala-slick.org/) and [ScalikeJDBC](http://scalikejdbc.org/) libraries as well.
 
 Comparison of these libraries is not a goal of this ADR, but it's essential to know the differences.
 
@@ -164,7 +164,7 @@ val q = TableQuery[Person].filter(_.id === 1)
 val result: Future[Seq[Person]] = db.run(q.result)
 ```
 
-#### Two more real example of Doobie and Quill usage are in the [Links](#links) section.
+#### Two more real example of Doobie and Quill usage are in the [Links](#links) section
 
 ## Links
 
@@ -175,5 +175,5 @@ val result: Future[Seq[Person]] = db.run(q.result)
 - [Database access libraries in Scala](https://medium.com/@takezoe/database-access-libraries-in-scala-7aa7590aa3db)
 - [Typechecking SQL queries with doobie](https://godatadriven.com/blog/typechecking-sql-queries-with-doobie/)
 - [Typechecking SQL in Slick and doobie](https://underscore.io/blog/posts/2015/05/28/typechecking-sql.html)
-- [Doobie example in the Pollux library](https://github.com/input-output-hk/atala-prism-building-blocks/blob/pollux-v0.17.0/pollux/lib/sql-doobie/src/main/scala/io/iohk/atala/pollux/sql/repository/JdbcCredentialRepository.scala)
-- [Quill example in the Pollux library](https://github.com/input-output-hk/atala-prism-building-blocks/blob/pollux-v0.17.0/pollux/lib/sql-doobie/src/main/scala/io/iohk/atala/pollux/sql/model/VerifiableCredentialSchema.scala)
+- [Doobie example in the Pollux library](https://github.com/hyperledger/identus-cloud-agent/blob/pollux-v0.17.0/pollux/lib/sql-doobie/src/main/scala/io/iohk/atala/pollux/sql/repository/JdbcCredentialRepository.scala)
+- [Quill example in the Pollux library](https://github.com/hyperledger/identus-cloud-agent/blob/pollux-v0.17.0/pollux/lib/sql-doobie/src/main/scala/io/iohk/atala/pollux/sql/model/VerifiableCredentialSchema.scala)