Skip to main content
Signing proves that a Legal Identity key accepted a specific normalized contract in a specific role. Validation must check more than the signature bytes.

​
Before signing

  1. Fetch the current contract from its provider.
  2. Verify the provider/domain and contract ID.
  3. Validate the XML and parameter rules.
  4. Render the selected human-readable language.
  5. Confirm machine and human sections agree.
  6. Confirm the signer’s Legal Identity is approved and assigned/eligible for the role.
  7. Confirm validity dates and current state permit signing.

​
Key selection

The contract library supports: Legally binding contract signatures should use the approved Legal Identity keys required by the workflow.

​
Validate a received contract

Check:
  • recognized smart-contract namespace and schema;
  • deterministic normalization;
  • parameter types, ranges, expressions, and protected forms;
  • each client signature against the referenced Legal Identity and signed role;
  • role MinCount/MaxCount and explicit part rules;
  • legal identity state and trust chain;
  • server signature/attestation;
  • lifecycle state, timestamps, and visibility;
  • attachment hashes/signatures where used.
Use ContractsClient.Validate(...) for protocol-aware validation. Offline validation can be partial when current identities, schemas, or provider state must be fetched.

​
Replay and race safety

Re-fetch immediately before signing, and submit the signature against the exact version you reviewed. If the contract changed, discard the signature and render the new version. Store the returned contract state and signature identity for audit.