Documentation Index
Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt
Use this file to discover all available pages before exploring further.
1. Document Overview
1.1 Purpose
This document describes the network communication architecture and data security policies for the Liveform service provided by ARGOS Identity. It is intended for use by security and network review personnel at customer organizations.
1.2 Target Audience
- Information security and security review personnel at customer organizations
- Personnel conducting due diligence on behalf of the data controller in a data processing relationship
- Compliance / audit departments
1.3 Scope
- End-to-end communication path for the Liveform service
- Encryption in transit and at rest
- Authentication and authorization mechanisms
- Access control / auditing / compliance
This document uses standardized security terminology and industry-standard protocol names, and does not include specific internal resource identifiers used within ARGOS Identity (server names, function names, domains, etc.).
2. Service Category Introduction
Liveform is one of the four categories offered by ARGOS Identity, providing an end-to-end identity verification service that includes a user interface (UI).
2.1 Key Features
- Ready-to-use screens for customers who do not want to build their own UI
- All verifications performed within a single workflow
- Customers can enable or disable individual verification items from the management dashboard
2.2 Participant Structure
| Role | Description |
|---|
| End User | The customer’s user. Submits ID images, selfies, and personal information via the Liveform UI |
| Customer | The business that entrusts KYC processing to ARGOS (data controller in the data processing relationship) |
| ARGOS Identity | The data processor responsible for KYC processing and result delivery |
3. Network Communication Flow
3.1 End-to-End Communication Path (Conceptual)
3.2 Communication Stages
| Stage | From | To | Protocol |
|---|
| ① UI Loading | End User browser | ARGOS CDN / Web | HTTPS (TLS) |
| ② KYC Data Submission | End User browser | ARGOS API Gateway | HTTPS (TLS) + additional application-layer encryption |
| ③ Verification Processing | API Gateway | Serverless computing (Lambda) | AWS internal (inter-service encryption) |
| ④ Data Storage | Verification processing layer | DynamoDB / S3 | AWS SDK (HTTPS, SigV4) |
| ⑤ Result Notification | Verification processing layer | Customer Webhook endpoint | HTTPS (TLS 1.2+) |
| ⑥ Real-time Progress | Processing layer | End User browser | WSS (Secure WebSocket) |
3.3 Data Types
| Data Category | Examples | Handling |
|---|
| ID document images | Passport, driver’s license, etc. | Stored with KMS encryption in object storage |
| Facial images | Selfies, liveness video | Same as above |
| Identifying information | Name, date of birth, ID number | Sensitive fields additionally encrypted at the application layer before DB storage |
| Behavioral logs | Verification results, status changes | Stored separately in an audit trail |
4. Communication Protocols and Standards
4.1 Transport Layer Security
- TLS 1.2 or higher enforced (all external entry points are HTTPS only)
- Certificates issued by AWS Certificate Manager (ACM) are used (auto-renewal)
- TLS termination at external entry points is handled by AWS CloudFront / API Gateway
4.2 Protocols Used
| Protocol | Purpose |
|---|
| HTTPS (TLS 1.2+) | All external HTTP communications |
| WSS (Secure WebSocket) | Real-time channel between UI ↔ backend |
| AWS SigV4 | Authentication signature for AWS internal service calls |
4.3 External Entry Point Policy
- External entry points are limited exclusively to AWS API Gateway + AWS CloudFront
- The verification processing layer is not directly reachable from outside (internal AWS calls only)
5. Data Encryption
5.1 Encryption in Transit (In-Transit)
| Segment | Method |
|---|
| End User ↔ Liveform UI | TLS 1.2+ |
| Liveform UI ↔ API Gateway | TLS 1.2+ |
| Application payload (sensitive fields) | Hybrid encryption (see 5.2) |
| Between AWS services | AWS internal encryption |
5.2 Application-Layer Payload Encryption (Hybrid Scheme)
Payloads transmitted from the End User to the verification processing layer receive additional encryption on top of TLS.
| Component | Algorithm / Specification |
|---|
| Session key exchange | RSA-2048 + OAEP padding + SHA-256 |
| Body encryption | AES-256-GCM |
| Integrity assurance | Auth Tag verification built into GCM mode |
- The client generates a one-time AES-256 session key
- The session key is encrypted with the server’s public key (RSA-2048) and transmitted
- The body is encrypted with the session key using AES-256-GCM
- The server decrypts the session key using the RSA private key → decrypts the body + verifies the Auth Tag
5.3 Encryption at Rest (At-Rest)
| Data Asset | Primary Encryption | Secondary Encryption (optional strengthening) |
|---|
| ID document and selfie images (object storage) | AWS S3 server-side encryption | AWS KMS |
| Identifying and personal information (DB) | DynamoDB server-side encryption | Sensitive fields: AES-256 + AWS KMS |
| Audit logs | DynamoDB server-side encryption | — |
5.4 Key Management
- Based on AWS Key Management Service (KMS)
- Multi-Region Keys used for consistent key management across regions
- AWS KMS is based on FIPS 140-2 Level 3 certified HSM (Hardware Security Module)
6. Authentication and Authorization
6.1 API Gateway Stage — Primary Authentication
All external inbound calls must pass API Key validation as defined by AWS API Gateway before reaching the verification processing layer.
- Per-project unique API Key: ARGOS issues separate keys for each customer project
- Header validation: API Gateway automatically validates the value of the request header (
x-api-key)
- Missing or mismatched: Immediately rejected at the API Gateway stage (does not reach the verification processing layer)
6.2 Optional — IP Allowlist (Custom Authorizer)
- Source IP allowlists can be configured per project
- AWS Lambda Authorizer compares the client IP against the allowlist
- On mismatch, an IAM Deny Policy is returned → rejected by API Gateway
6.3 Special Flow — Private Token
- One-time tokens (Private Token) are issued and validated in special flows such as ID re-verification and facial re-authentication
- 8–64 characters combining alphanumeric characters and
_.
- Stored in DynamoDB; expiry time and revocation status are validated
- JWT (JSON Web Token) HMAC-SHA256 signature applied
6.4 Bot / Automation Blocking
- Cloudflare Turnstile CAPTCHA applied
- Tokens are signed with JWT (HMAC-SHA256) and verified server-side
6.5 Internal Calls
- Calls between AWS internal services are based on IAM Role + SigV4 signing
- Least privilege principle applied (each service holds access rights only to the resources it requires)
7. Integrity and Tamper Prevention
| Segment | Integrity Assurance Method |
|---|
| Payload body | Auth Tag verification in AES-256-GCM mode |
| TLS channel | TLS 1.2+ built-in integrity (HMAC / AEAD) |
| ID document images | MRZ (Machine Readable Zone) checksum verification + tamper detection algorithm |
| Input data | Format and range validation (email, gender, date of birth, etc.) |
| Internal calls | Request digest included in AWS SigV4 signature |
8. Access Control and Isolation
8.1 Network Layer Isolation
- External entry is limited to API Gateway / CloudFront
- The verification processing layer is not directly reachable from outside
- The data storage layer is accessible only through AWS SDK + IAM Role
8.2 Privilege Separation
- AWS IAM least privilege principle: each service execution role (Role) is granted only the minimum permissions required
- Direct calls between services are restricted by IAM Policy
9. Logging and Auditing
9.1 System Logs
- Execution logs for all serverless functions are automatically collected in AWS CloudWatch Logs
- AWS API calls are automatically audited via AWS CloudTrail
9.2 Application Logs
- Per-stage verification events are recorded in a separate audit table (status changes, verification results, administrator actions, etc.)
9.3 Retention
- Retention periods for CloudWatch Logs / application audit logs are defined separately according to compliance requirements
10. Compliance
10.1 Held Certifications
- ISO/IEC 27001 — International standard certification for information security management systems
10.2 Cloud Infrastructure Certifications (AWS Inherited)
AWS services used by ARGOS (Lambda, API Gateway, DynamoDB, S3, KMS, CloudFront) hold the following certifications:
- SOC 1 / SOC 2 / SOC 3
- ISO 27001 / 27017 / 27018
- PCI-DSS Level 1
- HIPAA Eligible
- FedRAMP Moderate
10.3 Data Subject Rights
- Procedures in place to respond to requests (access, rectification, erasure, portability) under applicable privacy laws / GDPR
- Subject to a separate processing agreement between the data controller and processor
Appendix A. Glossary
| Term | Definition |
|---|
| TLS | Transport Layer Security — transport-layer encryption protocol |
| AES-256-GCM | 256-bit AES symmetric key + Galois/Counter Mode (authenticated encryption) |
| RSA-2048 | 2048-bit RSA public-key algorithm |
| OAEP | Optimal Asymmetric Encryption Padding (standard RSA padding) |
| KMS | AWS Key Management Service (FIPS 140-2 Level 3 HSM-based) |
| SigV4 | AWS Signature Version 4 (standard for signing AWS API calls) |
| IAM | AWS Identity and Access Management |
| HMAC | Hash-based Message Authentication Code |
| JWT | JSON Web Token |
For technical inquiries regarding this document, please contact ARGOS Identity through the sales or technical support channel.
