Signatures
The signature API lets you use Procivis One Core as an issuing authority for other parties. A single endpoint covers several kinds of signed output:
- X.509 certificates: sign a certificate signing request (CSR) with one of your certificate authorities.
- Wallet-Relying Party Access Certificates (WRPAC): issue an X.509 access certificate as defined in ETSI TS 119 475.
- Wallet-Relying Party Registration Certificates (WRPRC): issue a signed registration certificate (JWT) as defined in ETSI TS 119 475.
Each kind of output is produced by a signer, a configured provider with its own request data, issuer requirements, and revocation method.
When to use the signature API
The signature API issues things to someone else. When you sign a CSR, the private key belongs to whoever generated the request. Core returns the result to you and keeps a record for revocation, but the result does not become one of your identifiers.
The other party can be another Core instance. For example, you can run a separate Core instance dedicated to your certificate authorities and sign CSRs from your other instances, keeping your CA keys apart from the instances that issue and verify credentials.
Depending on what you need, a different interface may fit better:
| Goal | Use |
|---|---|
| Create keys, certificates, or DIDs that your own Core instance uses to issue, hold, or verify | The identifiers API. See Identifier Management. |
| Issue Access or Registration Certificates as part of running a wallet-relying party registry | The Wallet-Relying Party Registry service, the managed and preferred interface for these certificates. |
| Sign CSRs for other parties, or issue Access or Registration Certificates directly from Core | The signature API, described here. |
| Qualified electronic signatures on documents | See Qualified Electronic Signatures for Issuers and for Wallets. The signature API does not sign documents. |
Core uses the signature API internally. For example, when you create a self-signed certificate authority through the identifiers API, Core signs it with the X.509 signer. You do not need to call the signature API yourself for these flows.
Available signers
The default configuration includes one signer of each type:
| Signer | Output | Issuer identifier | Revocation |
|---|---|---|---|
X509_CERTIFICATE | X.509 certificate chain (PEM) | Certificate authority | CRL |
ACCESS_CERTIFICATE | X.509 certificate chain (PEM) | Certificate authority | CRL |
REGISTRATION_CERTIFICATE | Signed JWT (rc-wrp+jwt) | Certificate | Token Status List |
The signer value in a request is the name of a configured signer, not
a fixed type. Your deployment may rename these entries or define more than
one signer of the same type, for example two X.509 signers with different
CA-signing rules. See Signer configuration.
For signer-specific request data and behavior, see:
Creating a signature
Before you sign, you need an identifier of the type the signer requires, as shown in the table above. See Certificates.
Every signature request has the same shape. Only data changes between
signers.
POST /api/signature/v1
{
"issuer": "<identifier ID>",
"signer": "X509_CERTIFICATE",
"data": {
"csr": "-----BEGIN CERTIFICATE REQUEST-----\n...\n-----END CERTIFICATE REQUEST-----"
},
"validityEnd": "2027-10-27T00:00:00Z"
}
| Field | Description |
|---|---|
issuer | The identifier that signs. Must be the identifier type the signer requires. |
issuerKey | Optional. A specific key of the issuer identifier. Omit for automatic selection. |
issuerCertificate | Optional. A specific certificate of the issuer identifier. Omit for automatic selection. |
signer | The name of a configured signer. |
data | Signer-specific request data. See the page for each signer. |
validityStart | Optional. See Validity. |
validityEnd | Optional. See Validity. |
The field names and casing inside data differ between signers. Use the
examples on each signer's page.
The response contains:
id: the signature ID. Store it; you need it to revoke the signature or check its status.result: the signed output, in the format listed for the signer above.
{
"id": "4f1c2b7e-...",
"result": "-----BEGIN CERTIFICATE-----\n..."
}
Validity
Each signer has a configured maximum validity period, available from the
configuration endpoint (GET /api/config/v1) as
maxValidityDurationSeconds.
- If you omit
validityStart, validity starts immediately. A start time in the past is rejected. - If you omit
validityEnd, validity runs for the maximum period from the start. - A request is rejected if the end is in the past, the end is before the start, or the period is longer than the configured maximum.
Revocation and status
Every signature created through the API is recorded on the revocation list of the signer's revocation method.
To revoke a signature, use its ID:
POST /api/signature/v1/{id}/revoke
To check the current status of one or more signatures:
POST /api/signature/v1/revocation-check
{
"signatureIds": ["4f1c2b7e-...", "9a0d3e51-..."]
}
The response maps each signature ID to its state (ACTIVE or REVOKED) and
the name of the signer that created it. IDs that are not found are omitted
from the response.
Permissions
When Core runs in STS authentication mode, creating and revoking signatures requires a permission specific to the signer:
| Signer type | Create | Revoke |
|---|---|---|
| X.509 certificate | X509_CERTIFICATE_SIGN | X509_CERTIFICATE_REVOKE |
| Access Certificate | ACCESS_CERTIFICATE_SIGN | ACCESS_CERTIFICATE_REVOKE |
| Registration Certificate | REGISTRATION_CERTIFICATE_SIGN | REGISTRATION_CERTIFICATE_REVOKE |
The permission applies to the signer, whichever endpoint uses it. Creating a
self-signed certificate authority through the identifiers API also requires
X509_CERTIFICATE_SIGN.
Permissions are only enforced in STS authentication mode. With a static token or no authentication, any caller who can reach the API can create and revoke signatures with every configured signer. If you expose the signature API, run Core in STS mode, or disable the signers you do not need.