Skip to main content
Version: 0.2 Draft 2

11. Security Considerations

11.1 Claim accuracy​

The PCT mechanism provides cryptographic assurance that claims have not been tampered with since issuance. It does not provide assurance that claims were accurate at the time of issuance. Issuers must implement governance processes — including integration with authoritative consent management systems, policy platforms, and data catalogues — to ensure that claims accurately reflect reality at the time of issuance.

11.2 Key compromise​

If an issuer's private signing key is compromised, all PCTs signed with that key must be considered potentially fraudulent. Issuers must maintain a key revocation mechanism and must notify relying verifiers of key compromise without delay. Verifiers must check key revocation status before accepting PCTs from issuers whose key status is uncertain.

11.3 Replay attacks​

A PCT that has been captured in transit could be replayed to authorise an action for which the PCT was not originally intended. Implementations should mitigate replay risk by binding the PCT to a specific request using the request_id and request_timestamp fields in the verification request, and by setting expires_at values appropriate to the sensitivity of the data.

11.4 Token detachment and data substitution​

A valid PCT could be detached from its original data and presented with a different, potentially malicious, dataset. The data binding mechanism defined in Section 5.8 mitigates this by cryptographically binding the token to a hash of the data payload at issuance. Verifiers must always perform the data binding check (Section 5.8.5) before evaluating claims. A mismatch between the computed hash and data_hash must be treated as a verification failure.

Where the lawful basis is consent, a PCT issued on the basis of consent becomes invalid if that consent is subsequently withdrawn. PCT lifecycles should be configured with expiry periods short enough that revoked consent is not honoured by stale tokens. For high-sensitivity processing, implementations should implement a consent status check against the live consent record at verification time using the consent_record_ref field.