Webhook - ARGOS Identity

1. Document Overview

1.1 Purpose

This document describes the network communication architecture and security policies for the channel through which ARGOS Identity delivers verification results to customers via Webhook (callback).

1.2 Target Audience

Information security and security review personnel at customer organizations
Development teams building and operating Webhook receiving endpoints
Compliance / audit departments

1.3 Scope

Webhook dispatch communication from ARGOS → customer
Communication protocol, TLS, payload encryption
Authentication, integrity, retry, and auditing

2. Service Category Introduction

Webhook is the channel through which ARGOS delivers KYC processing results (approved / rejected / re-requested, etc.) to customers asynchronously.

2.1 Features

Event-driven: dispatched immediately when a result is produced (no polling required)
HTTPS compliant: customers can receive events with a standard HTTP server without installing a separate SDK
Two-stage pipeline structure:
1. Event convergence layer (serverless): determines dispatch targets + constructs the body
2. Dispatch execution layer (dedicated dispatch server): executes HTTPS POST to the customer endpoint

2.2 Dispatch Triggers

Event	Dispatch Timing
Verification completed	Immediately after a result is finalized via Liveform / Restful API
Verification status changed	When a re-verification or supplemental request occurs
Administrator action	When a manual approval/rejection action occurs in the dashboard

3. Network Communication Flow

3.1 Full Flow

3.2 Outbound Dispatch Channel

Item	Value
Direction	ARGOS → Customer (Outbound from ARGOS)
Protocol	HTTPS (TLS 1.2 or higher enforced)
HTTP Method	POST (may vary based on customer configuration)
Content-Type	`application/json` (default) / `text/plain` (when encryption option is enabled)
Certificate validation	ARGOS validates the customer’s certificate (`rejectUnauthorized` enabled)

4. Communication Protocols and Standards

4.1 Transport Layer

TLS 1.2 or higher (explicitly enforced in the HTTPS Agent: secureProtocol: TLSv1_2_method)
The customer server’s certificate is validated against the standard PKI trust chain (Root CA)
Self-signed certificates are not supported without prior arrangement

4.2 Request Headers

Header	Value / Description
`Content-Type`	`application/json` (default), `text/plain` (when encryption is applied)
`User-Agent`	ARGOS internal identifier (e.g., `Argos-kyc-webhook`)
`X-Webhook-Encrypted`	`true` / `false` — signals whether body encryption is applied

4.3 Request Body (JSON, plain-text mode)

{
  "projectId": "<project identifier>",
  "submissionId": "<submission identifier>",
  "userId": "<optional>",
  "status": "approved | rejected | incomplete",
  "timestamp": "<dispatch timestamp>",
  "webhookParams": { ... }
}

The body structure may vary partially depending on project options and the type of dispatch event. For the detailed specification, refer to the separate API documentation.

5. Data Encryption

5.1 Encryption in Transit (Required)

TLS 1.2 or higher enforced (HTTPS only)
Plain HTTP dispatch is not supported

5.2 Payload Encryption (Optional, per-project activation)

Customers who want additional security can apply encryption on top of TLS to the body.

Item	Value
Activation	Enable the `Data Encryption` project option
Algorithm	AES-256 (symmetric key encryption)
Key derivation	Per-project API Key-based key derivation
Signal header	`X-Webhook-Encrypted: true`
Content-Type	`text/plain` (Base64-encoded ciphertext transmitted)

Decryption procedure (customer side):

Check the X-Webhook-Encrypted header
Obtain the body (Base64 decode → ciphertext)
Derive the key using the project API Key as a seed
AES-256 decryption → JSON parsing

6. Authentication and Authorization

6.1 Customer-Side Sender Verification Options

Method	Description
TLS certificate + sender domain verification	The customer verifies the origin via the TLS certificate of the ARGOS dispatch domain
IP allowlist (recommended)	Only the fixed IP range of the ARGOS dispatch server is permitted to deliver events (customer firewall configuration)
Encryption mode header	Source confirmed by verifying `X-Webhook-Encrypted: true` and ability to decrypt
Customer-registered authentication header	By arrangement, ARGOS can include a customer-specified authentication header (e.g., Bearer token) in the dispatch

Customers requiring strong sender verification are recommended to use the combination of IP allowlist + payload encryption mode.

6.2 ARGOS Internal Authentication

Verification layer → Webhook convergence layer: AWS internal call (IAM Role + SigV4)
Webhook convergence layer → Dispatch execution layer: AWS network call

7. Integrity and Tamper Prevention

Segment	Integrity Assurance Method
TLS channel	TLS 1.2+ built-in integrity (AEAD / HMAC)
Payload (encryption mode)	AES-256 + successful decryption = source verification
TCP transport	TCP checksum + TLS end-to-end integrity
Dispatch log	Append-only audit table entries (immutable)

8. Access Control and Isolation

8.1 Dispatch Target Isolation

Customer Webhook URLs are registered and isolated per project
Explicit registration procedure requiring administrator authentication when the URL is changed

8.2 Dispatch Server Isolation

The ARGOS Webhook dispatch server operates within AWS exclusively for result notification
Direct inbound requests to this server from outside are not possible
Dispatch targets are limited to customer-registered URLs only

8.3 Environment Separation

Live / Test environment dispatch channels are separated
Test results are dispatched only to the registered URL in the test environment

9. Logging and Auditing

9.1 Per-Dispatch Log

Every Webhook dispatch attempt is recorded in the audit table with the following information:

Item	Description
Dispatch identifier	Unique ID for the individual dispatch
Project identifier	Project ID
Dispatch timestamp	UTC timestamp
Target URL	Customer-registered endpoint
HTTP response code	200 / 4xx / 5xx
Response body	Customer response
Status	SUCCESS / FAIL / ERROR

9.2 Daily Aggregate Metrics

Daily counts of successes, failures, and errors are aggregated in a separate metrics table.

9.3 Retry Policy

Stage	Policy
First attempt	Dispatched immediately
Retry	Up to 3 times (exponential backoff)
DLQ / Manual Replay	Failed dispatches can be manually re-sent using a separate tool

9.4 Retention

Retention period for dispatch audit logs is defined separately according to compliance requirements

10. Compliance

10.1 ARGOS Identity Held Certifications

ISO/IEC 27001 — International standard certification for information security management systems

10.2 AWS Infrastructure Certifications (Inherited)

The Webhook dispatch infrastructure (AWS Lambda, EC2, DynamoDB, etc.) inherits the following AWS certifications:

SOC 1 / SOC 2 / SOC 3
ISO 27001 / 27017 / 27018
PCI-DSS Level 1
HIPAA Eligible
FedRAMP Moderate

10.3 Data Processing Agreement

Information entrusted by customers to ARGOS for KYC processing is not used for any purpose other than the result notification (Webhook) after processing is complete.
The policy for cleaning up dispatch audit logs after notification is subject to a separate processing agreement.

Appendix A. Glossary

Term	Definition
Webhook	An asynchronous callback method that notifies results via HTTPS POST when an event occurs
TLS	Transport Layer Security
AES-256	256-bit Advanced Encryption Standard
DLQ	Dead Letter Queue (separate channel for retaining failed messages)
Exponential Backoff	A method of progressively increasing the interval between retries
Base64	Binary-to-text-safe encoding
IP allowlist	A policy that restricts receiving/sending to only permitted IP addresses

Appendix B. Recommended Integration Guide

When customers build ARGOS Webhook receiving endpoints, the following practices are recommended:

Use HTTPS-only endpoints (Let’s Encrypt / commercial certificate)
Allow only the ARGOS dispatch IP range (firewall/security group configuration)
Enable X-Webhook-Encrypted: true mode (activate Data Encryption in project options)
Respond with 200 OK immediately upon receipt, then process asynchronously (delays over 3 seconds may trigger a retry)
Idempotency handling: ensure safe processing even when the same submissionId is received more than once

Appendix C. Contact

For technical inquiries regarding this document, please contact ARGOS Identity through the sales or technical support channel.

​1. Document Overview

​1.1 Purpose

​1.2 Target Audience

​1.3 Scope

​2. Service Category Introduction

​2.1 Features

​2.2 Dispatch Triggers

​3. Network Communication Flow

​3.1 Full Flow

​3.2 Outbound Dispatch Channel

​4. Communication Protocols and Standards

​4.1 Transport Layer

​4.2 Request Headers

​4.3 Request Body (JSON, plain-text mode)

​5. Data Encryption

​5.1 Encryption in Transit (Required)

​5.2 Payload Encryption (Optional, per-project activation)

​6. Authentication and Authorization

​6.1 Customer-Side Sender Verification Options

​6.2 ARGOS Internal Authentication

​7. Integrity and Tamper Prevention

​8. Access Control and Isolation

​8.1 Dispatch Target Isolation

​8.2 Dispatch Server Isolation

​8.3 Environment Separation

​9. Logging and Auditing

​9.1 Per-Dispatch Log

​9.2 Daily Aggregate Metrics

​9.3 Retry Policy

​9.4 Retention

​10. Compliance

​10.1 ARGOS Identity Held Certifications

​10.2 AWS Infrastructure Certifications (Inherited)

​10.3 Data Processing Agreement

​Appendix A. Glossary

​Appendix B. Recommended Integration Guide

​Appendix C. Contact

1. Document Overview

1.1 Purpose

1.2 Target Audience

1.3 Scope

2. Service Category Introduction

2.1 Features

2.2 Dispatch Triggers

3. Network Communication Flow

3.1 Full Flow

3.2 Outbound Dispatch Channel

4. Communication Protocols and Standards

4.1 Transport Layer

4.2 Request Headers

4.3 Request Body (JSON, plain-text mode)

5. Data Encryption

5.1 Encryption in Transit (Required)

5.2 Payload Encryption (Optional, per-project activation)

6. Authentication and Authorization

6.1 Customer-Side Sender Verification Options

6.2 ARGOS Internal Authentication

7. Integrity and Tamper Prevention

8. Access Control and Isolation

8.1 Dispatch Target Isolation

8.2 Dispatch Server Isolation

8.3 Environment Separation

9. Logging and Auditing

9.1 Per-Dispatch Log

9.2 Daily Aggregate Metrics

9.3 Retry Policy

9.4 Retention

10. Compliance

10.1 ARGOS Identity Held Certifications

10.2 AWS Infrastructure Certifications (Inherited)

10.3 Data Processing Agreement

Appendix A. Glossary

Appendix B. Recommended Integration Guide

Appendix C. Contact