This section provides a reference for APIs that should be implemented by this Building Block.
This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.
The GovStack non-functional requirements document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.
The tests for the Consent Building Block can be found in this GitHub repository.
The following is an automated rendition of our latest OpenAPI YAML specification.
None
DELETE - Cascading delete operation for Right To Be Forgotten, deletes all Consent Records that shall not be retained and have a "forgettable" Agreement. May also delete an unsigned Consent Record, for instance in cases where the user exits the signing process. Individual ID supplied as HTTP header.
READ - Fetch an Individual in the Consent system
Unique ID of an object
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
LIST - lists individuals in the system
Requested index for start of resources to be provided in response requested by client
Requested number of resources to be provided in response requested by client
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
CREATE - Creates an Individual in the Consent system
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent agreements.
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
UPDATE - Updates an Individual in the Consent system
Unique ID of an object
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent agreements.
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
LIST - returns the current Policy
Unique ID of an object
Requested index for start of resources to be provided in response requested by client
Requested number of resources to be provided in response requested by client
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
LIST - Fetches list of readable Policy objects
An object with id revisionId
Requested index for start of resources to be provided in response requested by client
Requested number of resources to be provided in response requested by client
A list of Policy objects readable for the current session's credentials.
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
READ - fetches the latest version of a Policy and the presented revisionId of an associated Agreement
Unique ID of an object
An object with id revisionId
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
READ - get a Policy object + latest Revision. If a PolicyFilter is supplied and contains a revision_id, then this specific revision is returned.
Unique ID of an object
An object with id revisionId
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
UPDATE - Updates an existing Policy object, returning the updated version and a new revision. Updating a Policy does not affect existing references in Agreement, the new revision should be specified for Agreement.
Unique ID of an object
A policy governs data and Agreement in the realm of an organisation that is refered to as "data controller" (GDPR) and owner of referencing Agreements.
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
CREATE - Creates a new Policy object and returns the new object and a PolicyRevision
A policy governs data and Agreement in the realm of an organisation that is refered to as "data controller" (GDPR) and owner of referencing Agreements.
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
A set consisting of the new Policy object created, together with the initial Revision object.
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
DELETE - Deletes an existing Policy object, returning the updated version and a new revision. Deleting a Policy is not possible if it's associated with active Agreement.
Unique ID of an object
""
This was previously called "schema" but for technical reasons should be called "schema_name"
""
The PK of the object that was serialized.
""
Indicates that object_id was left blank in serialized_snapshot when calculating serialized_hash. object_id may be subsequently filled in.
""
Revisioned data (serialized as JSON) as a dict {object_data: {...}, schema_name: ..., object_id: ..., signed_without_object_id: ..., timestamp: ..., authorized_by_individual: ..., authorized_by_other: ...}. It contains all the fields of the schema except id, successor, predessor_hash and predecessor_signature.
""
Hash of serialized_snapshot (SHA-1)
""
Timestamp of when revisioning happened
""
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent agreements.
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
Reference to an admin user that has created this revision
""
A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
""
This was previously called "schema" but for technical reasons should be called "schema_name"
""
The PK of the object that was serialized.
""
Indicates that object_id was left blank in serialized_snapshot when calculating serialized_hash. object_id may be subsequently filled in.
""
Revisioned data (serialized as JSON) as a dict {object_data: {...}, schema_name: ..., object_id: ..., signed_without_object_id: ..., timestamp: ..., authorized_by_individual: ..., authorized_by_other: ...}. It contains all the fields of the schema except id, successor, predessor_hash and predecessor_signature.
""
Hash of serialized_snapshot (SHA-1)
""
Timestamp of when revisioning happened
""
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent agreements.
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
Reference to an admin user that has created this revision
""
A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
Tamper-resistent artifact from previous record, copied from serialized_hash
""
Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""
Tamper-resistent artifact from previous record, copied from serialized_hash
""
Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""
READ
Unique ID of an object
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.
""
An agreement contains the specification of a single purpose that can be consented to. An Agreement is universal and can be consented to by many individuals through a ConsentRecord
""
The version of this specification to which a receipt conforms
""
Details of a data controller.
""
Name of data controller (may be omitted if no data involved)
""
URL of data controller (may be omitted if no data involved)
""
A policy governs data and Agreement in the realm of an organisation that is refered to as "data controller" (GDPR) and owner of referencing Agreements.
""
Name of the policy
""
Version of the policy
""
Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""
""
""
""
""
""
TBD: Models the purpose of an agreement
""
Name of purpose
""
Description of purpose
""
In order to sign an Agreement, this relation needs to have a cryptopgraphic hash of the JSON serialized data to be included in the Signature payload of the Agreement. Hashes are collected as the hex representation of the SHA-1 sum of all UTF8 encoded string versions of the JSON representation of data. SHA1(json_serialized_data)
""
Lawful basis of the agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""
null/data_source/data_using_service
""
Data Protection Impact Assessment
""
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 {verificiation_payload: ..., verification_payload_hash: ..., verification_method: ..., verification_artifact: ..., verification_signed_by: ..., verification_jws_header, timestamp: ..., signed_without_object_reference: ..., object_type: ..., object_reference: ...}. Serialized as a JSON dict. If the signature is generated before anything is stored in the database (and has a PK), then the object_reference should be omitted from the payload but filled in afterwards.
""
Signature of payload hash, the format of the signature should be specified by either verification_method or verification_jws_header
""
A well-known string denoting which method is used. Valid values: . We might expand this with a relation to which verification methods that are supported. There may be a minimal set of supported methods necessary.
""
Internally generated serialized version of the data referenced by object_type and object_reference - by extracting and serializing their data as JSON.
""
Internally generated cryptographic hash of the value to be signed, i.e. the value of verification_payload
""
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 verification_method, verification_hash and verification_signature, 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 object_reference was left blank in the serialized version that was signed.
""
Name of the schema model that object_reference points to. Values: "signature" or "revision"
""
A symmetric relation / back reference to the object_type 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)
""
Agreement is active and new ConsentRecords can be created.
""
Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""
An agreement contains the specification of a single purpose that can be consented to. An Agreement is universal and can be consented to by many individuals through a ConsentRecord
TBD: Models the valid lifecycle states of an Agreement
""
Draft / Complete
""
A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
""
This was previously called "schema" but for technical reasons should be called "schema_name"
""
The PK of the object that was serialized.
""
Indicates that object_id was left blank in serialized_snapshot when calculating serialized_hash. object_id may be subsequently filled in.
""
Revisioned data (serialized as JSON) as a dict {object_data: {...}, schema_name: ..., object_id: ..., signed_without_object_id: ..., timestamp: ..., authorized_by_individual: ..., authorized_by_other: ...}. It contains all the fields of the schema except id, successor, predessor_hash and predecessor_signature.
""
Hash of serialized_snapshot (SHA-1)
""
Timestamp of when revisioning happened
""
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent agreements.
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
Reference to an admin user that has created this revision
""
A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
Tamper-resistent artifact from previous record, copied from serialized_hash
""
Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""
Copy of the revision hash. The hash is the included in the signature and ensures against tampering with the original agreement.
""
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent agreements.
The unique ID of an Individual row.
""
Reference to another foundational/functional ID, which is likely PII
""
External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""
This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""
True: The individual has positively opted in. False: The individual has explicitly said no (or withdrawn a previous consent).
""
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 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 {verificiation_payload: ..., verification_payload_hash: ..., verification_method: ..., verification_artifact: ..., verification_signed_by: ..., verification_jws_header, timestamp: ..., signed_without_object_reference: ..., object_type: ..., object_reference: ...}. Serialized as a JSON dict. If the signature is generated before anything is stored in the database (and has a PK), then the object_reference should be omitted from the payload but filled in afterwards.
""
Signature of payload hash, the format of the signature should be specified by either verification_method or verification_jws_header
""
A well-known string denoting which method is used. Valid values: . We might expand this with a relation to which verification methods that are supported. There may be a minimal set of supported methods necessary.
""
Internally generated serialized version of the data referenced by object_type and object_reference - by extracting and serializing their data as JSON.
""
Internally generated cryptographic hash of the value to be signed, i.e. the value of verification_payload
""
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 verification_method, verification_hash and verification_signature, 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 object_reference was left blank in the serialized version that was signed.
""
Name of the schema model that object_reference points to. Values: "signature" or "revision"
""
A symmetric relation / back reference to the object_type 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)
""