{
"info": {
"name": "ANKASecure API – Enterprise Post-Quantum Cryptography",
"description": {
"content": "Enterprise-grade quantum-resistant cryptography API with hybrid classical+PQC encryption, zero-copy streaming for large files, and NIST-compliant algorithms.\n\n✓ Hybrid cryptography (X25519+ML-KEM) for crypto-agility\n✓ Streaming operations for multi-GB files without buffering\n✓ NIST FIPS 203/204 compliant (ML-KEM, ML-DSA)\n✓ Multi-tenant key isolation with complete lifecycle management\n✓ Interoperability with external PKI systems\n\nAlgorithms: AES · RSA · ECC · ML-KEM · ML-DSA · Falcon · SLH-DSA\n",
"type": "text/markdown"
},
"version": "3.0.0",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
},
"item": [
{
"name": " Algorithm Catalog",
"description": "Catalog of supported cryptographic algorithms for crypto-agility decisions.",
"item": [
{
"name": "/api/v3/key-management/supported-algorithms",
"description": "Returns the algorithm catalogue with full metadata for crypto-agility decisions. Supports optional server-side filtering via query parameters. ## Query Parameters (all optional) | Parameter | Type | Logic | Description | |-----------|------|-------|-------------| | `category` | string | = | CLASSICAL, POST_QUANTUM, or HYBRID | | `status` | string | = | RECOMMENDED, EXPERIMENTAL, or LEGACY | | `minSecurityLevel` | int | >= | Minimum NIST level (1, 3, 5) | | `maxSecurityLevel` | int | <= | Maximum NIST level (1, 3, 5) | | `keyOps` | array | AND | Required operations (must support ALL) | | `standards` | array | AND | Required standards (must have ALL) | | `kty` | array | OR | Key types (matches ANY, including COMPOSITE) | | `alg` | array | OR | Algorithms (matches ANY) | ## Response fields | Field | Type | Description | |-------|------|-------------| | `kty` | string | Key type: ML-KEM, ML-DSA, RSA, EC, oct (simple) or COMPOSITE_KEM_COMBINE, COMPOSITE_SIGNATURE (composite) | | `alg` | string | Algorithm identifier: ML-KEM-768, RSA-4096 (simple) or X25519+ML-KEM-768 (composite) | | `keyOps` | array | Permitted operations: encrypt, decrypt, sign, verify | | `status` | string | RECOMMENDED, EXPERIMENTAL, or LEGACY | | `sunsetDate` | date | Planned deprecation date (ISO 8601, optional) | | `advisory` | string | Migration or security guidance (optional) | | `securityLevel` | integer | NIST security level (1-5) | | `standards` | array | Endorsing standards, from the single platform vocabulary: ANSSI, BSI, CRYPTREC, ENISA, ETSI, GMT, GOST, IETF, ISO, KISA, MYSEAL, NCA_NCS, NIST, NSA | | `category` | string | CLASSICAL, POST_QUANTUM, or HYBRID | ## Composite algorithm entries Composite algorithms appear as first-class entries with: - `category: \"HYBRID\"` - `kty`: The composite mode (COMPOSITE_KEM_COMBINE or COMPOSITE_SIGNATURE) - `alg`: Combined identifier (e.g., \"X25519+ML-KEM-768\", \"Ed25519+ML-DSA-65\") Use `category=HYBRID` to filter composite entries only. ## Example queries ``` # Post-quantum algorithms only GET /api/key-management/supported-algorithms?category=POST_QUANTUM # Hybrid/composite algorithms only GET /api/key-management/supported-algorithms?category=HYBRID # High security, recommended algorithms GET /api/key-management/supported-algorithms?minSecurityLevel=3&status=RECOMMENDED # Signature algorithms with NIST compliance GET /api/key-management/supported-algorithms?keyOps=sign,verify&standards=NIST # Find specific composite algorithm GET /api/key-management/supported-algorithms?alg=X25519+ML-KEM-768 ``` ",
"item": [
{
"name": "Get supported algorithms (crypto-agility)",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/key-management/supported-algorithms",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"key-management",
"supported-algorithms"
],
"variable": [
],
"query": [
{
"key": "category",
"value": "category_example",
"description": "Filter by category: CLASSICAL, POST_QUANTUM, or HYBRID",
"disabled": true
},
{
"key": "status",
"value": "status_example",
"description": "Filter by status: RECOMMENDED, EXPERIMENTAL, or LEGACY",
"disabled": true
},
{
"key": "minSecurityLevel",
"value": "56",
"description": "Minimum NIST security level (1, 3, or 5)",
"disabled": true
},
{
"key": "maxSecurityLevel",
"value": "56",
"description": "Maximum NIST security level (1, 3, or 5)",
"disabled": true
},
{
"key": "keyOps",
"value": "",
"description": "Required operations (comma-separated). Must support ALL specified.",
"disabled": true
},
{
"key": "standards",
"value": "",
"description": "Required standards (comma-separated). Must have ALL specified.",
"disabled": true
},
{
"key": "kty",
"value": "",
"description": "Key types (comma-separated, OR logic). Matches ANY specified. Use COMPOSITE for hybrid algorithms.",
"disabled": true
},
{
"key": "alg",
"value": "",
"description": "Algorithms (comma-separated, OR logic). Matches ANY specified.",
"disabled": true
}
]
},
"description": "Returns the algorithm catalogue with full metadata for crypto-agility decisions. Supports optional server-side filtering via query parameters. ## Query Parameters (all optional) | Parameter | Type | Logic | Description | |-----------|------|-------|-------------| | `category` | string | = | CLASSICAL, POST_QUANTUM, or HYBRID | | `status` | string | = | RECOMMENDED, EXPERIMENTAL, or LEGACY | | `minSecurityLevel` | int | >= | Minimum NIST level (1, 3, 5) | | `maxSecurityLevel` | int | <= | Maximum NIST level (1, 3, 5) | | `keyOps` | array | AND | Required operations (must support ALL) | | `standards` | array | AND | Required standards (must have ALL) | | `kty` | array | OR | Key types (matches ANY, including COMPOSITE) | | `alg` | array | OR | Algorithms (matches ANY) | ## Response fields | Field | Type | Description | |-------|------|-------------| | `kty` | string | Key type: ML-KEM, ML-DSA, RSA, EC, oct (simple) or COMPOSITE_KEM_COMBINE, COMPOSITE_SIGNATURE (composite) | | `alg` | string | Algorithm identifier: ML-KEM-768, RSA-4096 (simple) or X25519+ML-KEM-768 (composite) | | `keyOps` | array | Permitted operations: encrypt, decrypt, sign, verify | | `status` | string | RECOMMENDED, EXPERIMENTAL, or LEGACY | | `sunsetDate` | date | Planned deprecation date (ISO 8601, optional) | | `advisory` | string | Migration or security guidance (optional) | | `securityLevel` | integer | NIST security level (1-5) | | `standards` | array | Endorsing standards, from the single platform vocabulary: ANSSI, BSI, CRYPTREC, ENISA, ETSI, GMT, GOST, IETF, ISO, KISA, MYSEAL, NCA_NCS, NIST, NSA | | `category` | string | CLASSICAL, POST_QUANTUM, or HYBRID | ## Composite algorithm entries Composite algorithms appear as first-class entries with: - `category: \"HYBRID\"` - `kty`: The composite mode (COMPOSITE_KEM_COMBINE or COMPOSITE_SIGNATURE) - `alg`: Combined identifier (e.g., \"X25519+ML-KEM-768\", \"Ed25519+ML-DSA-65\") Use `category=HYBRID` to filter composite entries only. ## Example queries ``` # Post-quantum algorithms only GET /api/key-management/supported-algorithms?category=POST_QUANTUM # Hybrid/composite algorithms only GET /api/key-management/supported-algorithms?category=HYBRID # High security, recommended algorithms GET /api/key-management/supported-algorithms?minSecurityLevel=3&status=RECOMMENDED # Signature algorithms with NIST compliance GET /api/key-management/supported-algorithms?keyOps=sign,verify&standards=NIST # Find specific composite algorithm GET /api/key-management/supported-algorithms?alg=X25519+ML-KEM-768 ``` "
}
,"response": [
]
}
]
}
]
},
{
"name": " Secure Streaming",
"description": "Endpoints to manage fully streaming-based cryptographic operations\nwith symmetric and post-quantum/classical asymmetric keys (AES, RSA, ECC, ML-1024,\nML-DSA, Falcon, etc.).\n",
"item": [
{
"name": "/api/v3/crypto/stream/decrypt",
"description": "The request is multipart/mixed with two parts: application/jose+json — JWE General-JSON header (detached ciphertext).application/octet-stream — proprietary binary envelope followed by the ciphertext and GCM tag.
The response is multipart/mixed (PRD §64): PART 1 (application/octet-stream) is the decrypted plaintext and the trailing PART 2 (application/json) is a StreamVerdict emitted AFTER the end-of-stream AES-GCM tag is verified ({verdict,operation,reason,correlationId,timestamp}). Because the GCM tag is only known at end-of-stream, a tamper is reported through an INVALID verdict in PART 2 — never a silently truncated success.
Supports both SIMPLE keys (single recipient) and COMPOSITE keys (multiple recipients). For COMPOSITE keys, decryption uses all recipients to derive the final content encryption key. ",
"item": [
{
"name": "Decrypt data (streaming).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/decrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"decrypt"
],
"variable": [
],
"query": [
]
},
"description": "The request is multipart/mixed with two parts: application/jose+json — JWE General-JSON header (detached ciphertext).application/octet-stream — proprietary binary envelope followed by the ciphertext and GCM tag.
The response is multipart/mixed (PRD §64): PART 1 (application/octet-stream) is the decrypted plaintext and the trailing PART 2 (application/json) is a StreamVerdict emitted AFTER the end-of-stream AES-GCM tag is verified ({verdict,operation,reason,correlationId,timestamp}). Because the GCM tag is only known at end-of-stream, a tamper is reported through an INVALID verdict in PART 2 — never a silently truncated success.
Supports both SIMPLE keys (single recipient) and COMPOSITE keys (multiple recipients). For COMPOSITE keys, decryption uses all recipients to derive the final content encryption key. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/decrypt-verify",
"description": "Consumes the nested ciphertext as multipart/mixed (outer JWE header + ciphertext), decrypts it and verifies the recovered inner JWS. The response is multipart/mixed: PART 1 is the decrypted plaintext, PART 2 a JSON verdict carrying gcmTagVerdict and signatureVerdict — both MUST be VALID for the overall verdict to be VALID. ",
"item": [
{
"name": "Decrypt-then-verify data (streaming, two verdicts).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/decrypt-verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"decrypt-verify"
],
"variable": [
],
"query": [
]
},
"description": "Consumes the nested ciphertext as multipart/mixed (outer JWE header + ciphertext), decrypts it and verifies the recovered inner JWS. The response is multipart/mixed: PART 1 is the decrypted plaintext, PART 2 a JSON verdict carrying gcmTagVerdict and signatureVerdict — both MUST be VALID for the overall verdict to be VALID. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/encrypt",
"description": "Consumes two multipart/form-data fields:
1. metadata – JSON body EncryptStreamRequest
2. file – binary plaintext
Produces a multipart/mixed response where:
• Part 1 (application/jose+json) is a JWE General-JSON header with detached ciphertext.
• Part 2 (application/octet-stream) is the proprietary envelope [wkLen]‖wrappedKey‖[ivLen]‖iv‖ciphertext‖tag streamed on-the-fly.
Output format depends on key type:
• SIMPLE keys: JWE General JSON with single recipient
• COMPOSITE keys: JWE General JSON with multiple recipients (one per component) ",
"item": [
{
"name": "Encrypt data (streaming).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/encrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"encrypt"
],
"variable": [
],
"query": [
]
},
"description": "Consumes two multipart/form-data fields:
1. metadata – JSON body EncryptStreamRequest
2. file – binary plaintext
Produces a multipart/mixed response where:
• Part 1 (application/jose+json) is a JWE General-JSON header with detached ciphertext.
• Part 2 (application/octet-stream) is the proprietary envelope [wkLen]‖wrappedKey‖[ivLen]‖iv‖ciphertext‖tag streamed on-the-fly.
Output format depends on key type:
• SIMPLE keys: JWE General JSON with single recipient
• COMPOSITE keys: JWE General JSON with multiple recipients (one per component) "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/reencrypt",
"description": "Decrypts the incoming ciphertext using oldKid (from the JWE header) and re-encrypts it on the fly with newKid (provided via query parameter). Returns a multipart/mixed response (PRD §64): the new JWE header part, the re-encrypted ciphertext part, and a trailing application/json StreamVerdict part emitted AFTER the source AES-GCM tag is verified at end-of-stream (an INVALID verdict signals a tampered source; no committed ciphertext is promotable). All key-selection metadata is returned in the single `Crypto-Policy-Info` response header.
Supports all key type combinations:
• SIMPLE → SIMPLE (single recipient → single recipient)
• SIMPLE → COMPOSITE (single recipient → multiple recipients)
• COMPOSITE → COMPOSITE (multiple recipients → multiple recipients)
• COMPOSITE → SIMPLE (multiple recipients → single recipient) ",
"item": [
{
"name": "Re-encrypt data (streaming).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/reencrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"reencrypt"
],
"variable": [
],
"query": [
{
"key": "newKid",
"value": "newKid_example",
"description": "KID of the key the payload is re-encrypted TO.",
"disabled": false
},
{
"key": "sourceKidOverride",
"value": "sourceKidOverride_example",
"description": "KID of the key the payload is decrypted FROM. Required only for a legacy envelope whose header carries no `kid`; otherwise the header's own `kid` is used.",
"disabled": true
}
]
},
"description": "Decrypts the incoming ciphertext using oldKid (from the JWE header) and re-encrypts it on the fly with newKid (provided via query parameter). Returns a multipart/mixed response (PRD §64): the new JWE header part, the re-encrypted ciphertext part, and a trailing application/json StreamVerdict part emitted AFTER the source AES-GCM tag is verified at end-of-stream (an INVALID verdict signals a tampered source; no committed ciphertext is promotable). All key-selection metadata is returned in the single `Crypto-Policy-Info` response header.
Supports all key type combinations:
• SIMPLE → SIMPLE (single recipient → single recipient)
• SIMPLE → COMPOSITE (single recipient → multiple recipients)
• COMPOSITE → COMPOSITE (multiple recipients → multiple recipients)
• COMPOSITE → SIMPLE (multiple recipients → single recipient) "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/resign",
"description": "Verifies a detached-JWS (oldJws) under oldKid— either the header's kid or sourceKidOverride if the header lacks a kid—and immediately signs the same payload with newKid. The response is multipart/mixed (PRD §64): PART 1 (application/octet-stream) is the new detached-JWS JSON and the trailing PART 2 (application/json) is a StreamVerdict emitted AFTER the source (old) signature is verified — an INVALID verdict signals a source-signature failure discovered at end-of-stream.
Supports all key type combinations:
• SIMPLE → SIMPLE (single signature → single signature)
• SIMPLE → COMPOSITE (single signature → multiple signatures)
• COMPOSITE → COMPOSITE (multiple signatures → multiple signatures)
• COMPOSITE → SIMPLE (multiple signatures → single signature) ",
"item": [
{
"name": "Re-sign data (streaming).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/resign",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"resign"
],
"variable": [
],
"query": [
]
},
"description": "Verifies a detached-JWS (oldJws) under oldKid— either the header's kid or sourceKidOverride if the header lacks a kid—and immediately signs the same payload with newKid. The response is multipart/mixed (PRD §64): PART 1 (application/octet-stream) is the new detached-JWS JSON and the trailing PART 2 (application/json) is a StreamVerdict emitted AFTER the source (old) signature is verified — an INVALID verdict signals a source-signature failure discovered at end-of-stream.
Supports all key type combinations:
• SIMPLE → SIMPLE (single signature → single signature)
• SIMPLE → COMPOSITE (single signature → multiple signatures)
• COMPOSITE → COMPOSITE (multiple signatures → multiple signatures)
• COMPOSITE → SIMPLE (multiple signatures → single signature) "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/sign",
"description": "Consumes two multipart/form-data fields:
1. metadata â€\" JSON body SignStreamRequest
2. file â€\" binary data to sign
Produces a detached-JWS in JSON format streamed as application/octet-stream. Output structure depends on key type:
• SIMPLE keys: Single signature in compact detached format
• COMPOSITE keys: Multiple signatures (classical + PQC) with anka_composite_kid field ",
"item": [
{
"name": "Sign data (streaming).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/sign",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"sign"
],
"variable": [
],
"query": [
]
},
"description": "Consumes two multipart/form-data fields:
1. metadata â€\" JSON body SignStreamRequest
2. file â€\" binary data to sign
Produces a detached-JWS in JSON format streamed as application/octet-stream. Output structure depends on key type:
• SIMPLE keys: Single signature in compact detached format
• COMPOSITE keys: Multiple signatures (classical + PQC) with anka_composite_kid field "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/sign-encrypt",
"description": "Consumes a multipart/form-data request with a JSON SignEncryptStreamRequest metadata part ({signKid, encryptKid, validityDays?}) and a binary file part. The payload is signed with signKid and the resulting compact JWS is encrypted with encryptKid, so the signature is carried encrypted. signKid and encryptKid MUST be different and homogeneous (both symmetric or both asymmetric). The response is the nested ciphertext streamed as multipart/mixed (JWE header + ciphertext). ",
"item": [
{
"name": "Sign-then-encrypt data (streaming, nested JWE(JWS)).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/sign-encrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"sign-encrypt"
],
"variable": [
],
"query": [
]
},
"description": "Consumes a multipart/form-data request with a JSON SignEncryptStreamRequest metadata part ({signKid, encryptKid, validityDays?}) and a binary file part. The payload is signed with signKid and the resulting compact JWS is encrypted with encryptKid, so the signature is carried encrypted. signKid and encryptKid MUST be different and homogeneous (both symmetric or both asymmetric). The response is the nested ciphertext streamed as multipart/mixed (JWE header + ciphertext). "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/stream/verify",
"description": "Two multipart/form-data parts: • metadata – JSON (VerifyDetachedJwsStreamRequest) with a detached-JWS (General-JSON). • file – the binary payload originally signed. Extracts kid and alg from the header, verifies and returns a VerifySignatureResponse.
Supports both SIMPLE keys (compact JWS with single signature) and COMPOSITE keys (General JSON with multiple signatures and anka_composite_kid field). ",
"item": [
{
"name": "Verify a detached-JWS (streaming).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/stream/verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"stream",
"verify"
],
"variable": [
],
"query": [
]
},
"description": "Two multipart/form-data parts: • metadata – JSON (VerifyDetachedJwsStreamRequest) with a detached-JWS (General-JSON). • file – the binary payload originally signed. Extracts kid and alg from the header, verifies and returns a VerifySignatureResponse.
Supports both SIMPLE keys (compact JWS with single signature) and COMPOSITE keys (General JSON with multiple signatures and anka_composite_kid field). "
}
,"response": [
]
}
]
}
]
},
{
"name": " Secure",
"description": "Endpoints to manage and perform cryptographic operations with symmetric\nand post-quantum/classical asymmetric keys (AES, RSA, ECC, ML-KEM, ML-DSA, Falcon, etc.).\n",
"item": [
{
"name": "/api/v3/crypto/decrypt",
"description": "Parses and decrypts the given JWE using the private key identified by the kid in its protected header. Returns the plaintext (Base64-encoded) plus metadata about key selection, algorithm, and any warnings. Uses JWE General JSON Serialization (RFC 7516 §7.2) uniformly — single-recipient for SIMPLE keys, multi-recipient for COMPOSITE hybrid keys. ",
"item": [
{
"name": "SIMPLE key (single-recipient General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJlbmMiOiJBMjU2R0NNIn0\",\n \"recipients\" : [ {\n \"header\" : {\n \"alg\" : \"RSA-OAEP-256\",\n \"kid\" : \"my-rsa-3072-key\"\n },\n \"encrypted_key\" : \"OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9k\"\n } ],\n \"iv\" : \"48V1_ALb6US04U3b\",\n \"ciphertext\" : \"5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4\",\n \"tag\" : \"XFBoMYUZodetZdvTiFvSkQ\"\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/decrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"decrypt"
],
"variable": [
],
"query": [
]
},
"description": "Parses and decrypts the given JWE using the private key identified by the kid in its protected header. Returns the plaintext (Base64-encoded) plus metadata about key selection, algorithm, and any warnings. Uses JWE General JSON Serialization (RFC 7516 §7.2) uniformly — single-recipient for SIMPLE keys, multi-recipient for COMPOSITE hybrid keys. "
}
,"response": [
]
},
{
"name": "COMPOSITE hybrid key (multi-recipient General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJlbmMiOiJBMjU2R0NNIn0\",\n \"recipients\" : [ {\n \"header\" : {\n \"alg\" : \"ML-KEM-768\",\n \"kid\" : \"my-hybrid-key#mlkem\"\n },\n \"encrypted_key\" : \"Pa8K3hYbN9_TmRcF2D5wXqEyZ7VuG4Hj1NkLmP0qO2rS\"\n }, {\n \"header\" : {\n \"alg\" : \"RSA-OAEP-256\",\n \"kid\" : \"my-hybrid-key#rsa\"\n },\n \"encrypted_key\" : \"OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9k\"\n } ],\n \"iv\" : \"48V1_ALb6US04U3b\",\n \"ciphertext\" : \"5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4\",\n \"tag\" : \"XFBoMYUZodetZdvTiFvSkQ\"\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/decrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"decrypt"
],
"variable": [
],
"query": [
]
},
"description": "Parses and decrypts the given JWE using the private key identified by the kid in its protected header. Returns the plaintext (Base64-encoded) plus metadata about key selection, algorithm, and any warnings. Uses JWE General JSON Serialization (RFC 7516 §7.2) uniformly — single-recipient for SIMPLE keys, multi-recipient for COMPOSITE hybrid keys. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/decrypt-verify",
"description": "Performs decrypt-then-verify operation: decrypts nested JWE to reveal inner JWS, then verifies the signature and extracts original plaintext. Decryption and verification key identifiers are automatically extracted from token headers per JOSE standards (RFC 7516 §4.1.4, RFC 7515 §4.1.4). Both keys must be homogeneous (both symmetric or both asymmetric). COMPOSITE keys are supported via JWE/JWS General JSON Serialization format. Key type combinations: - Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256) - Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + RSA) - COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE) - COMPOSITE + SIMPLE (any homogeneous combination) Returns 422 if signature verification fails or token format is invalid. ",
"item": [
{
"name": "SIMPLE keys (single-recipient General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJhbGciOiJNTC1LRU0tMTAyNCIsImVuYyI6IkEyNTZHQ00iLCJjdHkiOiJKV1MiLCJraWQiOiJteS1kZWNyeXB0LWtleSJ9\",\n \"recipients\" : [ {\n \"header\" : {\n \"kid\" : \"my-decrypt-key\"\n },\n \"encrypted_key\" : \"EncryptedKey_BASE64URL\"\n } ],\n \"iv\" : \"IV_BASE64URL\",\n \"ciphertext\" : \"InnerJwsCiphertext_BASE64URL\",\n \"tag\" : \"Tag_BASE64URL\"\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/decrypt-verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"decrypt-verify"
],
"variable": [
],
"query": [
]
},
"description": "Performs decrypt-then-verify operation: decrypts nested JWE to reveal inner JWS, then verifies the signature and extracts original plaintext. Decryption and verification key identifiers are automatically extracted from token headers per JOSE standards (RFC 7516 §4.1.4, RFC 7515 §4.1.4). Both keys must be homogeneous (both symmetric or both asymmetric). COMPOSITE keys are supported via JWE/JWS General JSON Serialization format. Key type combinations: - Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256) - Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + RSA) - COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE) - COMPOSITE + SIMPLE (any homogeneous combination) Returns 422 if signature verification fails or token format is invalid. "
}
,"response": [
]
},
{
"name": "COMPOSITE hybrid keys (multi-recipient General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJlbmMiOiJBMjU2R0NNIiwiY3R5IjoiSldTIiwia2lkIjoibXktaHlicmlkLWRlY3J5cHQta2V5In0\",\n \"recipients\" : [ {\n \"header\" : {\n \"alg\" : \"RSA-OAEP-256\",\n \"kid\" : \"my-hybrid-decrypt-key#rsa\"\n },\n \"encrypted_key\" : \"ClassicalEK_BASE64URL\"\n }, {\n \"header\" : {\n \"alg\" : \"ML-KEM-1024\",\n \"kid\" : \"my-hybrid-decrypt-key#mlkem\"\n },\n \"encrypted_key\" : \"PqcEK_BASE64URL\"\n } ],\n \"iv\" : \"IV_BASE64URL\",\n \"ciphertext\" : \"InnerJwsCiphertext_BASE64URL\",\n \"tag\" : \"Tag_BASE64URL\"\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/decrypt-verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"decrypt-verify"
],
"variable": [
],
"query": [
]
},
"description": "Performs decrypt-then-verify operation: decrypts nested JWE to reveal inner JWS, then verifies the signature and extracts original plaintext. Decryption and verification key identifiers are automatically extracted from token headers per JOSE standards (RFC 7516 §4.1.4, RFC 7515 §4.1.4). Both keys must be homogeneous (both symmetric or both asymmetric). COMPOSITE keys are supported via JWE/JWS General JSON Serialization format. Key type combinations: - Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256) - Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + RSA) - COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE) - COMPOSITE + SIMPLE (any homogeneous combination) Returns 422 if signature verification fails or token format is invalid. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/encrypt",
"description": "Encrypts Base64‑encoded data using the public key associated with kid. Supported algorithms: ML‑KEM (KEM), RSA, ECC (ECIES). Output: a typed JWE General JSON Serialization (RFC 7516 §7.2) payload — uniform shape across SIMPLE single-recipient keys and COMPOSITE hybrid multi-recipient keys. ",
"item": [
{
"name": "Encrypt request",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"kid\" : \"myKeyKid\",\n \"data\" : \"SGVsbG8gQW5rYQ==\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/encrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"encrypt"
],
"variable": [
],
"query": [
]
},
"description": "Encrypts Base64‑encoded data using the public key associated with kid. Supported algorithms: ML‑KEM (KEM), RSA, ECC (ECIES). Output: a typed JWE General JSON Serialization (RFC 7516 §7.2) payload — uniform shape across SIMPLE single-recipient keys and COMPOSITE hybrid multi-recipient keys. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/reencrypt",
"description": "Decrypts the incoming JWE under the kid in its protected header (or under sourceKidOverride if the header has no kid) and re-encrypts the plaintext under newKid. The result is a fresh JWE General JSON Serialization (RFC 7516 §7.2) payload — single-recipient for SIMPLE target keys, multi-recipient for COMPOSITE hybrid targets. ",
"item": [
{
"name": "SIMPLE → SIMPLE re-encryption",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJlbmMiOiJBMjU2R0NNIn0\",\n \"recipients\" : [ {\n \"header\" : {\n \"alg\" : \"RSA-OAEP-256\",\n \"kid\" : \"old-rsa-key\"\n },\n \"encrypted_key\" : \"OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9k\"\n } ],\n \"iv\" : \"48V1_ALb6US04U3b\",\n \"ciphertext\" : \"5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4\",\n \"tag\" : \"XFBoMYUZodetZdvTiFvSkQ\"\n },\n \"newKid\" : \"new-mlkem-key\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/reencrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"reencrypt"
],
"variable": [
],
"query": [
]
},
"description": "Decrypts the incoming JWE under the kid in its protected header (or under sourceKidOverride if the header has no kid) and re-encrypts the plaintext under newKid. The result is a fresh JWE General JSON Serialization (RFC 7516 §7.2) payload — single-recipient for SIMPLE target keys, multi-recipient for COMPOSITE hybrid targets. "
}
,"response": [
]
},
{
"name": "COMPOSITE → COMPOSITE re-encryption (hybrid PQC rotation)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJlbmMiOiJBMjU2R0NNIn0\",\n \"recipients\" : [ {\n \"header\" : {\n \"alg\" : \"ML-KEM-768\",\n \"kid\" : \"old-hybrid#mlkem\"\n },\n \"encrypted_key\" : \"Pa8K3hYbN9_TmRcF2D5wXqEyZ7VuG4Hj1NkLmP0qO2rS\"\n }, {\n \"header\" : {\n \"alg\" : \"RSA-OAEP-256\",\n \"kid\" : \"old-hybrid#rsa\"\n },\n \"encrypted_key\" : \"OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9k\"\n } ],\n \"iv\" : \"48V1_ALb6US04U3b\",\n \"ciphertext\" : \"5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4\",\n \"tag\" : \"XFBoMYUZodetZdvTiFvSkQ\"\n },\n \"newKid\" : \"new-hybrid-key\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/reencrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"reencrypt"
],
"variable": [
],
"query": [
]
},
"description": "Decrypts the incoming JWE under the kid in its protected header (or under sourceKidOverride if the header has no kid) and re-encrypts the plaintext under newKid. The result is a fresh JWE General JSON Serialization (RFC 7516 §7.2) payload — single-recipient for SIMPLE target keys, multi-recipient for COMPOSITE hybrid targets. "
}
,"response": [
]
},
{
"name": "With sourceKidOverride (legacy migration — header omits kid)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jweToken\" : {\n \"protected\" : \"eyJlbmMiOiJBMjU2R0NNIn0\",\n \"recipients\" : [ {\n \"header\" : {\n \"alg\" : \"A256GCMKW\"\n },\n \"encrypted_key\" : \"...\"\n } ],\n \"iv\" : \"iv-bytes\",\n \"ciphertext\" : \"ct-bytes\",\n \"tag\" : \"tag-bytes\"\n },\n \"newKid\" : \"new-mlkem-key\",\n \"sourceKidOverride\" : \"legacy-rsa-key\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/reencrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"reencrypt"
],
"variable": [
],
"query": [
]
},
"description": "Decrypts the incoming JWE under the kid in its protected header (or under sourceKidOverride if the header has no kid) and re-encrypts the plaintext under newKid. The result is a fresh JWE General JSON Serialization (RFC 7516 §7.2) payload — single-recipient for SIMPLE target keys, multi-recipient for COMPOSITE hybrid targets. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/resign",
"description": "Verifies the incoming JWS (Compact or General JSON Serialization) under its embedded `oldKid` (or an explicit override) and, if valid, produces a replacement signature with `newKid`. Useful for algorithm migrations without touching payload bytes. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the RE-SIGNED output (the incoming form does not govern it) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` token structurally cannot carry it). **Behavior truth table** (`serialization` × effective stamping → output form): | `serialization` | stamping | output | 400? | |---|---|---|---| | omitted | OFF | compact JWS | no | | omitted | REQUIRED | JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T) | no | | `COMPACT` | OFF | compact JWS | no | | `COMPACT` | REQUIRED | — | **400** `serialization-incompatible-with-timestamp` | | `JSON` | OFF | JWS-JSON, no `sigTst` | no | | `JSON` | REQUIRED | JWS-JSON + `sigTst` (JAdES B-T) | no | An explicit `COMPACT` is never silently upgraded and a mandated stamp is never dropped; the `output` column names the logical serialization tier. On the HTTP wire the re-signed JWS is ALWAYS carried in the typed `jwsToken` (RFC 7515 §7.2 JWS JSON Serialization) envelope: a COMPACT / unstamped result is a single-signature object with no `sigTst` (losslessly convertible to the 3-segment compact form), a JAdES B-T result carries the RFC 3161 `sigTst` in the unprotected header. The re-sign metadata envelope (old/new key requested, per-leg material versions, algorithms, warnings) is ALWAYS present regardless of serialization. ",
"item": [
{
"name": "SIMPLE key (single-signature General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jwsToken\" : {\n \"payload\" : \"SGVsbG8gQW5rYQ\",\n \"signatures\" : [ {\n \"protected\" : \"eyJhbGciOiJQUzI1NiIsImtpZCI6Im9sZC1zaWduLWtleSJ9\",\n \"header\" : {\n \"kid\" : \"old-sign-key\"\n },\n \"signature\" : \"SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cC4hiUPoj\"\n } ]\n },\n \"newKid\" : \"my-post-quantum-sign-key\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/resign",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"resign"
],
"variable": [
],
"query": [
]
},
"description": "Verifies the incoming JWS (Compact or General JSON Serialization) under its embedded `oldKid` (or an explicit override) and, if valid, produces a replacement signature with `newKid`. Useful for algorithm migrations without touching payload bytes. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the RE-SIGNED output (the incoming form does not govern it) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` token structurally cannot carry it). **Behavior truth table** (`serialization` × effective stamping → output form): | `serialization` | stamping | output | 400? | |---|---|---|---| | omitted | OFF | compact JWS | no | | omitted | REQUIRED | JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T) | no | | `COMPACT` | OFF | compact JWS | no | | `COMPACT` | REQUIRED | — | **400** `serialization-incompatible-with-timestamp` | | `JSON` | OFF | JWS-JSON, no `sigTst` | no | | `JSON` | REQUIRED | JWS-JSON + `sigTst` (JAdES B-T) | no | An explicit `COMPACT` is never silently upgraded and a mandated stamp is never dropped; the `output` column names the logical serialization tier. On the HTTP wire the re-signed JWS is ALWAYS carried in the typed `jwsToken` (RFC 7515 §7.2 JWS JSON Serialization) envelope: a COMPACT / unstamped result is a single-signature object with no `sigTst` (losslessly convertible to the 3-segment compact form), a JAdES B-T result carries the RFC 3161 `sigTst` in the unprotected header. The re-sign metadata envelope (old/new key requested, per-leg material versions, algorithms, warnings) is ALWAYS present regardless of serialization. "
}
,"response": [
]
},
{
"name": "COMPOSITE hybrid key (multi-signature General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jwsToken\" : {\n \"payload\" : \"SGVsbG8gQW5rYQ\",\n \"signatures\" : [ {\n \"protected\" : \"eyJhbGciOiJQUzI1NiIsImtpZCI6Im9sZC1oeWJyaWQjcnNhIn0\",\n \"header\" : {\n \"kid\" : \"old-hybrid#rsa\"\n },\n \"signature\" : \"j7e9c4F8nQ2pR5hX1bY6vM3kL0nO7rT4dE9sG2hI3uA4nO5pT\"\n }, {\n \"protected\" : \"eyJhbGciOiJNTC1EU0EtNjUiLCJraWQiOiJvbGQtaHlicmlkI21sZHNhIn0\",\n \"header\" : {\n \"kid\" : \"old-hybrid#mldsa\"\n },\n \"signature\" : \"Q5_pE7vYzKqHN3xWqQfL2K9JxC0pV4Z8mB1tE7cR6dF9sG2hI3u\"\n } ]\n },\n \"newKid\" : \"my-post-quantum-sign-key\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/resign",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"resign"
],
"variable": [
],
"query": [
]
},
"description": "Verifies the incoming JWS (Compact or General JSON Serialization) under its embedded `oldKid` (or an explicit override) and, if valid, produces a replacement signature with `newKid`. Useful for algorithm migrations without touching payload bytes. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the RE-SIGNED output (the incoming form does not govern it) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` token structurally cannot carry it). **Behavior truth table** (`serialization` × effective stamping → output form): | `serialization` | stamping | output | 400? | |---|---|---|---| | omitted | OFF | compact JWS | no | | omitted | REQUIRED | JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T) | no | | `COMPACT` | OFF | compact JWS | no | | `COMPACT` | REQUIRED | — | **400** `serialization-incompatible-with-timestamp` | | `JSON` | OFF | JWS-JSON, no `sigTst` | no | | `JSON` | REQUIRED | JWS-JSON + `sigTst` (JAdES B-T) | no | An explicit `COMPACT` is never silently upgraded and a mandated stamp is never dropped; the `output` column names the logical serialization tier. On the HTTP wire the re-signed JWS is ALWAYS carried in the typed `jwsToken` (RFC 7515 §7.2 JWS JSON Serialization) envelope: a COMPACT / unstamped result is a single-signature object with no `sigTst` (losslessly convertible to the 3-segment compact form), a JAdES B-T result carries the RFC 3161 `sigTst` in the unprotected header. The re-sign metadata envelope (old/new key requested, per-leg material versions, algorithms, warnings) is ALWAYS present regardless of serialization. "
}
,"response": [
]
},
{
"name": "With sourceKidOverride (legacy migration — header omits kid)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jwsToken\" : {\n \"payload\" : \"SGVsbG8gQW5rYQ\",\n \"signatures\" : [ {\n \"protected\" : \"eyJhbGciOiJQUzI1NiJ9\",\n \"signature\" : \"...\"\n } ]\n },\n \"newKid\" : \"my-post-quantum-sign-key\",\n \"sourceKidOverride\" : \"legacy-sign-key-v1\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/resign",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"resign"
],
"variable": [
],
"query": [
]
},
"description": "Verifies the incoming JWS (Compact or General JSON Serialization) under its embedded `oldKid` (or an explicit override) and, if valid, produces a replacement signature with `newKid`. Useful for algorithm migrations without touching payload bytes. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the RE-SIGNED output (the incoming form does not govern it) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` token structurally cannot carry it). **Behavior truth table** (`serialization` × effective stamping → output form): | `serialization` | stamping | output | 400? | |---|---|---|---| | omitted | OFF | compact JWS | no | | omitted | REQUIRED | JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T) | no | | `COMPACT` | OFF | compact JWS | no | | `COMPACT` | REQUIRED | — | **400** `serialization-incompatible-with-timestamp` | | `JSON` | OFF | JWS-JSON, no `sigTst` | no | | `JSON` | REQUIRED | JWS-JSON + `sigTst` (JAdES B-T) | no | An explicit `COMPACT` is never silently upgraded and a mandated stamp is never dropped; the `output` column names the logical serialization tier. On the HTTP wire the re-signed JWS is ALWAYS carried in the typed `jwsToken` (RFC 7515 §7.2 JWS JSON Serialization) envelope: a COMPACT / unstamped result is a single-signature object with no `sigTst` (losslessly convertible to the 3-segment compact form), a JAdES B-T result carries the RFC 3161 `sigTst` in the unprotected header. The re-sign metadata envelope (old/new key requested, per-leg material versions, algorithms, warnings) is ALWAYS present regardless of serialization. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/sign",
"description": "Signs Base64-encoded `data` with the private key associated with `kid` and returns the produced JWS inside a signing-metadata envelope. Supported algorithms: ML-DSA, Falcon, RSA-PSS (PS256), ECDSA (ES256/384/512), and COMPOSITE hybrid keys. **Serialization selection (PRD §60).** The optional `serialization` field expresses the client's chosen JWS representation and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers exist: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the JWS Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` token structurally cannot carry it). **Behavior truth table** (`serialization` × effective stamping → output form): | `serialization` | stamping | output | 400? | |---|---|---|---| | omitted | OFF | compact JWS | no | | omitted | REQUIRED | JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T) | no | | `COMPACT` | OFF | compact JWS | no | | `COMPACT` | REQUIRED | — | **400** `serialization-incompatible-with-timestamp` | | `JSON` | OFF | JWS-JSON, no `sigTst` | no | | `JSON` | REQUIRED | JWS-JSON + `sigTst` (JAdES B-T) | no | An explicit `COMPACT` is never silently upgraded and a mandated stamp is never dropped — the compact+REQUIRED row is the only rejection. The `output` column names the logical serialization tier; see \"Output to parse\" for the exact wire shape. **Output to parse.** On the HTTP wire the produced JWS is ALWAYS carried in the typed `jwsToken` (RFC 7515 §7.2 JWS JSON Serialization) envelope. A COMPACT / unstamped result is a single-signature object with no `sigTst` (losslessly convertible to the 3-segment RFC 7515 §7.1 compact form, as the SDK renders it); a JAdES B-T result carries the RFC 3161 `sigTst` in the unprotected header (`signatures[].header.etsiU[].sigTst`). The surrounding metadata envelope (`keyRequested`, `materialVersion`, `algorithmUsed`, `warnings`) is ALWAYS present regardless of serialization. ",
"item": [
{
"name": "Sign request",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"kid\" : \"mySigningKeyKid\",\n \"data\" : \"SGVsbG8gQW5rYQ==\"\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/sign",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"sign"
],
"variable": [
],
"query": [
]
},
"description": "Signs Base64-encoded `data` with the private key associated with `kid` and returns the produced JWS inside a signing-metadata envelope. Supported algorithms: ML-DSA, Falcon, RSA-PSS (PS256), ECDSA (ES256/384/512), and COMPOSITE hybrid keys. **Serialization selection (PRD §60).** The optional `serialization` field expresses the client's chosen JWS representation and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers exist: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the JWS Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` token structurally cannot carry it). **Behavior truth table** (`serialization` × effective stamping → output form): | `serialization` | stamping | output | 400? | |---|---|---|---| | omitted | OFF | compact JWS | no | | omitted | REQUIRED | JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T) | no | | `COMPACT` | OFF | compact JWS | no | | `COMPACT` | REQUIRED | — | **400** `serialization-incompatible-with-timestamp` | | `JSON` | OFF | JWS-JSON, no `sigTst` | no | | `JSON` | REQUIRED | JWS-JSON + `sigTst` (JAdES B-T) | no | An explicit `COMPACT` is never silently upgraded and a mandated stamp is never dropped — the compact+REQUIRED row is the only rejection. The `output` column names the logical serialization tier; see \"Output to parse\" for the exact wire shape. **Output to parse.** On the HTTP wire the produced JWS is ALWAYS carried in the typed `jwsToken` (RFC 7515 §7.2 JWS JSON Serialization) envelope. A COMPACT / unstamped result is a single-signature object with no `sigTst` (losslessly convertible to the 3-segment RFC 7515 §7.1 compact form, as the SDK renders it); a JAdES B-T result carries the RFC 3161 `sigTst` in the unprotected header (`signatures[].header.etsiU[].sigTst`). The surrounding metadata envelope (`keyRequested`, `materialVersion`, `algorithmUsed`, `warnings`) is ALWAYS present regardless of serialization. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/sign-encrypt",
"description": "Performs sign-then-encrypt operation: signs data with signKid, then encrypts the resulting JWS with encryptKid to produce a nested JWE(JWS) structure. Both keys must be homogeneous (both symmetric or both asymmetric). Both keys must be different for security. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the INNER signed JWS (before it is encrypted into the outer JWE) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers apply to the inner JWS: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` inner token structurally cannot carry it). Truth table (`serialization` × effective stamping → inner form): omitted+OFF → compact; omitted+REQUIRED → JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T); `COMPACT`+OFF → compact; `COMPACT`+REQUIRED → **400** `serialization-incompatible-with-timestamp` (rejected BEFORE any signing or encryption); `JSON`+OFF → JWS-JSON, no `sigTst`; `JSON`+REQUIRED → JWS-JSON + `sigTst`. It never adds or drops a timestamp and does not change the outer JWE. The `jweToken` field and the separated sign/encrypt metadata envelope are ALWAYS present regardless of serialization. Uses JWE General JSON Serialization (RFC 7516 §7.2) and JWS General JSON Serialization (RFC 7515 §7.2) uniformly across SIMPLE and COMPOSITE keys. COMPOSITE keys enable hybrid post-quantum cryptography with dual signatures (COMPOSITE_SIGNATURE) and combined key encapsulation (COMPOSITE_KEM_COMBINE). Key type combinations: - Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256) - Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + ECDSA) - COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE) - COMPOSITE + SIMPLE (any homogeneous combination) The JWE outer header includes cty=\"JWS\" to indicate nested content. ",
"item": [
{
"name": "SIMPLE keys (asymmetric PQC)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"data\" : \"SGVsbG8gQW5rYQ==\",\n \"signKid\" : \"myMLDSASignKey\",\n \"encryptKid\" : \"myMLKEMEncKey\",\n \"validityDays\" : 365\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/sign-encrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"sign-encrypt"
],
"variable": [
],
"query": [
]
},
"description": "Performs sign-then-encrypt operation: signs data with signKid, then encrypts the resulting JWS with encryptKid to produce a nested JWE(JWS) structure. Both keys must be homogeneous (both symmetric or both asymmetric). Both keys must be different for security. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the INNER signed JWS (before it is encrypted into the outer JWE) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers apply to the inner JWS: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` inner token structurally cannot carry it). Truth table (`serialization` × effective stamping → inner form): omitted+OFF → compact; omitted+REQUIRED → JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T); `COMPACT`+OFF → compact; `COMPACT`+REQUIRED → **400** `serialization-incompatible-with-timestamp` (rejected BEFORE any signing or encryption); `JSON`+OFF → JWS-JSON, no `sigTst`; `JSON`+REQUIRED → JWS-JSON + `sigTst`. It never adds or drops a timestamp and does not change the outer JWE. The `jweToken` field and the separated sign/encrypt metadata envelope are ALWAYS present regardless of serialization. Uses JWE General JSON Serialization (RFC 7516 §7.2) and JWS General JSON Serialization (RFC 7515 §7.2) uniformly across SIMPLE and COMPOSITE keys. COMPOSITE keys enable hybrid post-quantum cryptography with dual signatures (COMPOSITE_SIGNATURE) and combined key encapsulation (COMPOSITE_KEM_COMBINE). Key type combinations: - Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256) - Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + ECDSA) - COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE) - COMPOSITE + SIMPLE (any homogeneous combination) The JWE outer header includes cty=\"JWS\" to indicate nested content. "
}
,"response": [
]
},
{
"name": "COMPOSITE keys (hybrid PQC)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"data\" : \"SGVsbG8gQW5rYQ==\",\n \"signKid\" : \"myCompositeDualSignKey\",\n \"encryptKid\" : \"myCompositeHybridKEMKey\",\n \"validityDays\" : 365\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/sign-encrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"sign-encrypt"
],
"variable": [
],
"query": [
]
},
"description": "Performs sign-then-encrypt operation: signs data with signKid, then encrypts the resulting JWS with encryptKid to produce a nested JWE(JWS) structure. Both keys must be homogeneous (both symmetric or both asymmetric). Both keys must be different for security. **Serialization selection (PRD §60).** The optional `serialization` field selects the representation of the INNER signed JWS (before it is encrypted into the outer JWE) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers apply to the inner JWS: **RFC 7515 JWS** (`COMPACT` = §7.1 three-segment compact, or `JSON` = §7.2 JWS JSON Serialization) and **JAdES B-T** (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp `sigTst` in the Unprotected Header per ETSI TS 119 182-1 — a `COMPACT` inner token structurally cannot carry it). Truth table (`serialization` × effective stamping → inner form): omitted+OFF → compact; omitted+REQUIRED → JWS-JSON + `sigTst` (auto-upgrade, JAdES B-T); `COMPACT`+OFF → compact; `COMPACT`+REQUIRED → **400** `serialization-incompatible-with-timestamp` (rejected BEFORE any signing or encryption); `JSON`+OFF → JWS-JSON, no `sigTst`; `JSON`+REQUIRED → JWS-JSON + `sigTst`. It never adds or drops a timestamp and does not change the outer JWE. The `jweToken` field and the separated sign/encrypt metadata envelope are ALWAYS present regardless of serialization. Uses JWE General JSON Serialization (RFC 7516 §7.2) and JWS General JSON Serialization (RFC 7515 §7.2) uniformly across SIMPLE and COMPOSITE keys. COMPOSITE keys enable hybrid post-quantum cryptography with dual signatures (COMPOSITE_SIGNATURE) and combined key encapsulation (COMPOSITE_KEM_COMBINE). Key type combinations: - Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256) - Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + ECDSA) - COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE) - COMPOSITE + SIMPLE (any homogeneous combination) The JWE outer header includes cty=\"JWS\" to indicate nested content. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/crypto/verify",
"description": "Verifies a JWS and reports the cryptographic verdict plus key metadata. Serialization is AUTO-DETECTED — both RFC 7515 §7.1 Compact (three dot-separated segments) and §7.2 JWS JSON Serialization inputs are accepted with no `serialization` parameter. The wire shape is uniform: single-signature for SIMPLE keys, multi-signature for COMPOSITE hybrid keys. **Qualified timestamp (JAdES B-T, informational).** When the verified JWS carries an embedded RFC 3161 qualified timestamp (JAdES `sigTst`), the response surfaces an informational `qualifiedTimestamp` block — `present`, `trustStatus` (VALID/UNTRUSTED/REVOKED/EXPIRED/TIME_ANOMALY), `genTime`, `serialNumber`, `policyOid`. This block is purely informational and NEVER flips the boolean `valid`: a cryptographically valid signature with an absent, untrusted, or revoked timestamp still returns `valid = true`. The block is omitted for a compact or an unstamped JWS. ",
"item": [
{
"name": "SIMPLE key (single-signature General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jwsToken\" : {\n \"payload\" : \"SGVsbG8gQW5rYQ\",\n \"signatures\" : [ {\n \"protected\" : \"eyJhbGciOiJSUzI1NiIsImtpZCI6Im15LXJzYS0zMDcyLWtleSJ9\",\n \"header\" : {\n \"kid\" : \"my-rsa-3072-key\"\n },\n \"signature\" : \"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7\"\n } ]\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"verify"
],
"variable": [
],
"query": [
]
},
"description": "Verifies a JWS and reports the cryptographic verdict plus key metadata. Serialization is AUTO-DETECTED — both RFC 7515 §7.1 Compact (three dot-separated segments) and §7.2 JWS JSON Serialization inputs are accepted with no `serialization` parameter. The wire shape is uniform: single-signature for SIMPLE keys, multi-signature for COMPOSITE hybrid keys. **Qualified timestamp (JAdES B-T, informational).** When the verified JWS carries an embedded RFC 3161 qualified timestamp (JAdES `sigTst`), the response surfaces an informational `qualifiedTimestamp` block — `present`, `trustStatus` (VALID/UNTRUSTED/REVOKED/EXPIRED/TIME_ANOMALY), `genTime`, `serialNumber`, `policyOid`. This block is purely informational and NEVER flips the boolean `valid`: a cryptographically valid signature with an absent, untrusted, or revoked timestamp still returns `valid = true`. The block is omitted for a compact or an unstamped JWS. "
}
,"response": [
]
},
{
"name": "COMPOSITE hybrid key (multi-signature General JSON)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"jwsToken\" : {\n \"payload\" : \"SGVsbG8gQW5rYQ\",\n \"signatures\" : [ {\n \"protected\" : \"eyJhbGciOiJNTC1EU0EtNjUiLCJraWQiOiJteS1oeWJyaWQta2V5I21sZHNhIn0\",\n \"header\" : {\n \"kid\" : \"my-hybrid-key#mldsa\"\n },\n \"signature\" : \"Q5_pE7vYzKqHN3xWqQfL2K9JxC0pV4Z8mB1tE7cR6dF9sG2hI3uA4nO5pT6sU\"\n }, {\n \"protected\" : \"eyJhbGciOiJQUzI1NiIsImtpZCI6Im15LWh5YnJpZC1rZXkjcnNhIn0\",\n \"header\" : {\n \"kid\" : \"my-hybrid-key#rsa\"\n },\n \"signature\" : \"j7e9c4F8nQ2pR5hX1bY6vM3kL0nO7rT4dE9sG2hI3uA4nO5pT6sUcC4hiUPoj\"\n } ]\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"verify"
],
"variable": [
],
"query": [
]
},
"description": "Verifies a JWS and reports the cryptographic verdict plus key metadata. Serialization is AUTO-DETECTED — both RFC 7515 §7.1 Compact (three dot-separated segments) and §7.2 JWS JSON Serialization inputs are accepted with no `serialization` parameter. The wire shape is uniform: single-signature for SIMPLE keys, multi-signature for COMPOSITE hybrid keys. **Qualified timestamp (JAdES B-T, informational).** When the verified JWS carries an embedded RFC 3161 qualified timestamp (JAdES `sigTst`), the response surfaces an informational `qualifiedTimestamp` block — `present`, `trustStatus` (VALID/UNTRUSTED/REVOKED/EXPIRED/TIME_ANOMALY), `genTime`, `serialNumber`, `policyOid`. This block is purely informational and NEVER flips the boolean `valid`: a cryptographically valid signature with an absent, untrusted, or revoked timestamp still returns `valid = true`. The block is omitted for a compact or an unstamped JWS. "
}
,"response": [
]
}
]
}
]
},
{
"name": " Key Query",
"description": "Retrieve key metadata and list stored keys.",
"item": [
{
"name": "/api/v3/key-management/keys",
"description": " Retrieves ONE PAGE of the tenant's keys. Secret fields (e.g. privateKey) are omitted. Filters (origin/restricted/kty/status) apply server-side BEFORE pagination: totalElements is the filtered count. size is capped at 200 (400 on violation, never clamped). A page beyond the last page yields an empty content array with the true totals (HTTP 200). ",
"item": [
{
"name": "List keys (paginated, no secret data).",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/key-management/keys",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"key-management",
"keys"
],
"variable": [
],
"query": [
{
"key": "origin",
"value": "origin_example",
"description": "Filter by key origin, using the SAME token a key's `origin` field carries in the response. Absent or empty means no filter. Any other value is rejected with 400.",
"disabled": true
},
{
"key": "restricted",
"value": "true",
"description": "Filter by restriction status",
"disabled": true
},
{
"key": "kty",
"value": "kty_example",
"description": "Filter by key type (RSA, EC, ML-KEM, etc.)",
"disabled": true
},
{
"key": "status",
"value": "status_example",
"description": "Filter by key lifecycle status, using the SAME token a key's `status` field carries in the response: `active`, `pending_rotation`, `rotated`, `expired`, `revoked`, `archived`, `deleted_logical`, `suspended`, `pending_destruction`. Absent or empty means no filter. Any other value is rejected with 400.",
"disabled": true
},
{
"key": "page",
"value": "0",
"description": "Zero-based page index.",
"disabled": true
},
{
"key": "size",
"value": "50",
"description": "Page size (1..200). Values above 200 are REJECTED with 400, never clamped.",
"disabled": true
}
]
},
"description": " Retrieves ONE PAGE of the tenant's keys. Secret fields (e.g. privateKey) are omitted. Filters (origin/restricted/kty/status) apply server-side BEFORE pagination: totalElements is the filtered count. size is capped at 200 (400 on violation, never clamped). A page beyond the last page yields an empty content array with the true totals (HTTP 200). "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/key-management/keys/:kid/metadata",
"description": "Returns comprehensive metadata for a single key including: - Lifecycle information (status, created/expires timestamps) - Usage tracking (usage count, limits) - Algorithm details (kty, alg) - Capability flags (exportable, origin, restricted, keyOps) This endpoint is suitable for administrative dashboards, key inventory systems, and compliance audits where cryptographic material exposure is unnecessary. **Note**: To retrieve the public key material, use the admin-api export endpoint GET /api/v3/admin/tenants/{tenantId}/keys/{kid}/export which enforces exportable flag validation. ",
"item": [
{
"name": "Retrieve key metadata (no cryptographic material)",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/key-management/keys/:kid/metadata",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"key-management",
"keys",
":kid",
"metadata"
],
"variable": [
{
"key": "kid",
"value": "",
"description": "Key identifier"
}
],
"query": [
]
},
"description": "Returns comprehensive metadata for a single key including: - Lifecycle information (status, created/expires timestamps) - Usage tracking (usage count, limits) - Algorithm details (kty, alg) - Capability flags (exportable, origin, restricted, keyOps) This endpoint is suitable for administrative dashboards, key inventory systems, and compliance audits where cryptographic material exposure is unnecessary. **Note**: To retrieve the public key material, use the admin-api export endpoint GET /api/v3/admin/tenants/{tenantId}/keys/{kid}/export which enforces exportable flag validation. "
}
,"response": [
]
}
]
}
]
},
{
"name": "License Metrics",
"description": "Operational metrics for license validation monitoring",
"item": [
{
"name": "/api/v3/license/metrics",
"description": "Returns real-time metrics about license validation behavior, including the percentage of requests validated strictly vs allowed without validation. Useful for monitoring service availability vs enforcement tradeoff.",
"item": [
{
"name": "Get license validation metrics",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/license/metrics",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"license",
"metrics"
],
"variable": [
],
"query": [
]
},
"description": "Returns real-time metrics about license validation behavior, including the percentage of requests validated strictly vs allowed without validation. Useful for monitoring service availability vs enforcement tradeoff."
}
,"response": [
]
}
]
}
]
},
{
"name": "Crypto Limits",
"description": "Discovery of the crypto payload limit (read-only)",
"item": [
{
"name": "/api/v3/crypto/limits",
"description": "Returns the maximum plaintext byte length the producer crypto endpoints (encrypt / sign / sign-encrypt) accept. Resolved from the same single source of truth the encrypt gate enforces, so the advertised value never drifts from the enforced one. The limit is a global scalar (identical for every tenant).",
"item": [
{
"name": "Discover the crypto plaintext limit",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/crypto/limits",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"crypto",
"limits"
],
"variable": [
],
"query": [
]
},
"description": "Returns the maximum plaintext byte length the producer crypto endpoints (encrypt / sign / sign-encrypt) accept. Resolved from the same single source of truth the encrypt gate enforces, so the advertised value never drifts from the enforced one. The limit is a global scalar (identical for every tenant)."
}
,"response": [
]
}
]
}
]
},
{
"name": "Policy Cache Monitoring",
"description": "Monitor policy cache health (read-only observability)",
"item": [
{
"name": "/api/v3/monitoring/policy-cache/health",
"description": "Checks if policy cache system is healthy and Redis Pub/Sub listener is active",
"item": [
{
"name": "Policy cache health check",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "*/*",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/monitoring/policy-cache/health",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"monitoring",
"policy-cache",
"health"
],
"variable": [
],
"query": [
]
},
"description": "Checks if policy cache system is healthy and Redis Pub/Sub listener is active"
}
,"response": [
]
}
]
},
{
"name": "/api/v3/monitoring/policy-cache/stats",
"description": "Returns detailed statistics for Caffeine caches and decision cache",
"item": [
{
"name": "Get policy cache statistics",
"request": {
"method": "GET",
"header": [
{
"key": "Accept",
"value": "*/*",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/monitoring/policy-cache/stats",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"monitoring",
"policy-cache",
"stats"
],
"variable": [
],
"query": [
]
},
"description": "Returns detailed statistics for Caffeine caches and decision cache"
}
,"response": [
]
}
]
}
]
},
{
"name": "Migration",
"description": "One-time migration operations for importing keys, certificates, and legacy\ncryptographic data from external systems (PKCS#12, PKCS#7/CMS). These endpoints\nsupport transitioning legacy cryptographic assets to ANKASecure's post-quantum\ninfrastructure. Keys are imported into the tenant keystore for ongoing use.\n",
"item": [
{
"name": "/api/v3/migration/analyze-pkcs7",
"description": "Introspects PKCS#7/CMS binary data and returns structured metadata including signers, recipients, algorithms, certificates, and conversion feasibility. Supports SignedData, EnvelopedData, and SignedAndEnvelopedData. Provides actionable guidance for migration to JOSE (JWE/JWS). **Current support**: Single signer and single recipient only **Multi-actor support**: Planned for future release (multi-signer/multi-recipient with JSON serialization) ",
"item": [
{
"name": "Analyze PKCS#7 SignedData",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"pkcs7Data\" : \"MIIGHgYJKoZIhvcNAQcCoIIGDzCCBgsCAQAxggE...\",\n \"decryptionKid\" : null,\n \"validateCertificates\" : false,\n \"validateTimestamp\" : false\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/migration/analyze-pkcs7",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"migration",
"analyze-pkcs7"
],
"variable": [
],
"query": [
]
},
"description": "Introspects PKCS#7/CMS binary data and returns structured metadata including signers, recipients, algorithms, certificates, and conversion feasibility. Supports SignedData, EnvelopedData, and SignedAndEnvelopedData. Provides actionable guidance for migration to JOSE (JWE/JWS). **Current support**: Single signer and single recipient only **Multi-actor support**: Planned for future release (multi-signer/multi-recipient with JSON serialization) "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/migration/convert-pkcs7-to-jose",
"description": "Converts legacy PKCS#7/CMS files to modern JOSE (JWE/JWS) format. This is a **format conversion** (PKCS#7 container → JOSE container), not an algorithm conversion. Classical algorithms (RSA, ECDSA, AES) are preserved or upgraded (CBC→GCM). **Supported conversions**: - SignedData (1 signer) → JWS Compact - EnvelopedData (1 recipient) → JWE Compact - SignedAndEnvelopedData (1 signer + 1 recipient) → JWE(JWS) Compact **Future enhancement**: Multi-signer/multi-recipient support with JSON serialization **Process:** 1. Parse PKCS#7 structure 2. Verify signatures (optional) 3. Decrypt if encrypted (using imported key) 4. Match signers/recipients with imported keys 5. Re-sign/re-encrypt with JOSE format **Prerequisites:** Import private keys via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore **Next steps:** For PQC algorithms, use POST /api/crypto/reencrypt or POST /api/crypto/resign ",
"item": [
{
"name": "SignedData (1 signer, no encryption)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"pkcs7Data\" : \"MIAGCSqGSIb3DQEHA6CAMIACAQAxggE...\",\n \"serialization\" : \"AUTO\",\n \"targetFormat\" : \"AUTO\",\n \"algorithmPolicy\" : {\n \"allowLegacyHash\" : false\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/migration/convert-pkcs7-to-jose",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"migration",
"convert-pkcs7-to-jose"
],
"variable": [
],
"query": [
]
},
"description": "Converts legacy PKCS#7/CMS files to modern JOSE (JWE/JWS) format. This is a **format conversion** (PKCS#7 container → JOSE container), not an algorithm conversion. Classical algorithms (RSA, ECDSA, AES) are preserved or upgraded (CBC→GCM). **Supported conversions**: - SignedData (1 signer) → JWS Compact - EnvelopedData (1 recipient) → JWE Compact - SignedAndEnvelopedData (1 signer + 1 recipient) → JWE(JWS) Compact **Future enhancement**: Multi-signer/multi-recipient support with JSON serialization **Process:** 1. Parse PKCS#7 structure 2. Verify signatures (optional) 3. Decrypt if encrypted (using imported key) 4. Match signers/recipients with imported keys 5. Re-sign/re-encrypt with JOSE format **Prerequisites:** Import private keys via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore **Next steps:** For PQC algorithms, use POST /api/crypto/reencrypt or POST /api/crypto/resign "
}
,"response": [
]
},
{
"name": "EnvelopedData (1 recipient, encrypted)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"pkcs7Data\" : \"MIIGHgYJKoZIhvcNAQcDoIIGDzCCBgsCAQAxggE...\",\n \"decryptionKid\" : \"legacy-recipient-key\",\n \"serialization\" : \"AUTO\",\n \"targetFormat\" : \"AUTO\",\n \"algorithmPolicy\" : {\n \"contentEncryptionUpgrade\" : \"AES_GCM\"\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/migration/convert-pkcs7-to-jose",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"migration",
"convert-pkcs7-to-jose"
],
"variable": [
],
"query": [
]
},
"description": "Converts legacy PKCS#7/CMS files to modern JOSE (JWE/JWS) format. This is a **format conversion** (PKCS#7 container → JOSE container), not an algorithm conversion. Classical algorithms (RSA, ECDSA, AES) are preserved or upgraded (CBC→GCM). **Supported conversions**: - SignedData (1 signer) → JWS Compact - EnvelopedData (1 recipient) → JWE Compact - SignedAndEnvelopedData (1 signer + 1 recipient) → JWE(JWS) Compact **Future enhancement**: Multi-signer/multi-recipient support with JSON serialization **Process:** 1. Parse PKCS#7 structure 2. Verify signatures (optional) 3. Decrypt if encrypted (using imported key) 4. Match signers/recipients with imported keys 5. Re-sign/re-encrypt with JOSE format **Prerequisites:** Import private keys via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore **Next steps:** For PQC algorithms, use POST /api/crypto/reencrypt or POST /api/crypto/resign "
}
,"response": [
]
},
{
"name": "SignedAndEnvelopedData (1 signer + 1 recipient)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "{\n \"pkcs7Data\" : \"MIIHkwYLKoZIhvcNAQkQAQKgggecMIIHmAIBAQ...\",\n \"decryptionKid\" : \"legacy-recipient-key\",\n \"serialization\" : \"AUTO\",\n \"targetFormat\" : \"AUTO\",\n \"algorithmPolicy\" : {\n \"allowLegacyHash\" : false,\n \"contentEncryptionUpgrade\" : \"AES_GCM\"\n }\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/migration/convert-pkcs7-to-jose",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"migration",
"convert-pkcs7-to-jose"
],
"variable": [
],
"query": [
]
},
"description": "Converts legacy PKCS#7/CMS files to modern JOSE (JWE/JWS) format. This is a **format conversion** (PKCS#7 container → JOSE container), not an algorithm conversion. Classical algorithms (RSA, ECDSA, AES) are preserved or upgraded (CBC→GCM). **Supported conversions**: - SignedData (1 signer) → JWS Compact - EnvelopedData (1 recipient) → JWE Compact - SignedAndEnvelopedData (1 signer + 1 recipient) → JWE(JWS) Compact **Future enhancement**: Multi-signer/multi-recipient support with JSON serialization **Process:** 1. Parse PKCS#7 structure 2. Verify signatures (optional) 3. Decrypt if encrypted (using imported key) 4. Match signers/recipients with imported keys 5. Re-sign/re-encrypt with JOSE format **Prerequisites:** Import private keys via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore **Next steps:** For PQC algorithms, use POST /api/crypto/reencrypt or POST /api/crypto/resign "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/migration/stream/analyze-pkcs7",
"description": "Introspects PKCS#7/CMS binary data of ANY size and returns structured metadata, parsing incrementally. Returns metadata including signers, recipients, algorithms, certificates, and conversion feasibility. **Supports:** - SignedData (1 signer) - EnvelopedData (1 recipient) - SignedAndEnvelopedData (1 signer + 1 recipient) **Current support**: Single signer and single recipient only **Multi-actor support**: Planned for future release **Input:** multipart/form-data with a `metadata` part followed by a `file` part (binary PKCS#7). **Part order is enforced**, as on every other streaming endpoint: `metadata` MUST precede `file`. The parse is sequential and single-pass, so the payload cannot be reached without consuming what precedes it and there is nothing to go back to; a `file`-first body is refused with `400 .../errors/multipart-part-order` before any payload byte is read. ",
"item": [
{
"name": "Analyze PKCS#7 structure (streaming, >5MB files)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/migration/stream/analyze-pkcs7",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"migration",
"stream",
"analyze-pkcs7"
],
"variable": [
],
"query": [
]
},
"description": "Introspects PKCS#7/CMS binary data of ANY size and returns structured metadata, parsing incrementally. Returns metadata including signers, recipients, algorithms, certificates, and conversion feasibility. **Supports:** - SignedData (1 signer) - EnvelopedData (1 recipient) - SignedAndEnvelopedData (1 signer + 1 recipient) **Current support**: Single signer and single recipient only **Multi-actor support**: Planned for future release **Input:** multipart/form-data with a `metadata` part followed by a `file` part (binary PKCS#7). **Part order is enforced**, as on every other streaming endpoint: `metadata` MUST precede `file`. The parse is sequential and single-pass, so the payload cannot be reached without consuming what precedes it and there is nothing to go back to; a `file`-first body is refused with `400 .../errors/multipart-part-order` before any payload byte is read. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/migration/stream/convert-pkcs7-to-jose",
"description": "Converts PKCS#7/CMS files of any size to modern JOSE (JWE/JWS) detached format. This is a **format conversion** (PKCS#7 container → JOSE container), not an algorithm conversion. Classical algorithms (RSA, ECDSA, AES) are preserved or upgraded (CBC→GCM). **Supported conversions:** - SignedData (1 signer) → JWS detached JSON - EnvelopedData (1 recipient) → JWE detached multipart - SignedAndEnvelopedData (1 signer + 1 recipient) → JWE(JWS) detached multipart **Response format varies by PKCS#7 type:** **SignedData** returns `application/octet-stream`: ```json {\"protected\":\"eyJhbGc...\",\"signature\":\"dGVz...\"} ``` **EnvelopedData** returns `multipart/mixed`: ``` ------ankatech- Content-Type: application/jose+json {\"protected\":\"...\",\"recipients\":[...],\"iv\":\"...\"} ------ankatech- Content-Type: application/octet-stream ------ankatech--- ``` **Important:** - No size limit (processes files of any size) - Response does NOT include metadata (signers, recipients, algorithm details) - For metadata: Use POST /api/v3/migration/stream/analyze-pkcs7 first - Output is directly compatible with POST /api/v3/crypto/stream/reencrypt or /resign **Prerequisites:** Import signer/recipient keys via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore **Input:** multipart/form-data with 'metadata' (JSON) and 'file' (binary PKCS#7) ",
"item": [
{
"name": "Convert PKCS#7 to JOSE (streaming)",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "*/*",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/migration/stream/convert-pkcs7-to-jose",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"migration",
"stream",
"convert-pkcs7-to-jose"
],
"variable": [
],
"query": [
]
},
"description": "Converts PKCS#7/CMS files of any size to modern JOSE (JWE/JWS) detached format. This is a **format conversion** (PKCS#7 container → JOSE container), not an algorithm conversion. Classical algorithms (RSA, ECDSA, AES) are preserved or upgraded (CBC→GCM). **Supported conversions:** - SignedData (1 signer) → JWS detached JSON - EnvelopedData (1 recipient) → JWE detached multipart - SignedAndEnvelopedData (1 signer + 1 recipient) → JWE(JWS) detached multipart **Response format varies by PKCS#7 type:** **SignedData** returns `application/octet-stream`: ```json {\"protected\":\"eyJhbGc...\",\"signature\":\"dGVz...\"} ``` **EnvelopedData** returns `multipart/mixed`: ``` ------ankatech- Content-Type: application/jose+json {\"protected\":\"...\",\"recipients\":[...],\"iv\":\"...\"} ------ankatech- Content-Type: application/octet-stream ------ankatech--- ``` **Important:** - No size limit (processes files of any size) - Response does NOT include metadata (signers, recipients, algorithm details) - For metadata: Use POST /api/v3/migration/stream/analyze-pkcs7 first - Output is directly compatible with POST /api/v3/crypto/stream/reencrypt or /resign **Prerequisites:** Import signer/recipient keys via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore **Input:** multipart/form-data with 'metadata' (JSON) and 'file' (binary PKCS#7) "
}
,"response": [
]
}
]
}
]
},
{
"name": "Interoperability",
"description": "Continuous interoperability operations for cryptographic collaboration with\nexternal systems using caller-supplied keys (not persisted in keystore).\nSupports signature verification and encryption for cross-platform integration\nwithout importing keys into ANKASecure infrastructure.\n",
"item": [
{
"name": "/api/v3/interoperability/encrypt",
"description": "Accepts two multipart parts: • metadata – JSON (CryptoUtilityApi) with kty, alg, publicKey • file – binary plaintext Returns a streaming application/octet-stream response without persisting the key. ",
"item": [
{
"name": "Encrypt data with a provided public key (stream).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/interoperability/encrypt",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"interoperability",
"encrypt"
],
"variable": [
],
"query": [
]
},
"description": "Accepts two multipart parts: • metadata – JSON (CryptoUtilityApi) with kty, alg, publicKey • file – binary plaintext Returns a streaming application/octet-stream response without persisting the key. "
}
,"response": [
]
}
]
},
{
"name": "/api/v3/interoperability/verify",
"description": "Accepts two multipart parts: • metadata – JSON (SignatureUtilityApi) containing the caller's detached-JWS object (signatureBase64) and the corresponding publicKey. • file – the raw payload that was signed. The controller ignores any kid inside the JWS header and uses the public key supplied by the caller for streaming verification. On success the endpoint returns a VerifySignatureResponse with isValid=true. ",
"item": [
{
"name": "Verify a detached General-JSON JWS with a supplied public key (stream).",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "multipart/form-data",
"description": "",
"disabled": false
},
{
"key": "Accept",
"value": "application/problem+json",
"description": "",
"disabled": false
}
],
"body": {
"mode": "raw",
"raw": "",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{baseUrl}}/api/v3/interoperability/verify",
"host": [
"{{baseUrl}}"
],
"path": [
"api",
"v3",
"interoperability",
"verify"
],
"variable": [
],
"query": [
]
},
"description": "Accepts two multipart parts: • metadata – JSON (SignatureUtilityApi) containing the caller's detached-JWS object (signatureBase64) and the corresponding publicKey. • file – the raw payload that was signed. The controller ignores any kid inside the JWS header and uses the public key supplied by the caller for streaming verification. On success the endpoint returns a VerifySignatureResponse with isValid=true. "
}
,"response": [
]
}
]
}
]
}
],
"variable": [
{
"key": "baseUrl",
"value": "https://{host}:{port}",
"type": "string"
},
{
"key": "port",
"value": "443",
"type": "string"
},
{
"key": "host",
"value": "demo.ankatech.co",
"type": "string"
}
]
}