6. Signing and Verification
6.1 Signing requirements
All PCTs must be cryptographically signed before attachment. Unsigned PCTs must be rejected by all verifiers.
The following signing algorithms are supported in version 0.1:
- RS256 (RSASSA-PKCS1-v1_5 with SHA-256). Recommended for all deployments where the issuer and verifier are different organisations or systems. Requires a public/private key pair.
- HS256 (HMAC with SHA-256). Permitted only for single-organisation deployments where the issuer and all verifiers share a secure secret. Must not be used across organisational boundaries.
Key management: Issuers must implement key rotation procedures. The
kidfield in the PCT header enables verifiers to retrieve the correct public key without invalidating existing tokens. Expired or revoked keys must be maintained in a key registry for audit purposes.
6.2 Signature construction
The signature is computed over the Base64URL encoding of the header concatenated with a period and the Base64URL encoding of the payload, consistent with RFC 7519 Section 7.2.
signature = sign(
Base64URL(header) + '.' + Base64URL(payload),
private_key
)
pct = Base64URL(header) + '.' + Base64URL(payload) + '.' + Base64URL(signature)
6.3 Verification procedure
A verifier must perform all of the following steps before accepting a PCT:
- Decode the three components of the compact serialised PCT.
- Retrieve the public key (or shared secret) associated with the
kidvalue in the header. - Verify the signature over
header.payloadusing the retrieved key. - Confirm that the
pct_versionin the header is a version supported by the verifier. - Confirm that the current timestamp is between
valid_fromandexpires_at. - Verify the data binding as defined in Section 5.8.5: re-hash the received data payload and compare against
data_hash. - Proceed to claims evaluation as defined in Section 4.5.
If any step fails, the PCT must be treated as invalid and the action must be blocked. Verifiers must not skip steps or apply partial verification.