[coepi-backend-aws]: Implement unified back-end supporting TCN Reports and Apple/Google keys

[ramnanib2]

Reference Doc

https://docs.google.com/document/d/1l6ajoKs4En_STtaROlZdHtWI9VZE6c5HLpmBwEqWcXo/edit#

Development Branch

https://github.com/Co-Epi/coepi-backend-aws/tree/unified_backend

API Definition

https://github.com/Co-Epi/coepi-backend-aws/blob/unified_backend/api_definition/coepi_api_0.5.0.yml

Apple/Google Diagnosis Server Reference Implementation:

https://github.com/bhushanRamnani/apple-google-diagnosis-server-aws

Tasks:

1. Implement TCN endpoint with lambda front-end
2. Implement TCN endpoint with ktor front-end
3. Add report and signature validation to TCN endpoint ([coepi-backend-aws][v4]: Do report signature validation on the server side before persisting the data #9)
4. Implement Apple/Google endpoint with lambda front-end
5. Implement Apple / Google endpoint with ktor front-end

[jmccance]

Are we keeping the old /v4/tcnreport endpoints, or can those go away?

[jmccance]

Given that we're introducing a new report type that seems to be handled completely separately from TCN reports, I'd propose we reorganize the packages in core:

• org.coepi.api.tcn.* - Core code for TCN reports
• org.coepi.api.agen.* - Core code for "Apple/Google Exposure Notification" reports. (I am very open to suggestions for a better name than agen.)

[ramnanib2]

Are we keeping the old /v4/tcnreport endpoints, or can those go away?

Yes, we'll be moving to new format

[ramnanib2]

Given that we're introducing a new report type that seems to be handled completely separately from TCN reports, I'd propose we reorganize the packages in core:

• org.coepi.api.tcn.* - Core code for TCN reports
• org.coepi.api.agen.* - Core code for "Apple/Google Exposure Notification" reports. (I am very open to suggestions for a better name than agen.)

agen seems fine. Instead of organizing protocols under packages, I was thinking we could just have a separate package name where we keep the service classes since dao and frontends are gonna be common. We could use either abstract method design pattern or strategy design pattern to pull out share common functionality between the services.

Common Functionality:

1. Parse Query parameters intervalNumber and intervalLength for get
2. Is-It-Human verification for get and post
3. Error translation to Http response

Service specific functionality:

1. Validating report/key data on post
2. Signature verification where required during post
3. Query records from DDB and translate to response body