Orchestration selects providers according to policy and eligibility rather than hard-coding them into business applications.
INTEGRATION
CA/RSSP & Signing Providers
Separate application orchestration from CA/RSSP certificate, key and signature-creation responsibilities.
ON THIS PAGE
Public CAs and connections through RAR/RS-HUB
A report published by NEAC on 23 May 2025 identifies these providers in the RS-HUB/VNeID context. Status reflects the report date, not current Mobile-ID Sign connections.
| Provider | Source scope | RAR/RS-HUB at publication | Current Mobile-ID Sign |
|---|---|---|---|
| VNPT | Named in the RS-HUB report; confirm the specific product | Connected in the 23 May 2025 report | Confirm for the deployment configuration |
| Viettel | Named in the RS-HUB report; confirm the specific product | Connected in the 23 May 2025 report | Confirm for the deployment configuration |
| MISA | Named in the RS-HUB report; confirm the specific product | Connected in the 23 May 2025 report | Confirm for the deployment configuration |
| Nacencomm | Named in the RS-HUB report; confirm the specific product | Connected in the 23 May 2025 report | Confirm for the deployment configuration |
| Softdreams | Named in the RS-HUB report; confirm the specific product | Connected in the 23 May 2025 report | Confirm for the deployment configuration |
| FPT | Named in the RS-HUB report; confirm the specific product | Connection procedures ongoing in the 23 May 2025 report | Confirm for the deployment configuration |
| Bkav | Named in the RS-HUB report; confirm the specific product | Connection procedures ongoing in the 23 May 2025 report | Confirm for the deployment configuration |
Legal-name mapping, provider identifiers, enrollment/signing/lookup capabilities and certificate eligibility are agreed per deployment.
Read the NEAC report — 23 May 2025 · Review the route and provider identifiersPROVIDER ABSTRACTION
Applications should not hard-code provider semantics
CA/RSSP carries responsibilities for its credential, certificate and signature service. Mobile-ID Sign can normalize state/result/evidence at the integration layer without hiding certificate status or provider-specific limitations needed for audit.
OPERATIONAL DEPTH
CA/RSSP boundary
A CA/RSSP provides trust-service, credential and signature capabilities within its service scope; Mobile-ID Sign does not claim to be the CA where that is not true.
Certificate status, signing result and provider errors are normalized before they reach the business system.
Fallback is allowed only where business/legal policy permits it; provider switching must not silently alter assurance or certificate context.
If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.
| Risk | Handling posture |
|---|---|
| Provider outage | Retain references; query results or escalate. Do not resubmit unknown requests or silently switch providers. |
| Certificate invalid | Keep the record unresolved; use transaction and decision references to reconcile missing evidence. |
| Unauthorized fallback | Keep the record unresolved; use transaction and decision references to reconcile missing evidence. |
CAs and published cooperation scope
Mobile-ID publishes the module-specific cooperation below. This list does not establish that every CA is connected or available in a particular Sign configuration.
MISA-CA
MISA · TMS-RA · Remote Signing
Published cooperationEFY-CA
EFY · TMS-RA
Published cooperationNC-CA
HN · TMS-RA
Published cooperationTrustCA
Savis · TMS-RA · CA
Published cooperationMobile-ID published source · Partners and deployment records