Create consent record
POST/service/individual/record/data-agreement/:dataAgreementId
This endpoint is used to create a consent record when an individial records their consent (e.g. in the privacy dashboard) against a data agreement.
Request
Path Parameters
Unique ID of an object
Query Parameters
An object with id revisionId
Header Parameters
Individual Id
Responses
- 200
- 400
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
- Array [
- ]
consentRecord object
A consent record expresses consent (as defined in this building block's specification) to a single DataAgreement. There must be a UNIQUE constraint on (data agreement revision, individual)
Objects may be passed back by some API endpoints without an id (PK), denoting that they are a "draft", i.e. a ConsentRecord that is not yet stored in the database and only exist in transit. Draft ConsentRecords do not have a Revision, but if paired up with a Signature, a valid Revision should be generated.
The DataAgreement to which consent has been given
The Revision of the data agreement which consent has been given to
Copy of the revision hash. The hash is the included in the signature and ensures against tampering with the original agreement.
The Individual who has signed this consent record
True: The individual has positively opted in. False: The individual has explicitly said no (or withdrawn a previous consent).
Possible values: [unsigned
, signed
]
The state field is used to record state changes after-the-fact. It is maintained by the Consent BB itself. Valid states: unsigned/pending more signatures/signed
A signature that hashes all the values of the consent record and has signed it with the key of the Invidiual, making it verifiable and tamper-proof. TBD: Relation to a Signature schema?
sectorPreferences object[]
Name of the sector
Defines sector is opted in or not
Defines consent record for this sector is last updated
revision object
A generic revision model captures the serialized contents of any schema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
Revision Id
Possible values: [dataAgreement
, policy
, dataAgreementRecord
]
This was previously called "schema" but for technical reasons should be called "schemaName"
The PK of the object that was serialized.
The object that is serialised.
Indicates that objectId was left blank in serizalizedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
Revisioned data (serialized as JSON) as a dict. Apply JSON Canonicalization Scheme as per IETF RFC 8785. It contains all the fields of the schema except sucessorId, serializedHash, serializedSnapshot.
Hash of serizalizedSnapshot (SHA-1)
Timestamp of when revisioning happened. It should be ISO 8601 UTC date time
Individual Id
Reference to an admin user that has created this revision
If this revision is no longer the latest revision, refer to its successor.
Tamper-resistent artifact from previous record, copied from serializedHash
Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
{
"consentRecord": {
"id": "",
"dataAgreementId": "string",
"dataAgreementRevisionId": "string",
"dataAgreementRevisionHash": "",
"individualId": "string",
"optIn": "",
"state": "",
"signatureId": "string",
"sectorPreferences": [
{
"sector": "",
"optIn": true,
"isLastUpdated": true
}
]
},
"revision": {
"id": "",
"schemaName": "",
"objectId": "",
"objectData": "",
"signedWithoutObjectId": "",
"serizalizedSnapshot": "",
"serializedHash": "",
"timestamp": "",
"authorizedByIndividualId": "string",
"authorizedByOtherId": "",
"successorId": "string",
"predecessorHash": "",
"predecessorSignature": ""
}
}
bad input parameter