Retry
Transient failure without changing trust route.
Orchestration
Signing Orchestration
Orchestrate by policy, record context and allowed routes; reconcile uncertainty before retrying.
ON THIS PAGE
POLICY-BASED ROUTING
The right signing route for each transaction.
Route selection should follow actual policy and implemented capability—not a cosmetic user choice.
WHOWHATIDENTITYCREDENTIALPOLICYRISKAVAILABILITY
GoPaperless
Policy & Routingreference architecture
Policy & Routingreference architecture
VNeID / RS-HUB
Passkey / SIC
Other supported route
FAILURE DISCIPLINE
No silent legal fallback.
Blocked
Required route unavailable and no permitted alternate route.
Alternate route
Only if policy explicitly allows it.
TRUSTED SIC CEREMONY
Passkey verifies/authorizes; signing infrastructure creates the digital signature
The transaction summary and authorization context must remain distinct from the credential that ultimately produces the signature.
Document and policyVersion • signer • authority
VNeID / RS-HUBApplicable identity and signing service route
GoPaperless AgentDesktop application handoff
REST APIAsynchronous transaction integration
Trusted SICTransaction-bound authorization
CA / RSSPSignature creation with the applicable key and certificate
Verification and evidenceOutput • state • correlation
If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.
| Layer | Role | Boundary |
|---|---|---|
| Passkey credential | Authentication / user verification | Not the signing certificate/private key |
| Authorization event | Evidence of user intent for the transaction | Does not by itself create the digital signature |
| Signing credential | Certificate/key managed by applicable signing infrastructure | Subject to provider/device policy |
ASSESSMENT DETAIL
Decision model for signing routes
Orchestration is a controlled decision, not vague “smart routing.” Inputs may include business policy, document type, actor, channel, allowed signing methods, available credentials/providers and transaction state. The output is an allowed route or a blocked/manual-support state; the system does not silently lower assurance merely to complete a transaction.
If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.
| Condition | Decision | Evidence |
|---|---|---|
| Required route available | Use the required route | Policy + route + provider result |
| Preferred route unavailable | Fallback only when explicitly allowed | Fallback rule + user/business context |
| No allowed credential/provider | Block / support | Reason + audit event |
| Uncertain provider result | Reconcile before retry | Correlation + status query/event |
| User cancels | Terminate the authorization attempt | User/transaction event |
An exact policy engine, ranking algorithm or fallback rule is labelled production only with a corresponding artefact; this is a reference decision framework.