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 the OpenAPI YAML specification contained in this release.
You can see the latest unreleased version of the OpenAPI specification in the main branch of our GitHub repository.
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.
DELETE - Deletes an existing Webhook object.
Unique ID of an object
READ - Fetch 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 records.
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.
""READ - Fetch 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 records.
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.
""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.
""READ - get a Webhook object.
Unique ID of an object
An object with id revisionId
Generic webhooks used to store subscriptions of third-parties that are notified by events.
""""""""""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 records.
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.
""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 records.
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 records.
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.
""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 records.
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 - Fetches list of readable Webhook 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 Webhook objects readable for the current session's credentials.
""""""""""READ
Unique ID of an object
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""READ - Individual ID supplied as HTTP header. Fetches the current ConsentRecord for an Agreement. There should be one unambiguous ConsentRecord for an Individual and an Agreement.
Unique ID of an object
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 records.
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.
""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 records.
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 a new Webhook object and returns the new object
Generic webhooks used to store subscriptions of third-parties that are notified by events.
""""""""""A set consisting of the new Webhook object created, together with the initial Revision object.
Generic webhooks used to store subscriptions of third-parties that are notified by events.
""""""""""LIST - fetch ConsentRecord objects
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
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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""LIST - Fetches all current unambiguous consent records stored for Individual ID. Individual ID supplied as HTTP header.
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
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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""LIST - Fetches all consent records given to a particular agreement. Individual ID supplied as HTTP header.
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
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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""UPDATE - Updates an existing Webhook object, returning the updated version.
Unique ID of an object
Generic webhooks used to store subscriptions of third-parties that are notified by events.
""""""""""Generic webhooks used to store subscriptions of third-parties that are notified by events.
""""""""""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
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""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.
""""""""""""LIST - Fetch
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 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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""Unique ID of an object
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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""READ - fetch a single Agreement.
Unique ID of an object
A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""UPDATE - Updates a Signature object for a Consent Record. This is used to add a signature to an existing unsigned Signature object. Consent BB is responsible for updating the Consent Record state. Signature object fieldset is restricted.
Unique ID of an 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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""CREATE - Creates and returns a Signature object for the Consent Record with a payload ready for signing. Signature object fieldset is restricted.
Unique ID of an 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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""CREATE - A new DataAgreement object is created and returned together with a Revision
A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""READ - Reads a consent record by its ID.
Unique ID of an object
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""CREATE - For a particular Individual and a particular Agreement, create a new Consent Record pointing to the current Revision of a given Agreement. Individual ID supplied as HTTP header.
Unique ID of an object
An object with id individualId
An object with id revisionId
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""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
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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 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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""READ - get a Policy object + latest Revisio
Unique ID of an object
An object with id revisionId
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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 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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""CREATE - Gets a DRAFT (unsaved) ConsentRecord and Signature objects (without a PK) for a given dataAgreementId.
An object with id individualId
An object with id dataAgreementId
An object with id revisionId
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""UPDATE* - Update a particular Consent Record, generating a new Revision object. Individual ID supplied as HTTP header. Note that updating a signed Consent Record invalidates its signature. Field set subject to update is restricted.
Unique ID of an object
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""LIST - Fetch consent records (latest revision). For a given ConsentRecordFilter, query if consent exists.
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
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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""LIST - fetch all Agreements stored 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 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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""READ - fetches the latest version of an Agreement
Unique ID of an object
A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""DELETE - Deletes an existing Policy object, returning a new revision. Deleting a Policy is not possible if it's associated with active DataAgreement.
Unique ID of an object
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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""READ - fetches the latest version of an Agreement
Unique ID of an object
A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""CREATE - Creates a paired ConsentRecord and Signature object. Returns the same objects with the PK defined.
A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""A Consent Record expresses consent (as defined in this building block's specification) to a single Data Agreement. There must be a UNIQUE constraint on (dataAgreementRevision, 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.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""Copy of the Revision's hash. The hash is the included in the signature and ensures against tampering with the original Data 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 records.
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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""CREATE - Creates a new Policy object and returns the new object and a PolicyRevision
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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 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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""UPDATE - Updates an existing Policy object, returning the updated version and a new revision. Updating a Policy must not affect existing active references in DataAgreement, the new Revision should be specified for Agreement.
Unique ID of an object
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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 policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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 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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""UPDATE - An existing DataAgreement object is created and returned together with a new Revision
Unique ID of an object
A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
""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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""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 "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (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 records.
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 serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""LIST - fetch all DataAgreements
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 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 Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data 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.
""""""""""""Purpose of data processing or purpose of consent. Displayed to the user.
""Lawful basis of the Data Agreement - consent / legal_obligation / contract / vital_interest / public_task / legitimate_interest
""null/data_source/data_using_service
""Data Protection Impact Assessment
""Data Agreement is active and new Consent Records can be created.
""Consent Record may be deleted when consent is withdrawn, as its existence is not necessary for auditability.
""A Data Agreement contains the specification of a single purpose that can be consented to. A Data Agreement is universal and can be consented to by many individuals through a ConsentRecord. A Data Agreement implements a specific type of agreement related to personal data, modeled by DataAgreementAttribute. There may be other types of agreements modeled in future Consent BB releases. Notice that when creating a serialized snapshop for revisioning a Data Agreement, all related objects have to be serialized and included.
TBD: Models the valid lifecycle states of a Data Agreement
""Draft / Complete
""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 {verificiationPayload: ..., 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: . 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 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.
""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, a Data Agreement, Policy etc)
""