Purpose:
Ensure that the VHL Receiver generates audit records when receiving and using a Verified Health Link (VHL) to retrieve health information, in support of accountability and traceability.

Description:
The VHL Receiver MAY record audit events for critical events during its handling of a VHL. These MAY include:

• Receipt of a VHL from a VHL Holder
• Verification of the VHL's digital signature and trust chain
• Use of the VHL to retrieve referenced health documents from a VHL Sharer
• Access, rendering, or internal processing of the retrieved documents

The VHL Sharer and VHL Receiver SHALL jointly establish a mutually authenticated TLS (mTLS) connection prior to executing any Verified Health Link (VHL) transactions involving the exchange of sensitive data.

This requirement entails:

• The VHL Receiver initiating the mTLS handshake as the client and presenting a valid X.509 certificate
• The VHL Sharer responding as the server, presenting its own certificate and validating the client's certificate against a trusted Certificate Authority or Trust Anchor

Establishing this trusted channel ensures confidentiality, integrity, and bilateral authentication of all subsequent communications, and fulfills the trust obligations defined in the Establish Trust requirement.

Before participating in any Verified Health Link (VHL) transactions, the VHL Sharer and VHL Receiver SHALL establish a trust relationship based on shared acceptance of a designated Trust Anchor.

Trust is established by referencing and accepting public key material published and distributed in accordance with this specification (e.g., via Distribute PKI Material and Receive PKI Material transactions).

All participants MUST validate digital signatures using keys that are anchored in the agreed trust framework.

The VHL Receiver, when acting as a client in a Verified Health Link (VHL) transaction, SHALL initiate a mutually authenticated TLS (mTLS) connection to the VHL Sharer.

This initiation includes:

• Presenting a valid X.509 client certificate
• Validating the Sharer's server certificate against an accepted Trust Anchor

Successful completion of the mTLS handshake is a prerequisite for all subsequent transactions involving sensitive data exchange, including the retrieval of VHLs or associated health documents.

A VHL Sharer or VHL Receiver, after receiving PKI material from a Trust Anchor, SHALL validate and process the trust information for subsequent cryptographic operations.

Participants SHOULD:

• Cache the received trust list or certificate material to reduce network and server load
• Validate digital signatures or trust paths before use in VHL validation or mTLS sessions
• Monitor certificate expiration or revocation status where applicable

The VHL Receiver SHALL be capable of receiving a Verified Health Link (VHL) from a VHL Holder through a supported transport mechanism (e.g., QR code scan, direct URL, or digital message).

Upon receipt, the Receiver SHALL:

• Parse the VHL
• Validate its digital signature against a trusted key published by a recognized Trust Anchor
• Prepare to retrieve the associated health documents

Receipt of the VHL may occur through direct user interaction (e.g., scanning a QR code) or automated channels, depending on the implementation context.

A VHL Sharer or VHL Receiver, as a participant in the trust network, SHALL be capable of requesting public key infrastructure (PKI) material from a designated Trust Anchor.

The retrieved material MAY include:

• Public key certificates and associated trust lists
• Certificate revocation data (e.g., CRLs, OCSP responses)
• Metadata used to:
  • Validate digital signatures on VHLs and related resources
  • Establish mutually authenticated TLS (mTLS) connections
  • Decrypt content protected via asymmetric encryption

Participants SHOULD cache the received trust list to reduce network and server load.

Preconditions:

• The requesting participant knows in advance the endpoint from which to retrieve PKI material, as published or distributed by the Trust Anchor.

The VHL Receiver SHALL initiate a request to retrieve a single health document from a VHL Sharer, using a previously received and validated Verified Health Link (VHL).

This transaction SHALL be conducted over a mutually authenticated TLS (mTLS) channel. Both the Receiver and Sharer SHALL validate each other's participation in the trust network using PKI material published by the Trust Anchor.

Optional behaviors:

• The VHL Receiver MAY verify the digital signature of the returned health document to confirm its authenticity, integrity, and provenance, as defined in the Verify Document Signature requirement.
• The VHL Sharer MAY record an audit event documenting the access request by the Receiver, in accordance with the Audit Event – Received Health Data requirement.

The VHL Receiver SHALL initiate a request to retrieve a set of health documents from a VHL Sharer, using a previously received and validated Verified Health Link (VHL).

This transaction SHALL be conducted over a mutually authenticated TLS (mTLS) channel. Both the Receiver and Sharer SHALL validate each other's participation in the trust network using PKI material published by the Trust Anchor.

Optional behaviors:

• The VHL Sharer MAY record an audit event documenting the access request by the Receiver, in accordance with the Audit Event – Received Health Data requirement.

When a VHL Sharer or VHL Receiver generates a new public-private key pair for use within the VHL trust network, they SHALL submit the corresponding public key material to the Trust Anchor for validation and inclusion in the trust list.

The submission MAY include metadata to support categorization of key usage (e.g., digital signatures, encryption, mTLS) and business or operational context.

The VHL Receiver, upon receiving a digitally signed health document from a VHL Sharer, MAY verify the document's digital signature using previously retrieved PKI material.

This verification process confirms the authenticity, integrity, and provenance of the document independently of the Verified Health Link (VHL) itself.

The public key used for this verification MAY:

• Originate from a different trust network than the one used to validate the VHL
• Be unrelated to the key used to validate the VHL signature

Implementers SHOULD consult cross-profile guidance regarding interoperability with the IHE Document Digital Signature (DSG) profile, particularly in cases where additional attestation, long-term non-repudiation, or multi-party signatures are involved.