Register a bank signing key for an onboarding case

POST 
/v1/onboarding-cases/:case_id/signing-targets

Registers a reference to a signing key the bank holds, for one purpose. The key stays in the bank's backend; only the provider reference and the public key are recorded. The target is created with verification_state: PENDING; call POST .../signing-targets/{target_id}/verify to prove the reference before you submit.

As an alternative to registering keys yourself, POST .../key-generation-jobs creates, registers and verifies the keys for you.

Required scope: connector:onboarding:artifacts:write.

Allowed states: AWAITING_BANK_ADMIN, BANK_CONFIGURING, NEEDS_CHANGES (otherwise 409). The first edit moves AWAITING_BANK_ADMIN to BANK_CONFIGURING.

Fields (all in data.attributes):

• purpose (required): BANK_ADMIN, CREATE_INTERBANK_TRANSFER_MAKER or APPROVE_INTERBANK_TRANSFER_CHECKER. Only one target per purpose is allowed; a second one returns 409.
• backend_class (required): the key backend. AWS_KMS references take the form kms://{region}/{account_id}/{alias_path}; AWS_CLOUDHSM references cloudhsm://{locator}; GCP_CLOUD_KMS_HSM references gcp-kms://{location}/{project_id}/{key_ring}/{key_id}/{key_version}. A malformed reference returns 422.
• backend_ref (required, not blank): the provider reference. Must be unique within the case.
• algorithm (required): P256_SHA256_ASN1 or ED25519_PH_SHA_512.
• public_key (required): encoding must be spki_der_base64; value is the public key as base64-encoded SubjectPublicKeyInfo DER.
• public_key_fingerprint (required): algorithm must be sha256; value is the SHA-256 digest of the decoded DER bytes, in hexadecimal (a sha256: prefix and upper case are accepted and normalised to lower-case hex without prefix). It must match public_key.value (otherwise 422) and be unique within the case.
• backend (optional): provider-specific metadata, stored as given.

References to platform-generated keys. If backend_ref points at a key the platform generated, it must have been generated for this bank and case; otherwise the call returns 403 BANK_SCOPE_MISMATCH.

No Idempotency-Key is used. Repeating a successful request returns 409, because the purpose (and reference) are already registered.

Request

Responses

201

Signing target recorded with verification_state PENDING.

400

The request is malformed: invalid JSON syntax, an invalid path or query parameter, a missing required header such as Idempotency-Key, or a single field that fails its own format rule. Fix the request before retrying; retrying it unchanged fails again.

401

The bearer token is missing, malformed, expired, signed by an unknown key, or was not issued by the platform IAM for the Lyriq Connector. Obtain a new token and retry. See the Authentication section.

403

The token is valid but may not perform this request: it lacks the required scope, has no bank membership, needs an x-dan-bank-id header to choose between several memberships, names a bank in x-dan-bank-id it has no membership for, or the caller's bank is suspended or terminated. A new token with the same configuration fails the same way. See the Authentication section.

404

The resource does not exist, or it belongs to another bank. The Lyriq Connector does not distinguish the two cases, so resources of other banks are never disclosed.

409

The case is not editable, or a target already exists for this purpose, reference or fingerprint.

422

The request body is malformed for this resource or the key material is invalid.

503

The request could not be served right now. Either the network is not fully operational (OUTBOUND_HALTED or READ_ONLY: mutations are refused while read endpoints keep working; OPERATIONAL_STATE_UNKNOWN: the state could not be determined), or a platform dependency is temporarily unavailable. No Retry-After header is sent; retry later with backoff. When retrying a mutation, reuse the same Idempotency-Key and body.