Approach for verifying data issued as a DSP credential

Status	decided
Decision leader	@Andy Dingley
Contributors	@Reuben Roberts @Doris.Wong @john o
Date	Nov 8, 2022
Outcome	Use unencoded data

Background

To issue a DSP credential, placement or programme membership data must be sent from the front end application to a backend API endpoint. As the API is open to be sent any data by an authenticated user, we can not trust any data that it receives, so before issuing a credential we must ensure that the data being included in the credential is valid and correct.

This can be achieved by signing the data being sent in such a way that it can be verified when received.

Relevant data

The approach must be able to fulfil the following

Sign data with a secret key
Able to verify data is unmodified
Able to verify data signed by authorised signatory
Include a timestamp so the data can be expired

Options

	Option #1: Encoded data	Option #2: Unencoded data

Option #1: Encoded data

Option #2: Unencoded data

Description

This approach would encode the placement/programme membership data in to JWS/JWT tokens, which could be verified when the credential is being issued.

This approach would add a signature to the placement/programme membership DTOs, the signature could be checked against the contents to verify them when the credential is being issued.

Pros and cons

POSITIVES

Widely used approach to data signing
Simpler implementation

NEGATIVES

More complex application flow

POSITIVES

Simpler application flow
Data remains human readable

NEGATIVES

Lesser used approach to data signing
More complex implementation
Tightly couples the backend and frontend DTOs/models - a change to one would break the verification unless reflected in the other(s).

Estimated cost

SMALL

SMALL / MEDIUM

Actions

Review proposal and comment

Brainstorm any scenario where we think we may want/need to sub-divide the TIS Team in any other ways
(hopefully this will trigger a discussion to determine whether the team feel in those scenarios it is valid to have a more 'exclusive' group, or whether those scenarios would benefit from a more 'inclusive' approach)

Outcome

TBC