Verifiable Health Link, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.0.2-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.VHL/ and changes regularly. See the Directory of published versions

2: Verifiable Health Links (VHL) - Volume 2

2:X.1 Transactions

2:XX Publish PKI Material

2:XX.1 Scope

The Publish PKI Material transaction enables entities within a trust network—specifically, VHL Sharers and VHL Receivers—to submit their public key material to a designated Trust Anchor. This process facilitates the Trust Anchor’s role in aggregating, validating, and distributing a trusted list of public keys (Trust List) essential for verifying digital signatures and establishing secure communications within the VHL ecosystem.

2:XX.2 Actor Roles

Actor	Role
VHL Receiver, VHL Sharer	Submit PKI Material
Trust Anchor	Distribute PKI Material

2:XX.3 Referenced Standards

2:XX.4 Messages

2:XX.4.1 Publish PKI Material Request Message

2:XX.4.1.1 Trigger Events

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.

2:XX.4.1.2 Message Semantics

The message semantics and transport mechanism for the submission of public key material to the Trust Anchor SHALL be defined by the implementing jurisdiction of the trust network. The Trust Anchor is responsible for validating, cataloging, and securely redistributing key material as part of the canonical Trust List.

Different submission pathways MAY be defined based on the sensitivity, intended use, or organizational classification of the key material. For example:

• Indirect publication: Key material is published at a URL under the control of the submitting organization and its location is communicated to the Trust Anchor via:
  • Publication on a well-known, jurisdictionally recognized website
  • Secure transmission of the URL through official channels (e.g., signed correspondence, notarized documentation)
• Direct submission: Key material is submitted directly to the Trust Anchor over a secure, mutually authenticated connection:
  • Use of an API endpoint exposed by the Trust Anchor requiring mTLS or other credentialed authentication
  • Use of a secure upload portal with logging and role-based access controls
• Offline submission: In scenarios requiring maximal assurance of origin and identity:
  • Submission of key material on a secure physical medium (e.g., USB token, smart card) during a verified in-person encounter, with formal identity attestation

All submission mechanisms SHOULD be accompanied by sufficient provenance metadata to support validation by the Trust Anchor. At minimum, this SHOULD include:

• The asserted identity of the submitting entity
• The intended usage scope of the key(s) (e.g., signature, encryption, mTLS)
• An expiry date or revocation mechanism, if applicable
• A digital signature or certification path establishing the authenticity of the submission

Jurisdictions MAY further constrain the permitted submission methods based on policy, threat models, or operational constraints. The Trust Anchor SHOULD reject submissions that do not meet the validation criteria defined within the trust framework.

2:XX.4.1.3 Expected Actions

Upon receipt of public key material from a VHL Sharer or VHL Receiver, the Trust Anchor SHALL validate, organize, sign, and expose the PKI material as part of a trusted, canonical trust list.

This signed trust list enables all participants in the VHL trust network to verify digital signatures and establish secure connections in accordance with the governance policies of the Trust Anchor.

2:XX.4.2 Publish PKI Material Response Message

There is no Publish PKI Material Repsonse Message defined in this profile. This is up to the implementing jurisidiction of the Trust Anchor

2:XX.5 Security Considerations

The secure and verifiable exchange of public key infrastructure (PKI) material is foundational to the operation of a Verified Health Link (VHL) trust network. Any compromise in the integrity, authenticity, or provenance of this material undermines the ability of network participants to verify digital signatures, authenticate service endpoints, or enforce trust relationships.

Accordingly, implementers SHOULD ensure that:

• Submission and retrieval of PKI material occurs only over secure channels (e.g., mutually authenticated TLS),
• Submitted key material includes cryptographic proof of origin (e.g., embedded signatures or certification paths),
• Each key’s usage scope and validity period are clearly defined and enforced,
• All accepted material is validated against the criteria and policies established by the Trust Anchor’s governance authority.

Jurisdictions MAY define additional security controls, such as key size requirements, certificate chaining policies, Certificate Revocation List (CRL) or OCSP usage, offline verification workflows, or restrictions on submission endpoints.

The Trust Anchor SHOULD reject key material that fails to meet the validation requirements established by the trust framework or the implementing jurisdiction.

2:XX Retrieve PKI Material

2:XX.1 Scope

The Retrieve PKI Material transaction allows both VHL Sharers and VHL Receivers to retrieve trusted cryptographic material from the Trust Anchor. This material includes:

• Public key certificates (e.g., X.509),
• Certificate revocation data (e.g., CRLs or OCSP responses),
• JSON Web Keys (JWKs) or equivalent,
• and associated metadata required to validate the authenticity of a Verified Health Link (VHL) and to establish mutually authenticated TLS (mTLS) sessions.

Retrieved material SHALL be used to determine the trustworthiness of VHL artifacts and service endpoints in accordance with the governing trust framework.

2:XX.2 Actor Roles

Actor	Role
VHL Receiver, VHL Sharer	Request PKI material
	Receive PKI material
Trust Anchor	Provide PKI material

2:XX.3 Referenced Standards

2:XX.4 Messages

2:XX.4.1 Retrieve PKI Material Request Message

2:XX.4.1.1 Trigger Events

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.

2:XX.4.1.2 Message Semantics

OPTIONS TO DISCUSS:

• DID / JSON Web Keys
• mCSD Endpoint

2:XX.4.1.3 Expected Actions

2:XX.4.2 Retrieve PKI Material Response Message

2:XX.4.2.1 Trigger Events

A Trust Anchor initiates an Retrieve PKI Material Response Message once it has completed, to the extent possible, the expected actions upon receipt of a Retrieve PKI Material Request message.

2:XX.4.2.2 Message Semantics

The Retrieve PKI Material request MAY take one of several forms, depending on the transport and representation models adopted by the content profile. Potential representations include:

• A FHIR Parameters resource with serialized public key material (e.g., PEM, DER, or JWK)
• A DID Document conforming to W3C DID Core
• A pointer to a .well-known URI under organizational control, with machine-readable key data

The payload SHOULD include sufficient metadata to identify the submitting entity and bind the key material to its intended usage context (e.g., use: "sig", keyOps, x5c chain).

Content profiles SHALL define exact payload constraints, validation rules, and error behaviors.

2:XX.4.2.3 Expected Actions

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

2:XX.5 Security Considerations

All Retrieve PKI Material interactions SHOULD occur over secure channels using TLS 1.2 or higher, with mTLS recommended for enhanced endpoint authentication. The Trust Anchor SHOULD validate the authenticity, scope, and expiration of all retrieved key material before publishing or caching.

Clients (e.g., VHL Receivers and VHL Sharers) SHOULD verify the signature chain or integrity envelope of the material prior to using it for signature verification or secure session establishment.

Implementers SHOULD ensure that any out-of-band trust anchors or directory sources (e.g., .well-known/ endpoints) are tamper-resistant and publicly resolvable.

Content profiles MAY define additional constraints, such as:

• Minimum key lengths
• Permitted algorithms (e.g., RSA-2048, ECDSA P-256)
• CRL/OCSP freshness requirements
• Retry and caching behavior

2:XX Issue Verifiable Health Link

2:XX.1 Scope

The Issue Verifiable Health Link transaction returns a Verifiable Health Link authorization mechanism which can be used to provide access to one or more documents. A VHL Holder initiates the Issue VHL transaction against a VHL Sharer.

2:XX.2 Actor Roles

Actor	Role
VHL Holder	Request that a VHL authorization mechanism be issued
	Receive VHL authorization mechanism
VHL Sharer	Generate a VHL Authorization Mechanism Based on Query Parameters

2:XX.3 Referenced Standards

2:XX.4 Messages

2:XX.4.1 Issue VHL Request Message

2:XX.4.1.1 Trigger Events

A VHL Holder initiates a request to a VHL Sharer to generate a Verified Health Link (VHL) that references one or more health documents. The resulting VHL allows the Holder to subsequently share access to those documents with a VHL Receiver. The Holder MAY include optional parameters to constrain or protect the issued VHL-such as defining an expiration period, scoping which documents are included, or requiring a passcode for retrieval. These parameters guide the Sharer's issuance of the VHL and influence the conditions under which the associated documents may be accessed.

Preconditions:

• The VHL Holder SHALL trust that the VHL Sharer has been authorized by its jurisdiction to generate VHLs and to provide access to the corresponding health documents.
• Optionally, the VHL Holder has selected consent directives or selective disclosure preferences, as permitted by the applicable content profile.

2:XX.4.1.2 Message Semantics

None defined. Up to a content profile to define.

2:XX.4.1.3 Expected Actions

The VHL Sharer SHALL generate a Verified Health Link (VHL) to be issued to a VHL Holder.

The Sharer SHALL conduct all necessary tasks to prepare the content referenced by the VHL. These tasks MAY be further defined by applicable content profiles or implementation guides, and MAY include:

• Generation of new documents;
• Querying for existing documents associated with the VHL Holder; or
• Creation of digital signatures on one or more documents.

Once content preparation is complete, the Sharer SHALL construct the VHL payload and sign it to produce a cryptographically verifiable authorization mechanism.

Optional behaviors:

• The Sharer MAY record consent in accordance with the Record Consent requirement.
• The Sharer MAY log an audit event describing the VHL issuance, in accordance with the Audit Event – Accessed Health Data requirement.

2:XX.4.2 Issue VHL Response Message

2:XX.4.2.1 Trigger Events

A VHL Sharer initiates an Issue Verifiable Health Link Response Message once it has completed, to the extent possible, the expected actions upon receipt of a Issue Verifiable Health Link Request message, as specified by an appropriate content profile.

2:XX.4.2.2 Message Semantics

None defined. Up to a content profile to define.

2:XX.4.2.3 Expected Actions

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.

2:XX.5 Security Considerations

Depends on the content profile.