Creates blank signature
POST/service/individual/record/consent-record/:consentRecordId/signature
This endpoint is used to create a blank signature object for the consent record for an individual in an organiation defined in the consent building block. Creates and returns a blank Signature object for the consent record.
Request
Path Parameters
Unique ID of an object
Header Parameters
Individual ID
Responses
- 200
- 400
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
signature object
A generic signature contains a cryptographic hash of some value, together with a signature created by some private key in another system. Required signing methods: Revision object or another Signature object.
Objects may be passed back by some API endpoints without an id (PK), denoting that they are a "draft", i.e. a Signature that is not yet stored in the database and only exists in transit.
The final payload that is signed, constructed as a JSON serialisation of fields {verificationPayload: ..., verificationPayloadHash: ..., verificationMethod: ..., verificationArtifact: ..., verificationSignedBy: ..., verificationJwsHeader, timestamp: ..., signedWithoutObjectReference: ..., objectType: ..., objectReference: ...}. Serialised as a JSON dict. If the signature is generated before anything is stored in the database (and has a PK), then the objectReference should be omitted from the payload but filled in afterwards.
Signature of payload hash, the format of the signature should be specified by either verificationMethod or verificationJwsHeader
A well-known string denoting which method is used. Valid values: TBD. This might be expanded with supported verification methods. There may be a minimal set of supported methods necessary.
Internally generated serialised version of the data referenced by objectType and objectReference - by extracting and serialising their data as JSON
Internally generated cryptographic hash of the value to be signed, i.e. the value of verificationPayload
A verification artifact in the form of a scanned object, image, signature etc
Because an identifier's information may change over time, there is a need to store that information at the time of signing. In the case of a cryptographic signature, this field should contain some identifier for looking up or verifying the public key of the signing party. In the case of a non-cryptographic signature, this field could contain a natural individual's names, personal number, email addresses - store a snapshot that binds to the signature at the time of signing. In the case of a cryptographic signature, this may be the fingerprint of the individual's public key or in some cases, a token from the user's ID session.
DRAFT FIELD: Specifies the relationship between the authorising signature and the invidual which the payload concerns. This is relevant for Consent Records. Possible values: "individual" / "delegate".
Alternative to the verificationMethod, verificationHash and verificationSignature, give a JWS serialised object (RFC7515)
Timestamp of signature, currently this field isn't part of the payload so it's not tamper-proof
Indicates that objectReference was left blank in the serialised version that was signed
Possible values: [revision, signature]
Name of the schema model that objectReference points to. Values: "signature" or "revision"
A symmetric relation / back reference to the objectType that was signed. We are currently just modelling signing another signature (a chain) or signing a Revision (which can be a revision of a consent record, an agreement, policy etc).
{
  "signature": {
    "id": "",
    "payload": "",
    "signature": "",
    "verificationMethod": "",
    "verificationPayload": "",
    "verificationPayloadHash": "",
    "verificationArtifact": "",
    "verificationSignedBy": "",
    "verificationSignedAs": "",
    "verificationJwsHeader": "",
    "timestamp": "",
    "signedWithoutObjectReference": "",
    "objectType": "",
    "objectReference": ""
  }
}
bad input parameter