# Changelog Changes to API requests, response fields and customer workflows, newest first. ## October 8, 2026 ### Identity verification Identity verification accepts an application's customer reference as `rp_urn`. The start request includes `customer_id`, `phone_number` and the optional reference; later calls still require `customer_id` and can include the matching `rp_urn`. The returned reference is namespaced to the RP as `urn:securysign::`. On a start request without a reference, `phone_number` supplies `customer_id` if omitted. See [Start a verification](#/docs/kyc#1-start-a-verification) for both request forms. ### Enrolment `POST /api/enrolment/request` returns a `request_uri` for reusing an existing verified result in hosted enrolment. The first account to open the link within 600 seconds is assigned that verification. See [Reuse a verification](#/docs/enrolment#reuse-a-verification-you-ran-yourself) for the link and callback errors. ## October 1, 2026 ### Native apps Registered mobile apps can sign in with the public `-native` client using PKCE. Package or bundle IDs, callbacks and signing identities are managed through `GET /rp/mobile-apps/{rpId}`, `POST /rp/mobile-apps` and `DELETE /rp/mobile-apps/{id}`. The [native sign-in guide](#/docs/sso#sign-in-from-a-native-app) covers authorization and code exchange. Domains can serve generated `assetlinks.json` and `apple-app-site-association` files by proxying `/api/well-known//…`. See [Association-file setup](#/docs/sso#serve-the-association-files-from-your-domain). Native Android passkey assertions are accepted when the `android:apk-key-hash` origin matches a registered signing fingerprint. ### Identity verification Verification results include `personal_number`, the holder's national ID number or extracted passport personal number. `doc_number` identifies the document itself; on a Kenyan ID, it is the replaceable card serial number. Existing records are populated with the personal number where available. See [Verdict fields](#/docs/kyc#5-submit-the-result-and-read-the-verdict) for the distinction. The [native capture setup](#/docs/sdk-reference#native-capture-sdk) documents the service URL, bearer session token and outcome mapping. ## September 30, 2026 ### Enrolment The [SecurySign-hosted enrolment guide](#/docs/enrolment#enrol-through-securysign-directly) covers the entry link, PKCE exchange and callbacks. With `signa-kyc`, identity verification precedes certificate issuance, and the certificate uses the name read from the document. A backend verification can also be reused; the current integration uses `request_uri`. ### Identity verification The SDK reference maps web capture `stopped` reasons to recovery actions. ## September 28, 2026 ### Signing and decryption Signing verifies the passkey assertion against its registered public key, challenge, relying party ID, origin, user verification and signature counter before the server-side key signs. `POST /sign/pades/finalize` takes the approval over the prepared hash: `credentialId`, `signatureBase64`, `authenticatorData` and `clientDataJSON`. Prepared operations expire after five minutes and return `410`. `/decrypt` and `/decrypt/asymmetric` require the signed-in customer's own key; ownership mismatches return `403`. Following SSC-secret rotation, backend requests must use the current secret from the RP dashboard. ### Reference The API reference covers PAdES signing, encryption, certificate PEM downloads, RP self-service, identity providers, visible signatures and plans. Server-library examples distinguish the SSC secret from the OIDC secret used for code exchange. ## Docs, late September 2026 Navigation separates integration guides, API reference and web application workflows. Earlier URLs resolve through aliases. [Verification](#/docs/verification), [Encryption](#/docs/encryption), [Hash signing](#/docs/hash-signing) and [PAdES signing](#/docs/pades-signing) describe the application screens. Backend-library and web/mobile capture examples are collected in the [SDK reference](#/docs/sdk-reference); the [Demos page](#/docs/demo) links signing and capture demonstrations. RP approval authorizes the registered signing origin. Additional origins require separate approval. ## Docs, September 2026 The documentation provides the [OpenAPI 3.1 specification](/docs/openapi.json), page-copy controls, raw Markdown files and an index at [/llms.txt](/llms.txt). Importing the Node.js or PHP server library does not run its demonstration request. Capture, webhook and server-library examples include package checks; Android examples cover WebView and Custom Tab capture. Certificate-by-ID requests use `/pki/certificate/{id}`. The reference specifies SSC challenge and finalize limits and the token request's default `LOA-2`. Authenticated completion reads can recover a missed webhook delivery. ## v1.3.0, May 2026 Vault uploads show encryption progress. PDF request bodies support up to 20 MB. Signing and verification screens display the serial number extracted from the X.509 certificate, and base64 encoding handles large files in chunks. ## v1.2.0, April 2026 Certificate status, renewal and revocation operations are available. Signing approval includes document binding, with request counters applied per IP address or user as appropriate. ## v1.1.0, March 2026 Batch signing supports backend-created requests and completion notifications. Vault encryption supports AES-256-GCM with a wrapped file key, passkey-derived encryption and direct RSA encryption. The iframe has sandbox settings and a defined `postMessage` protocol. ## v1.0.0, February 2026 The initial release includes anonymous and registered-RP iframe signing, supported assurance levels, PAdES PDF signing, and OAuth 2.0/OIDC sign-in. Server-side signing uses keys held in an HSM.