Update consent record signature
PUT/service/individual/record/consent-record/:consentRecordId/signature
This endpoint is used to update a signature object for the consent record for an individual in an organiation defined in the consent building block.
Request
Path Parameters
Unique ID of an object
Header Parameters
Individual Id
- application/json
Body
signature objectrequired
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 exist in transit.
The final payload that is signed, constructed as a JSON serialization of fields {verificationPayload: ..., verificationPayloadHash: ..., verificationMethod: ..., verificationArtifact: ..., verificationSignedBy: ..., verificationJwsHeader, timestamp: ..., signedWithoutObjectReference: ..., objectType: ..., objectReference: ...}. Serialized 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:
Internally generated serialized version of the data referenced by objectType and objectReference - by extracting and serializing 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 case of a cryptographic signature, this field should contain some identifier for looking up or verifying the public key of the signing party. In 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 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 authorizing 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 serialized 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 serialized 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)
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 exist in transit.
The final payload that is signed, constructed as a JSON serialization of fields {verificationPayload: ..., verificationPayloadHash: ..., verificationMethod: ..., verificationArtifact: ..., verificationSignedBy: ..., verificationJwsHeader, timestamp: ..., signedWithoutObjectReference: ..., objectType: ..., objectReference: ...}. Serialized 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:
Internally generated serialized version of the data referenced by objectType and objectReference - by extracting and serializing 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 case of a cryptographic signature, this field should contain some identifier for looking up or verifying the public key of the signing party. In 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 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 authorizing 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 serialized 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 serialized 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