Skip to main content

Create draft consent record

POST 
/service/individual/record/consent-record/draft

This endpoint is used to create a draft (unsaved) consent record and signature object (without a PKI) for a data agreement.

Request​

Query Parameters

    individualId stringrequired

    An object with id individualId

    dataAgreementId stringrequired

    An object with id dataAgreementId

    revisionId stringrequired

    An object with id revisionId

Header Parameters

    X-ConsentBB-IndividualId stringrequired

    Individual Id

Responses​

Response Headers
    Schema
      consentRecord object

      A consent record expresses consent (as defined in this building block's specification) to a single DataAgreement. There must be a UNIQUE constraint on (data agreement revision, individual)

      id stringrequired

      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.

      dataAgreementId string

      The DataAgreement to which consent has been given

      dataAgreementRevisionId string

      The Revision of the data agreement which consent has been given to

      dataAgreementRevisionHash string

      Copy of the revision hash. The hash is the included in the signature and ensures against tampering with the original agreement.

      individualId string

      The Individual who has signed this consent record

      optIn boolean

      True: The individual has positively opted in. False: The individual has explicitly said no (or withdrawn a previous consent).

      state stringrequired

      Possible values: [unsigned, signed]

      The state field is used to record state changes after-the-fact. It is maintained by the Consent BB itself. Valid states: unsigned/pending more signatures/signed

      signatureId string

      A signature that hashes all the values of the consent record and has signed it with the key of the Invidiual, making it verifiable and tamper-proof. TBD: Relation to a Signature schema?

      sectorPreferences object[]
    • Array [
      • sector stringrequired

      Name of the sector

      optIn boolean

      Defines sector is opted in or not

      isLastUpdated boolean

      Defines consent record for this sector is last updated

    • ]
      • signature object

      A generic signature contains a cryptographic hash of some value, together with a signature created by some private key in another system. Required signing methods: Revision object or another Signature object.

      id string

      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.

      payload stringrequired

      The final payload that is signed, constructed as a JSON serialization of fields {verificationPayload: ..., verificationPayloadHash: ..., verificationMethod: ..., verificationArtifact: ..., verificationSignedBy: ..., verificationJwsHeader, timestamp: ..., signedWithoutObjectReference: ..., objectType: ..., objectReference: ...}. Serialized as a JSON dict. If the signature is generated before anything is stored in the database (and has a PK), then the objectReference should be omitted from the payload but filled in afterwards.

      signature stringrequired

      Signature of payload hash, the format of the signature should be specified by either verificationMethod or verificationJwsHeader

      verificationMethod stringrequired

      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.

      verificationPayload stringrequired

      Internally generated serialized version of the data referenced by objectType and objectReference - by extracting and serializing their data as JSON.

      verificationPayloadHash stringrequired

      Internally generated cryptographic hash of the value to be signed, i.e. the value of verificationPayload

      verificationArtifact string

      A verification artifact in the form of a scanned object, image, signature etc.

      verificationSignedBy stringrequired

      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.

      verificationSignedAs string

      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"

      verificationJwsHeader string

      Alternative to the verificationMethod, verificationHash and verificationSignature, give a JWS serialized object (RFC7515)

      timestamp stringrequired

      Timestamp of signature, currently this field isn't part of the payload so it's not tamper-proof.

      signedWithoutObjectReference boolean

      Indicates that objectReference was left blank in the serialized version that was signed.

      objectType string

      Possible values: [revision, signature]

      Name of the schema model that objectReference points to. Values: "signature" or "revision"

      objectReference string

      A symmetric relation / back reference to the objectType that was signed. We are currently just modelling signing another signature (a chain) or signing a Revision (which can be a revision of a consent record, an agreement, policy etc)

    Loading...
    Last updated on by George J Padayatti