This page is part of the FHIR Specification v6.0.0-ballot3: Release 6 Ballot (3rd Draft) (see Ballot Notes ). The current version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

6.1.2 Digital Signatures

Maturity Level : 1

Responsible Owner: Security Work Group

Standards Status : Trial Use Normative

Use case: "Digital Signature is Digital Signatures are needed to prove authenticity, integrity, the authenticity and non-repudiation." integrity of health records generally, and specifically for FHIR content and to establish the grounds for non-repudiation.

Approach: FHIR Resources are often parts of Medical Record or are communicated as part of formal Medical Documentation. As such there is sometimes a need to cryptographically bind a signature so that the receiving or consuming actor can verify authenticity, integrity, and non-repudiation. rely on non-repudiation of the content. This functionality is provided through the Signature type found in the signature element in the Provenance Resource. Where the The signature can either be any an electronic signature (e.g., an image of an ink signature), or a digital signature (cryptographic proof that the content has not changed), and in the case of a digital signature, either a JWS signature or an XML Digital Signature.

In general, signatures are not used when exchanging information directly between systems, as the transport arrangements between systems are expected to provide the necessary assurances of authenticity and integrity. The need for signatures arises when the content is being used across multiple systems, or when the content is stored for later retrieval and users need to verify that has not been changed. In addition, there may be regulatory requirements that require the use of signatures, including signatures that are applied subsequently to the content being created.

Due the wide set of choices around the use of electronic and digital signatures, local policy agreed and applicable implementation guides are required to define how signatures should be created when authoring FHIR content, and what actions should be taken to establish full verification when checking signatures. This specification defines a common set of actions that will cryptographically verify all conformant signatures, but this is not enough by itself to establish trustworthiness.

The goal of the FHIR specification with regard to signatures is two-fold:

1. Provide implementations with the capabilities needed to enable the set of local policies that are needed
2. Make the actual signature including Digital Signature methods verification process fully interoperable

If implementers follow all the conformance points below (both the "SHALL" and Electronic Signature. the "SHOULD" points), then any FHIR consumer will be able to verify any digital signature.

Digital Signatures bind cryptographically

6.1.2.1 Cautions around the exact contents, so use of digital signatures

The use of digital signatures with FHIR content comes with multiple challenges that implementers using digital signatures have to manage:

• Ongoing change to the content
• Uncertainty about what is signed
• Extent of signature verification
• Challenges identifying who signed the content

6.1.2.1.1 Ongoing change to the content

Once a resource or set of resources is signed, any changes change to the URLs, identifiers and the expression of internal references will make invalidate the Digital Signature invalid. When signature, along with other changes to the data and/or narrative. From the point of view of the signature, then, these things are frozen. However interoperability between system often requires systems to adjust URLs between relative and absolute, and to re-identify resources or references to resources, and/or to adjust other content, including coded values, in order to Manage system integration .

For example, when a Resource is created , or updated the server is expected expected, at a minimum, to update relevant elements that it manages (id, lastupdated, lastUpdated, etc.). These changes, although expected of normal RESTful create/update operations, will break any existing Digital Signature that has been calculated prior. covers these elements. Variations of this same pattern happens in Messaging, Documents, and other interaction models. For details, see Ramifications of storage/retrieval variations . This specification defines a number of canonicalization methods that allow systems to choose what parts of the Resource they want to sign, but systems will have to make difficult trade-offs between security and practicality in this regard.

For this reason, it is recommended that systems consider carefully the impact of any signature processes, particularly associated with RESTful APIs. One solution is to create the Digital Signature after the REST create operation completes, one which requires systems must first confirm that the resulting created/updated Resource is as expected, and then sign with the Digital Signature is formed. Signature. Another solution is to use a canonicalization that excuses these dynamic elements. elements, but this opens to problems around changing referenced resources that imply a very different meaning to the resource.

The impact of signatures on Document bundles and their related processes is the most well understood use of digital signatures, as the attestation of a documents is inherently associated with the frozen bundle.

6.1.2.1.2 Uncertainty about what is signed

Signing content and the consequential non-repudiation is often associated with human user actions, and human-level accountability. However, human users do not sign the resources themselves, they sign some representation of the resource, and the difference between these two forms is a challenge for implementers. When the goal of the digital signature includes human-level non-repudiation, implementers should pay careful attention to the resource narrative as the signed form in such cases.

One potential approach systems might take is to include plain text or image representations of the signature content beside the digital signature, so that humans can be clear about what was signed from a human user perspective.

6.1.2.1.3 Extent of signature verification

There are multiple aspects to signature verification:

1. Verifying the Digital Signature block itself by verifying the signature cryptographically
2. For XML digital signatures, confirming that the signed content of interest is unmodified using the hash algorithm (for JWS signatures, this is inherently required as part of the previous step)
3. Confirming that the signer (e.g., the certificate) was authentic, not revoked, and appropriate to the signature purpose.
4. Confirming the relationship between the signed content, the signer, and any consequences of the signature for the application.

Local policy and implementation guides are required to guide implementations here. While full conformance to this specification will enable the first and second aspects of signature verification, it does not (and cannot) speak to the third and fourth points; local guidance is required here. The signer stated in the signature can only be trusted if the certificate itself is verified against a trusted certificate authority.

6.1.2.1.4 Understanding who signed the content

At the certificate level, there is no ambiguity about the identity of the signer, as the certificate itself identifies the signer and this can be cryptographically verified, as explained above. But even then, there are still challenges here. The certificate will typically contain an LDAP based identification of the person/software/organization that requested the certificate (e.g., OU=IG Publisher,L=Ann Arbor,CN=hl7.org,O=HL7,ST=Michigan,C=us ). However:

• This is not necessarily the same as the person who signed the content.
• The user won't easily be able to resolve the LDAP identification to a known entity within their context of use.
• An application verifying the signature and presenting it to the user won't typically be able to relate the identity in the certificate to a FHIR reference / etc.
• Statements about the signer in the Provenance resource in .agent are easier to relate to the context, but can only be trusted to the extent that they can be validated by comparison to the signature contents.

There are some mitigations possible here. Certificate authorities can issue certificates that include additional identifiers that match to system level identifiers or URLs that allow precise identification of the signer, though this requires administrative practices that are not normal for most certificate authorities. Alternatively, identifiers in the certificate - either the LDAP name, additional identifiers or the certificate ID itself can be registered as identifiers (usually) in Practitioner or Organization resources (or others), but this also requires administrative overhead.

6.1.2.2 Canonicalization

A variation consistent representation of resources in their wire formats (JSON and XML) is required to make signatures interoperable; this is called 'Canonicalizing' resources. Because of the complexities around the interplay between data exchange and human-level signatures, FHIR defines a number of ways of canonicalizing resources that are suitable for different purposes.

The canonicalization methods SHOULD be represented in the Signature.targetFormat element, as shown here:

{
  "resourceType": "Signature",
  "targetFormat": "application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json"
}

6.1.2.2.1 JSON

This specification defines the following method for canonicalizing FHIR resources, when represented as JSON.

When JSON resources are canonicalized, they SHALL be canonicalized in accordance with the JSON Canonicalization Scheme defined in RFC 8785 .

This canonicalization method is identified by the URI http://hl7.org/fhir/canonicalization/json .

When a provenance has multiple targets resources that are signed, the resources are placed in a JSON Array preserving the Provenance.target order which itself is canonicalized according to the rules of RFC 8785.

6.1.2.2.2 JSON-XML (XML Safe JSON Canonicalization)

The simple JSON Canonicalization defined above has a potentially serious limitation: it does not allow for the reconstruction of a standard payload for signature verification if (and only if) the resource is represented as XML at some point in the life cycle between signing and verification. This happens because in Messaging, Documents, the XML format, XHTML elements (Resource and Section Narratives) are part of the XML DOM, and whitespace and namespaces may be reorganised without changing the canonical XHTML.

However most implementers never use the XML format, and the JSON Canonicalization is sufficient when it is not. If XML is in scope (and implementers should note that this is a requirement that might arise retrospectively), then this alternative canonicalization JSON-XML method should be used. The rules for this canonicalization are the same as for the JSON canonicalization, except that:

• Prior to serialization, the content of any xhtml in the narrative SHALL be canonicalized according to the XML canonicalization rules defined for XML below.

This canonicalization method is identified by the URI http://hl7.org/fhir/canonicalization/json-xml .

6.1.2.2.3 XML

This specification defines the following method for canonicalizing FHIR resources, when represented as XML. Resources are canonicalized using XML canonical method Canonical XML 1.1 ( http://www.w3.org/2006/12/xml-c14n11 ). In addition, the following rules apply:

• The XHTML Narrative SHALL be canonicalized following these same rules
• Whitespace in other interaction models. For details, see Ramifications primitive values SHALL not be altered (including multiple spaces in markdown)
• Resources are to contain no whitespace other than as found in attribute values and in the XHTML in the narrative, and single spaces between attributes in XML elements
• Use default namespaces for the FHIR and XHTML namespaces
• Omit all comments
• Include the XML processing instruction <?xml version="1.0" encoding="UTF-8"?>
• When sets of storage/retrieval variations resources are signed, each seperate resource is an additional Reference entry in the SignedInfo

This canonicalization method is identified by the URI http://hl7.org/fhir/canonicalization/xml .

When a provenance has multiple targets resources that are signed, the multiple canonicalized XMLs are contained in the digital signature as separate signed content in the order in which the targets are defined.

6.1.2.2.4 Canonicalization Variants

The following additional canonicalization URIs are also defined for all three forms defined above:

http://hl7.org/fhir/canonicalization/{fmt}#data	Resource.text is omitted prior to signing (note the deletion is at Resource.text , not Resource.text.div )
http://hl7.org/fhir/canonicalization/{fmt}#static	Resource.text and Resource.meta are omitted prior to signing. This makes the signature robust as the content is moved from server to server, or workflow and access tags are added or removed. Note that workflow and security tags may contain information important to the handling of the resource, so meta elements should be protected from tampering by other means if the resource is signed with this canonicalization.
http://hl7.org/fhir/canonicalization/{fmt}#narrative	Only Resource.id and Narrative ( Resource.text are signed
http://hl7.org/fhir/canonicalization/{fmt}#document	The Document Bundle.id and Bundle.metadata on the root Bundle are omitted prioer to signing. This allows for a document to be copied from server to server

These canonicalization methods allow systems the flexibility to sign the various portions of the resource that matter for the workflow the signature serves, per the discussion above. This specification recommends may define additional canonicalizations in the use of W3C future, and other specifications might also define additional canonicalization methods.

6.1.2.2.5 Digital Signatures Signature Methods or

This specification makes rules about the use of JWS - JSON Web Signatures, and XML Digital Signatures Signatures. Other signature methods can be used, but this specification says nothing about their use. Note that SMART Health Cards defines a signature protocol for FHIR Bundles based on the W3C Verifiable Credentials Data Model, and it has been internationally adopted for secure, granular verification of health information such as COVID-19 immunizations and test results.

Implementers should note that the choice of JSON vs XML digital signatures. Resources can signature is partially independent of the format of the resource that contains the signature, and also independent of the Signature.targetFormat . However mixing formats creates challenges, and implementers SHOULD generally use JSON signatures with the JSON canonicalization in JSON resources, and XML signatures with the XML canonicalization in XML resources.

6.1.2.2.6 JWS/JSON Signatures

When the signature is a JWS Digital Signature, the following rules apply:

• The Signature.data is base64 encoded JWS-Signature as specified in RFC 7515: JSON Web Signature (JWS)
• The value of Signature.sigFormat is application/jose and this SHOULD be populated
• The Signature.targetFormat SHOULD be populated, and the value SHOULD contain a canonicalization URL from those defined above. The custom protected header property canon MAY be also be used to identify the canonicalization method
• The signature is a Detached Signature (where the content that is signed using is separate from the Provenance signature itself), and the payload SHALL be omitted
• When FHIR Resources are signed, the signature is across either the Canonical XML form resource to carry or Canonical JSON form of the resource(s) as indicated in the targetFormat element as described above.
• The Signature.who SHOULD be populated, and if it is, it SHALL contain a value in either Reference.reference or Reference.identifier that matches an identifier found in the X509 certificate. e.g., the Subject Name ( SN ), or one of the Subject Alternative Names ( SAN )
• The JWS protected header SHALL contain either a kid or an x5c property
• The Signature SHALL include a "srCms signer commitments" property for the Purpose(s) of Signature. The Purpose can be the action being attested to, or the role associated with the signature. The Signature.type shall come from ASTM E1762-95(2013). The Signature.type SHALL contain the same values as the srCms element.
• The JWS protected header SHOULD have a sigT and the Signature.when SHOULD be populated, and if they are both populated, their values SHALL agree
• The Signature datatype MAY conform to JAdES-B-T is available or any other profiling of JOSE-Signature.
• The Signature SHOULD conform to JAdES-B-LT for support various of long term signatures. The JAdES-B-LT specification adds the timestamp of the signing, inclusion of the signing certificate, and statement of revocation

6.1.2.2.7 XML Digital Signatures

When the signature types including non-repudiation purposes. is an XML Digital Signature, the following rules apply:

• The Signature.data is base64 encoded XML Digital Signature as specified in XML Signature Syntax and Processing Version 1.1
• The value of Signature.sigFormat is application/pkcs7-signature and this SHOULD be populated
• The Signature.targetFormat SHOULD be populated, and the value SHOULD contain a canonicalization URL from those defined above
• The signature is a Detached Signature (where the content that is signed is separate from the signature itself)
• When FHIR Resources are signed, the signature is across either the Canonical XML form or Canonical JSON form of the resource(s) as indicated in the targetFormat element.
• The Signature SHOULD include a "xades CommitmentTypeId" element for the Purpose(s) of Signature. The Purpose can be the action being attested to, or the role associated with the signature. The value shall come from ASTM E1762-95(2013). The Signature.type SHALL contain the same values as the srCms element.
• The Signature SHOULD conform to XAdES-X-L for support of Long Term signatures . The XAdES-X-L specification adds the timestamp of the signing, inclusion of the signing certificate, and statement of revocation.
• Specifically, SignedSignatureProperties SHOULD have a SigningTime and the Signature.when SHOULD be populated, and if they are both populated, their values SHALL be equal
• If a SignedSignatureProperties block is present, it SHOULD not have any whitespace between the elements
• The Signature SHALL contain a X509Certificate
• The Signature.who SHOULD be populated, and if it is, it SHALL contain a value in either Reference.reference or Reference.identifier that matches an identifier found in the X509 certificate (e.g., the Subject , or one of the Subject Alternative Names
• The Signature MAY conform to XAdES-T or any other profiling of XML-Signature.

6.1.2.2.8 Digital Signatures in Provenance Resources

When a provenance resource is used to carry a signature, the following rules apply:

1. The JSON Digital-Signature Signature elements type , when , who , and onBehalfOf duplicate the Provenance elements agent.type , occurredDateTime , agent.who , and agent.onBehalfOf and SHOULD conform not be used
2. If they are present, they SHALL agree with the values in the Provenance resource
3. Since all digital signatures in the same provenance share the same signer, time, purpose etc, the primary use if multiple signatures is to JAdES-B-LT include different media representations of the signature such as text and images as described above and if these are present, they should be signed by the digital signature(s).

6.1.2.2.9 Signing Bundles

The most common use of signatures in FHIR is to sign a Document Bundle, and embed the signature inside the Bundle. In this approach, Documents are signed by Provenance resources contained within the document Bundle. Note that it is not necessary to sign Bundles with embedded signatures like this - systems and/or ecosystems may choose to use enveloping signatures ( JSON , XML for support ), where the the signed data is included within the signature itself, or make the Provenance resources avilable separately. However, if the signature is being embedded in the Bundle, then the following rules SHALL be observed:

1. Signatures SHALL be in a Provenance resource (there may be more than one such signature)
2. The Provenance resources with these signatures SHALL be in entries in the Bundle
3. The Provenance.target with a reference value of Long Term signatures. exactly Bundle/[id] where id is the id of the Bundle, such that the target identifies that the Bundle itself is being signed. Note that if the Provenance does not have a target of `Bundle/[id]` it does not represent an embedded signature, does not sign the Bundle, and is not subject to the rules documented here
4. The Signature MAY conform Provenance resource SHALL have a Provenance.signature element that contains the signature of the Bundle, with all entries that contain embedded signing provenance resources removed (that is, all entries that have a resource where the Provenance.targets includes a reference to JAdES-B-T Bundle/{id} or
5. The Provenance resource is allowed to indicate that it signs additional resources, including the special target value # which indicates that it signs itself in addition to the Bundle (but not including any other profiling Provenance.signature containing a digital signature).
6. Alternatively, the target might include the fullUrl of JOSE-Signature. another entry in the Bundle, indicating that this additional resource is also signed. Since the only entries that are not signed are other signatures, this is used to sign additional signatures. In such cases, the Provenance.signature is also signed. If the target is not in the Bundle, this specification does not define how such references are resolved.

Documents Bundle resources include the Bundle.signature , element, but a number of issues with its use have been identified, and the element is deprecated. Applications SHOULD use the method described above to sign Bundles (which may be signed pre-adopted when working with earlier versions of the FHIR specification).

using

6.1.2.3 Worked Examples

Note: the example below is based on Bundle.signature, and needs to be reworked. Here's a reformatted example of a bundle that is invalid (for now)

{
  "resourceType" : "Bundle",
  "id" : "signed",
  "identifier" : {
    "system" : "http://something1",
    "value" : "something2"
  },
  "type" : "collection",
  "timestamp" : "2024-06-09T11:06:35+10:00",
  "link" : [{
    "relation" : "self",
    "url" : "http://something3"
  }],
  "entry" : [{
    "fullUrl" : "http://something5",
    "resource" : {
      "resourceType" : "Observation",
      "id" : "obs1",
      "text" : {
        "status" : "generated",
        "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Observation_obs1\"> </a>This is a simple <b>example</b></div>"
      },
      "status" : "final",
      "code" : {
        "text" : "something"
      },
      "valueQuantity" : {
        "value" : 1
      }
    }
  },{
    "fullUrl" : "urn:uuid:b5dd98c2-002c-4da0-9cbf-bcb612e1d29c",
    "resource" : {
      "resourceType" : "Provenance",
      "id" : "prov1",
      "target" : [{
        "reference" : "Bundle/signed"
      }],
      "occurredDateTime" : "2025-07-01T08:48:05Z",
      "agent" : [{
        "type" : {
          "coding" :[{
            "system" : "urn:iso-astm:E1762-95:2013",
            "code" : "1.2.840.10065.1.12.1.1"
          }]
        },
        "who" : {
          "identifier" : {
            "system" : "http://example.org/certificates",
            "value" : "OU=IG Publisher,L=Ann Arbor,CN=hl7.org,O=HL7,ST=Missouri,C=us"
          }
        }
      }],
      "signature" : [{
        "targetFormat" : "application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json",
        "sigFormat" : "application/jose",
        "data" : "ZXlKMGVYQWlPaUpLVDFORklpd2ljM0pEYlhNaU9sdDdJbU52YlcxSlpDSTZleUpwWkNJNkluVnlianB2YVdRNk1TNHlMamcwTUM0eE1EQTJOUzR4TGpFeUxqRXVNU0lzSW1SbGMyTWlPaUpCZFhSb2IzSW5jeUJUYVdkdVlYUjFjbVVpZlgxZExDSmhiR2NpT2lKU1V6STFOaUlzSW5OcFoxUWlPaUl5TURJMUxUQTNMVEF4VkRBNE9qUTRPakExV2lJc0ltTmhibTl1SWpvaWFIUjBjRG92TDJoc055NXZjbWN2Wm1ocGNpOWpZVzV2Ym1sallXeHBlbUYwYVc5dUwycHpiMjRpTENKNE5XTWlPbHNpVFVsSlJHOTZRME5CYjNGblFYZEpRa0ZuU1VKQlJFRk9RbWRyY1docmFVYzVkekJDUVZFd1JrRkVRbkpOVVhOM1ExRlpSRlpSVVVkRmQwb3hZM3BGVWsxQk9FZEJNVlZGUTBGM1NWUlhiSHBqTWpreFkyMXJlRVJFUVV0Q1owNVdRa0Z2VFVFd2FFMU9la1ZSVFVFMFIwRXhWVVZCZDNkSVlVZDNNMHh0T1hsYWVrVlRUVUpCUjBFeFZVVkNkM2RLVVZjMWRVbEZSbmxaYlRsNVRWSlZkMFYzV1VSV1VWRk1SRUY0U2xKNVFsRmtWMHB6WVZoT2IxcFlTWGRJYUdOT1RXcFZkMDVxUlRWTlJFbDZUVVJOZWxkb1kwNU5hbGwzVG1wSmQwMUVTWHBOUkUxNlYycENjazFSYzNkRFVWbEVWbEZSUjBWM1NqRmpla1ZTVFVFNFIwRXhWVVZEUVhkSlZGZHNlbU15T1RGamJXdDRSRVJCUzBKblRsWkNRVzlOUVRCb1RVNTZSVkZOUVRSSFFURlZSVUYzZDBoaFIzY3pURzA1ZVZwNlJWTk5Ra0ZIUVRGVlJVSjNkMHBSVnpWMVNVVkdlVmx0T1hsTlVsVjNSWGRaUkZaUlVVeEVRWGhLVW5sQ1VXUlhTbk5oV0U1dldsaEpkMmRuUldwTlFUQkhRMU54UjFOSllqTkVVVVZDUVZGVlFVRTBTVUpGUVVGM1oyZEZURUZ2U1VKQlowTTVWWE00ZGpCVmVVOTVLMWhYVEZKbVpqSTVSMGhSWVRsaGVIRjBSR0Z2TjJGNmMxZHVSakl2UVVKa1p6Rm5ObVJQUmk4d1dtdHlhRXhrY1VwSlUybzRUV3hUVURWV1RHOTFOamRwV2tsSU1GSjRVazFtVTBFd1pTOW1hVGxFUlRoUlUzcHdTVTlzZFdWbFNESk5PRkV5Vm1WelMzQXphRWxyY0N0NFEyRkhVR0pqTkV3d2ExcFdhMFUyUlZjclZGVlNOMUZVY3pGT2EyRjRkSGRaZGxjNE4yZExlbTQyUWt3d1dYZ3ZOVzExTVZWR1YyTktMMWgwVEVocmFXRm5kRWxpVTJsRldGTmtjMnA0ZG1sUFlrcE5NbE5oVmpOMFlVTmhZWGxIUzFaR2NGVTJjbEJNUkM5V1VtRnlkRFphVURGRFNsRXllbXhKYzJ0RlJVOXVibFZMUlZWMWQyTkdjRXczZERWR1dHbElWazlZTUdoYU5XWnpkVWRaZERoRmRVeDNZVGRuYVVWUmRtWXZVR0ZSWWxSeVZGWk5UMlJMU0M5RlIxWktTVGd4VFdaT1ozcEZZbkpCTDBOMlkwY3ZiR2RITTBSTkswcDNTVVJCVVVGQ2J6RkJkMVJxUVdSQ1owNVdTRkUwUlVablVWVnhRa3R2TW1sUk1GSTFjalZIYVU1c2FESnpUa042UlhFNVVVbDNTSGRaUkZaU01HcENRbWQzUm05QlZYRkNTMjh5YVZFd1VqVnlOVWRwVG14b01uTk9RM3BGY1RsUlNYZEVRVmxFVmxJd1ZFSkJWWGRCZDBWQ0wzcEJUa0puYTNGb2EybEhPWGN3UWtGUk1FWkJRVTlEUVZGSlFXazRSbFp6Y1ZwS05FOW1hV2xuYW1kd05DdERaVWhFZURaTVNsSjFjVFpaYjJsT1pYSjRTalJzSzBWVU5FSmlOMm80UlM5RVJHVkZabVZpUlZGMmQxQnlhR3hQZVVaUFpubHZjM3BoUW01R09FVndMMGhyTjA5cU5tTndUR2h2UVVocVpWWXpSMVY1S3pONFp6Tk9Rak5FZFVVM1NtaHVlRGs1YTNkbVVrdzVkRTlZU2pVclRHd3hRVWxvZVZRd1NrbEVPRW8yTHprNVVUVldiWGRUUTFWbFVtWnVhRzV1YVdkYWJIZFRORlpvUVc5aGJtaHljWHAzV0had1QyTnZLMGg1YUV3d2VUTnRiV0pDU0M5bFMxVXJTRFZRSzB3eVNVWnBVMFpNTmxoQlREUlFUVE53V1VrdmVtb3JUbmxvUVZoYVdscDNiR3hTYW05SlMyWnNSMDlQT0VoVll6VnBTbWxVU0doWmJ6QnBTMU14YkZCNFEwaHZTM2xCSzJGV1JXRldSUzluYjNGQ2QyOWxNMVk1YlhoSVFYbzBWWEU0WlM5aFVUQlBabU5wUm0xcU5UVnpObTE0TldWVlpIazFiRkZ4Wm05bGEwVTlJbDE5Li5vUDFVd2xHQll2TllLREFpc2h6YThQbThjbDltMXkwbWkxVGMtZTdER2dUMEVGMG1xSV8tN3o3aFNQR1NPWEJISmRqcE00MHVZMHE1UlJ4MXFUdi1jbVhGQW52NHd4TXFHYzZ3U3VkbTZmMXRkTGdMbGZwUTlaOTh0cEZnSDBQejU2aWpmLUxqb0I1dVBtbV9Sb1Nyd2V3RlFuN0xocFk5Wm9wQWVUVVNTY1R5OUFGOW1Cdnd1MXZUbWFMeE9TSkR6b0djbmxmV3RKZ09fN29yMmVfS2ZKZDUzdGRYZkFOaVpmQURZcFEzaHhmLTJTWF9HYzVaZ3J4WGl0V2tGUDVSaFRYb3lycUMzSFlKNko2M1BnSzhEVmxMcWNFLXgzUXBZMDB3UXB2MUEtSGdjUGhKY3Rhc3k3QmJwbkszeldfdUxNRFZGYjl0OHVJV095a210UlJwZUtJ"
      }]
    }
  }]
}

6.1.2.3.1 JWS example

Here's an enveloped or enveloping signature. A specification example of a signed Bundle.

{
  "resourceType" : "Bundle",
  "id" : "signed",
  "identifier" : {
    "system" : "http://something1",
    "value" : "something2"
  },
  "type" : "collection",
  "timestamp" : "2024-06-09T11:06:35+10:00",
  "link" : [{
    "relation" : "self",
    "url" : "http://something3"
  }],
  "entry" : [{
    "fullUrl" : "http://something5",
    "resource" : {
      "resourceType" : "Observation",
      "id" : "obs1",
      "text" : {
        "status" : "generated",
        "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Observation_obs1\"> </a>This is a simple <b>example</b></div>"
      },
      "status" : "final",
      "code" : {
        "text" : "something"
      },
      "valueQuantity" : {
        "value" : 1
      }
    }
  }],
  "signature" : {
    "type" : [{
      "system" : "urn:iso-astm:E1762-95:2013",
      "code" : "1.2.840.10065.1.12.1.1"
    }],
    "when" : "2025-07-01T08:48:05Z",
    "who" : {
      "identifier" : {
        "system" : "http://example.org/certificates",
        "value" : "OU=IG Publisher,L=Ann Arbor,CN=hl7.org,O=HL7,ST=Missouri,C=us"
      }
    },
    "targetFormat" : "application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json",
    "sigFormat" : "application/jose",
    "data" : "ZXlKMGVYQWlPaUpLVDFORklpd2ljM0pEYlhNaU9sdDdJbU52YlcxSlpDSTZleUpwWkNJNkluVnlianB2YVdRNk1TNHlMamcwTUM0eE1EQTJOUzR4TGpFeUxqRXVNU0lzSW1SbGMyTWlPaUpCZFhSb2IzSW5jeUJUYVdkdVlYUjFjbVVpZlgxZExDSmhiR2NpT2lKU1V6STFOaUlzSW5OcFoxUWlPaUl5TURJMUxUQTNMVEF4VkRBNE9qUTRPakExV2lJc0ltTmhibTl1SWpvaWFIUjBjRG92TDJoc055NXZjbWN2Wm1ocGNpOWpZVzV2Ym1sallXeHBlbUYwYVc5dUwycHpiMjRpTENKNE5XTWlPbHNpVFVsSlJHOTZRME5CYjNGblFYZEpRa0ZuU1VKQlJFRk9RbWRyY1docmFVYzVkekJDUVZFd1JrRkVRbkpOVVhOM1ExRlpSRlpSVVVkRmQwb3hZM3BGVWsxQk9FZEJNVlZGUTBGM1NWUlhiSHBqTWpreFkyMXJlRVJFUVV0Q1owNVdRa0Z2VFVFd2FFMU9la1ZSVFVFMFIwRXhWVVZCZDNkSVlVZDNNMHh0T1hsYWVrVlRUVUpCUjBFeFZVVkNkM2RLVVZjMWRVbEZSbmxaYlRsNVRWSlZkMFYzV1VSV1VWRk1SRUY0U2xKNVFsRmtWMHB6WVZoT2IxcFlTWGRJYUdOT1RXcFZkMDVxUlRWTlJFbDZUVVJOZWxkb1kwNU5hbGwzVG1wSmQwMUVTWHBOUkUxNlYycENjazFSYzNkRFVWbEVWbEZSUjBWM1NqRmpla1ZTVFVFNFIwRXhWVVZEUVhkSlZGZHNlbU15T1RGamJXdDRSRVJCUzBKblRsWkNRVzlOUVRCb1RVNTZSVkZOUVRSSFFURlZSVUYzZDBoaFIzY3pURzA1ZVZwNlJWTk5Ra0ZIUVRGVlJVSjNkMHBSVnpWMVNVVkdlVmx0T1hsTlVsVjNSWGRaUkZaUlVVeEVRWGhLVW5sQ1VXUlhTbk5oV0U1dldsaEpkMmRuUldwTlFUQkhRMU54UjFOSllqTkVVVVZDUVZGVlFVRTBTVUpGUVVGM1oyZEZURUZ2U1VKQlowTTVWWE00ZGpCVmVVOTVLMWhYVEZKbVpqSTVSMGhSWVRsaGVIRjBSR0Z2TjJGNmMxZHVSakl2UVVKa1p6Rm5ObVJQUmk4d1dtdHlhRXhrY1VwSlUybzRUV3hUVURWV1RHOTFOamRwV2tsSU1GSjRVazFtVTBFd1pTOW1hVGxFUlRoUlUzcHdTVTlzZFdWbFNESk5PRkV5Vm1WelMzQXphRWxyY0N0NFEyRkhVR0pqTkV3d2ExcFdhMFUyUlZjclZGVlNOMUZVY3pGT2EyRjRkSGRaZGxjNE4yZExlbTQyUWt3d1dYZ3ZOVzExTVZWR1YyTktMMWgwVEVocmFXRm5kRWxpVTJsRldGTmtjMnA0ZG1sUFlrcE5NbE5oVmpOMFlVTmhZWGxIUzFaR2NGVTJjbEJNUkM5V1VtRnlkRFphVURGRFNsRXllbXhKYzJ0RlJVOXVibFZMUlZWMWQyTkdjRXczZERWR1dHbElWazlZTUdoYU5XWnpkVWRaZERoRmRVeDNZVGRuYVVWUmRtWXZVR0ZSWWxSeVZGWk5UMlJMU0M5RlIxWktTVGd4VFdaT1ozcEZZbkpCTDBOMlkwY3ZiR2RITTBSTkswcDNTVVJCVVVGQ2J6RkJkMVJxUVdSQ1owNVdTRkUwUlVablVWVnhRa3R2TW1sUk1GSTFjalZIYVU1c2FESnpUa042UlhFNVVVbDNTSGRaUkZaU01HcENRbWQzUm05QlZYRkNTMjh5YVZFd1VqVnlOVWRwVG14b01uTk9RM3BGY1RsUlNYZEVRVmxFVmxJd1ZFSkJWWGRCZDBWQ0wzcEJUa0puYTNGb2EybEhPWGN3UWtGUk1FWkJRVTlEUVZGSlFXazRSbFp6Y1ZwS05FOW1hV2xuYW1kd05DdERaVWhFZURaTVNsSjFjVFpaYjJsT1pYSjRTalJzSzBWVU5FSmlOMm80UlM5RVJHVkZabVZpUlZGMmQxQnlhR3hQZVVaUFpubHZjM3BoUW01R09FVndMMGhyTjA5cU5tTndUR2h2UVVocVpWWXpSMVY1S3pONFp6Tk9Rak5FZFVVM1NtaHVlRGs1YTNkbVVrdzVkRTlZU2pVclRHd3hRVWxvZVZRd1NrbEVPRW8yTHprNVVUVldiWGRUUTFWbFVtWnVhRzV1YVdkYWJIZFRORlpvUVc5aGJtaHljWHAzV0had1QyTnZLMGg1YUV3d2VUTnRiV0pDU0M5bFMxVXJTRFZRSzB3eVNVWnBVMFpNTmxoQlREUlFUVE53V1VrdmVtb3JUbmxvUVZoYVdscDNiR3hTYW05SlMyWnNSMDlQT0VoVll6VnBTbWxVU0doWmJ6QnBTMU14YkZCNFEwaHZTM2xCSzJGV1JXRldSUzluYjNGQ2QyOWxNMVk1YlhoSVFYbzBWWEU0WlM5aFVUQlBabU5wUm0xcU5UVnpObTE0TldWVlpIazFiRkZ4Wm05bGEwVTlJbDE5Li5vUDFVd2xHQll2TllLREFpc2h6YThQbThjbDltMXkwbWkxVGMtZTdER2dUMEVGMG1xSV8tN3o3aFNQR1NPWEJISmRqcE00MHVZMHE1UlJ4MXFUdi1jbVhGQW52NHd4TXFHYzZ3U3VkbTZmMXRkTGdMbGZwUTlaOTh0cEZnSDBQejU2aWpmLUxqb0I1dVBtbV9Sb1Nyd2V3RlFuN0xocFk5Wm9wQWVUVVNTY1R5OUFGOW1Cdnd1MXZUbWFMeE9TSkR6b0djbmxmV3RKZ09fN29yMmVfS2ZKZDUzdGRYZkFOaVpmQURZcFEzaHhmLTJTWF9HYzVaZ3J4WGl0V2tGUDVSaFRYb3lycUMzSFlKNko2M1BnSzhEVmxMcWNFLXgzUXBZMDB3UXB2MUEtSGdjUGhKY3Rhc3k3QmJwbkszeldfdUxNRFZGYjl0OHVJV095a210UlJwZUtJ"
  }
}

The raw data for enveloped and enveloping signatures on documents are profiled in the IHE Document Digital Signature (DSG) Profile . signature is (after decoding the base64):

eyJ0eXAiOiJKT1NFIiwic3JDbXMiOlt7ImNvbW1JZCI6eyJpZCI6InVybjpvaWQ6MS4yLjg0MC4xMDA2NS4xLjEyLjEuMSIsImRlc2MiOiJBdXRob3IncyBTaWduYXR1cmUifX1dLCJhbGciOiJSUzI1NiIsInNpZ1QiOiIyMDI1LTA3LTAxVDA4OjQ4OjA1WiIsImNhbm9uIjoiaHR0cDovL2hsNy5vcmcvZmhpci9jYW5vbmljYWxpemF0aW9uL2pzb24iLCJ4NWMiOlsiTUlJRG96Q0NBb3FnQXdJQkFnSUJBREFOQmdrcWhraUc5dzBCQVEwRkFEQnJNUXN3Q1FZRFZRUUdFd0oxY3pFUk1BOEdBMVVFQ0F3SVRXbHpjMjkxY21reEREQUtCZ05WQkFvTUEwaE1OekVRTUE0R0ExVUVBd3dIYUd3M0xtOXlaekVTTUJBR0ExVUVCd3dKUVc1dUlFRnlZbTl5TVJVd0V3WURWUVFMREF4SlJ5QlFkV0pzYVhOb1pYSXdIaGNOTWpVd05qRTVNREl6TURNeldoY05Nall3TmpJd01ESXpNRE16V2pCck1Rc3dDUVlEVlFRR0V3SjFjekVSTUE4R0ExVUVDQXdJVFdsemMyOTFjbWt4RERBS0JnTlZCQW9NQTBoTU56RVFNQTRHQTFVRUF3d0hhR3czTG05eVp6RVNNQkFHQTFVRUJ3d0pRVzV1SUVGeVltOXlNUlV3RXdZRFZRUUxEQXhKUnlCUWRXSnNhWE5vWlhJd2dnRWpNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJFQUF3Z2dFTEFvSUJBZ0M5VXM4djBVeU95K1hXTFJmZjI5R0hRYTlheHF0RGFvN2F6c1duRjIvQUJkZzFnNmRPRi8wWmtyaExkcUpJU2o4TWxTUDVWTG91NjdpWklIMFJ4Uk1mU0EwZS9maTlERThRU3pwSU9sdWVlSDJNOFEyVmVzS3AzaElrcCt4Q2FHUGJjNEwwa1pWa0U2RVcrVFVSN1FUczFOa2F4dHdZdlc4N2dLem42QkwwWXgvNW11MVVGV2NKL1h0TEhraWFndEliU2lFWFNkc2p4dmlPYkpNMlNhVjN0YUNhYXlHS1ZGcFU2clBMRC9WUmFydDZaUDFDSlEyemxJc2tFRU9ublVLRVV1d2NGcEw3dDVGWGlIVk9YMGhaNWZzdUdZdDhFdUx3YTdnaUVRdmYvUGFRYlRyVFZNT2RLSC9FR1ZKSTgxTWZOZ3pFYnJBL0N2Y0cvbGdHM0RNK0p3SURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVxQktvMmlRMFI1cjVHaU5saDJzTkN6RXE5UUl3SHdZRFZSMGpCQmd3Rm9BVXFCS28yaVEwUjVyNUdpTmxoMnNOQ3pFcTlRSXdEQVlEVlIwVEJBVXdBd0VCL3pBTkJna3Foa2lHOXcwQkFRMEZBQU9DQVFJQWk4RlZzcVpKNE9maWlnamdwNCtDZUhEeDZMSlJ1cTZZb2lOZXJ4SjRsK0VUNEJiN2o4RS9ERGVFZmViRVF2d1ByaGxPeUZPZnlvc3phQm5GOEVwL0hrN09qNmNwTGhvQUhqZVYzR1V5KzN4ZzNOQjNEdUU3SmhueDk5a3dmUkw5dE9YSjUrTGwxQUloeVQwSklEOEo2Lzk5UTVWbXdTQ1VlUmZuaG5uaWdabHdTNFZoQW9hbmhycXp3WHZwT2NvK0h5aEwweTNtbWJCSC9lS1UrSDVQK0wySUZpU0ZMNlhBTDRQTTNwWUkvemorTnloQVhaWlp3bGxSam9JS2ZsR09POEhVYzVpSmlUSGhZbzBpS1MxbFB4Q0hvS3lBK2FWRWFWRS9nb3FCd29lM1Y5bXhIQXo0VXE4ZS9hUTBPZmNpRm1qNTVzNm14NWVVZHk1bFFxZm9la0U9Il19..oP1UwlGBYvNYKDAishza8Pm8cl9m1y0mi1Tc-e7DGgT0EF0mqI_-7z7hSPGSOXBHJdjpM40uY0q5RRx1qTv-cmXFAnv4wxMqGc6wSudm6f1tdLgLlfpQ9Z98tpFgH0Pz56ijf-LjoB5uPmm_RoSrwewFQn7LhpY9ZopAeTUSScTy9AF9mBvwu1vTmaLxOSJDzoGcnlfWtJgO_7or2e_KfJd53tdXfANiZfADYpQ3hxf-2SX_Gc5ZgrxXitWkFP5RhTXoyrqC3HYJ6J63PgK8DVlLqcE-x3QpY00wQpv1A-HgcPhJctasy7BbpnK3zW_uLMDVFb9t8uIWOykmtRRpeKI

SMART Health Cards defines a This JWS signature protocol for FHIR Bundles has 3 parts: header, payload, and signature.

based Header

The header is json:

{
  "typ": "JOSE",
  "srCms": [
    {
      "commId": {
        "id": "urn:oid:1.2.840.10065.1.12.1.1",
        "desc": "Author's Signature"
      }
    }
  ],
  "alg": "RS256",
  "sigT": "2025-07-01T08:48:05Z",
  "canon": "http://hl7.org/fhir/canonicalization/json",
  "x5c": [
    "MIIDozCCAoqgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBrMQswCQYDVQQGEwJ1czERMA8GA1UECAwITWlzc291cmkxDDAKBgNVBAoMA0hMNzEQMA4GA1UEAwwHaGw3Lm9yZzESMBAGA1UEBwwJQW5uIEFyYm9yMRUwEwYDVQQLDAxJRyBQdWJsaXNoZXIwHhcNMjUwNjE5MDIzMDMzWhcNMjYwNjIwMDIzMDMzWjBrMQswCQYDVQQGEwJ1czERMA8GA1UECAwITWlzc291cmkxDDAKBgNVBAoMA0hMNzEQMA4GA1UEAwwHaGw3Lm9yZzESMBAGA1UEBwwJQW5uIEFyYm9yMRUwEwYDVQQLDAxJRyBQdWJsaXNoZXIwggEjMA0GCSqGSIb3DQEBAQUAA4IBEAAwggELAoIBAgC9Us8v0UyOy+XWLRff29GHQa9axqtDao7azsWnF2/ABdg1g6dOF/0ZkrhLdqJISj8MlSP5VLou67iZIH0RxRMfSA0e/fi9DE8QSzpIOlueeH2M8Q2VesKp3hIkp+xCaGPbc4L0kZVkE6EW+TUR7QTs1NkaxtwYvW87gKzn6BL0Yx/5mu1UFWcJ/XtLHkiagtIbSiEXSdsjxviObJM2SaV3taCaayGKVFpU6rPLD/VRart6ZP1CJQ2zlIskEEOnnUKEUuwcFpL7t5FXiHVOX0hZ5fsuGYt8EuLwa7giEQvf/PaQbTrTVMOdKH/EGVJI81MfNgzEbrA/CvcG/lgG3DM+JwIDAQABo1AwTjAdBgNVHQ4EFgQUqBKo2iQ0R5r5GiNlh2sNCzEq9QIwHwYDVR0jBBgwFoAUqBKo2iQ0R5r5GiNlh2sNCzEq9QIwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOCAQIAi8FVsqZJ4Ofiigjgp4+CeHDx6LJRuq6YoiNerxJ4l+ET4Bb7j8E/DDeEfebEQvwPrhlOyFOfyoszaBnF8Ep/Hk7Oj6cpLhoAHjeV3GUy+3xg3NB3DuE7Jhnx99kwfRL9tOXJ5+Ll1AIhyT0JID8J6/99Q5VmwSCUeRfnhnnigZlwS4VhAoanhrqzwXvpOco+HyhL0y3mmbBH/eKU+H5P+L2IFiSFL6XAL4PM3pYI/zj+NyhAXZZZwllRjoIKflGOO8HUc5iJiTHhYo0iKS1lPxCHoKyA+aVEaVE/goqBwoe3V9mxHAz4Uq8e/aQ0OfciFmj55s6mx5eUdy5lQqfoekE="
  ]
}

Comments on the W3C Verifiable Credentials Data Model, contents of the header:

• the srCms is as defined by JAdES-B-T. It SHOULD be present, and if present, and Signature.type is present, they SHALL agree, as this example does
• the sigT is as defined by JAdES-B-T. It SHOULD be present, and if present, and Signature.when is present, they SHALL agree, as this example does
• The canon is optional, but if it has been internationally adopted for secure, granulart it is present, and Signature.targetFormat is present and specifies a canonicalization, they SHALL agree, as this example does. Note that the signature should explicitly state the canonicalization since this is the most troublesome part of the signature verification
• This signature includes the public key directly (as this does). Alternatively, it might specify a kid that identifies the key, which must be retrieved from some key management arrangement
• Irrespective of health information such as COVID-19 immunizations how the public key is found, the signature is only trustable if the certificate itself is verified, and test results. doing that is outside the scope of the FHIR specification

Payload

The payload is not provided, since this is a detached signature. In order to verify the signature, the verifying application must rebuild the payload as the signing application did, using the same canonicalization, and with Bundle.signature removed. In this case, that is:

{"entry":[{"fullUrl":"http://something5","resource":{"code":{"text":"something"},"id":"obs1","resourceType":"Observation","status":"final","text":{"div":"<div xmlns=\"http://www.w3.org/1999/xhtml\"><a name=\"Observation_obs1\"> </a>This is a simple <b>example</b></div>","status":"generated"},"valueQuantity":{"value":1}}}],"id":"signed","identifier":{"system":"http://something1","value":"something2"},"link":[{"relation":"self","url":"http://something3"}],"resourceType":"Bundle","timestamp":"2024-06-09T11:06:35+10:00","type":"collection"}

Using Base64URL encoding, This encodes to

eyJlbnRyeSI6W3siZnVsbFVybCI6Imh0dHA6Ly9zb21ldGhpbmc1IiwicmVzb3VyY2UiOnsiY29kZSI6eyJ0ZXh0Ijoic29tZXRoaW5nIn0sImlkIjoib2JzMSIsInJlc291cmNlVHlwZSI6Ik9ic2VydmF0aW9uIiwic3RhdHVzIjoiZmluYWwiLCJ0ZXh0Ijp7ImRpdiI6IjxkaXYgeG1sbnM9XCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sXCI-PGEgbmFtZT1cIk9ic2VydmF0aW9uX29iczFcIj4gPC9hPlRoaXMgaXMgYSBzaW1wbGUgPGI-ZXhhbXBsZTwvYj48L2Rpdj4iLCJzdGF0dXMiOiJnZW5lcmF0ZWQifSwidmFsdWVRdWFudGl0eSI6eyJ2YWx1ZSI6MX19fV0sImlkIjoic2lnbmVkIiwiaWRlbnRpZmllciI6eyJzeXN0ZW0iOiJodHRwOi8vc29tZXRoaW5nMSIsInZhbHVlIjoic29tZXRoaW5nMiJ9LCJsaW5rIjpbeyJyZWxhdGlvbiI6InNlbGYiLCJ1cmwiOiJodHRwOi8vc29tZXRoaW5nMyJ9XSwicmVzb3VyY2VUeXBlIjoiQnVuZGxlIiwidGltZXN0YW1wIjoiMjAyNC0wNi0wOVQxMTowNjozNSsxMDowMCIsInR5cGUiOiJjb2xsZWN0aW9uIn0

Note that the payload SHALL be empty in the resource, but if the Java validator finds a payload, it will inspect the payload to Implementers: We would welcome reports of implementation experience. See discussion on use of Digital determine whether there is a content or a canonicalization problem, and this can be useful when debugging signatures.

Signature in FHIR

Feedback The key that signed this is welcome here . a developmental key with a published private key:

-----BEGIN CERTIFICATE-----
MIIDozCCAoqgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBrMQswCQYDVQQGEwJ1czER
MA8GA1UECAwITWlzc291cmkxDDAKBgNVBAoMA0hMNzEQMA4GA1UEAwwHaGw3Lm9y
ZzESMBAGA1UEBwwJQW5uIEFyYm9yMRUwEwYDVQQLDAxJRyBQdWJsaXNoZXIwHhcN
MjUwNjE5MDIzMDMzWhcNMjYwNjIwMDIzMDMzWjBrMQswCQYDVQQGEwJ1czERMA8G
A1UECAwITWlzc291cmkxDDAKBgNVBAoMA0hMNzEQMA4GA1UEAwwHaGw3Lm9yZzES
MBAGA1UEBwwJQW5uIEFyYm9yMRUwEwYDVQQLDAxJRyBQdWJsaXNoZXIwggEjMA0G
CSqGSIb3DQEBAQUAA4IBEAAwggELAoIBAgC9Us8v0UyOy+XWLRff29GHQa9axqtD
ao7azsWnF2/ABdg1g6dOF/0ZkrhLdqJISj8MlSP5VLou67iZIH0RxRMfSA0e/fi9
DE8QSzpIOlueeH2M8Q2VesKp3hIkp+xCaGPbc4L0kZVkE6EW+TUR7QTs1NkaxtwY
vW87gKzn6BL0Yx/5mu1UFWcJ/XtLHkiagtIbSiEXSdsjxviObJM2SaV3taCaayGK
VFpU6rPLD/VRart6ZP1CJQ2zlIskEEOnnUKEUuwcFpL7t5FXiHVOX0hZ5fsuGYt8
EuLwa7giEQvf/PaQbTrTVMOdKH/EGVJI81MfNgzEbrA/CvcG/lgG3DM+JwIDAQAB
o1AwTjAdBgNVHQ4EFgQUqBKo2iQ0R5r5GiNlh2sNCzEq9QIwHwYDVR0jBBgwFoAU
qBKo2iQ0R5r5GiNlh2sNCzEq9QIwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0F
AAOCAQIAi8FVsqZJ4Ofiigjgp4+CeHDx6LJRuq6YoiNerxJ4l+ET4Bb7j8E/DDeE
febEQvwPrhlOyFOfyoszaBnF8Ep/Hk7Oj6cpLhoAHjeV3GUy+3xg3NB3DuE7Jhnx
99kwfRL9tOXJ5+Ll1AIhyT0JID8J6/99Q5VmwSCUeRfnhnnigZlwS4VhAoanhrqz
wXvpOco+HyhL0y3mmbBH/eKU+H5P+L2IFiSFL6XAL4PM3pYI/zj+NyhAXZZZwllR
joIKflGOO8HUc5iJiTHhYo0iKS1lPxCHoKyA+aVEaVE/goqBwoe3V9mxHAz4Uq8e
/aQ0OfciFmj55s6mx5eUdy5lQqfoekE=
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY-----
MIIEwQIBADANBgkqhkiG9w0BAQEFAASCBKswggSnAgEAAoIBAgC9Us8v0UyOy+XW
LRff29GHQa9axqtDao7azsWnF2/ABdg1g6dOF/0ZkrhLdqJISj8MlSP5VLou67iZ
IH0RxRMfSA0e/fi9DE8QSzpIOlueeH2M8Q2VesKp3hIkp+xCaGPbc4L0kZVkE6EW
+TUR7QTs1NkaxtwYvW87gKzn6BL0Yx/5mu1UFWcJ/XtLHkiagtIbSiEXSdsjxviO
bJM2SaV3taCaayGKVFpU6rPLD/VRart6ZP1CJQ2zlIskEEOnnUKEUuwcFpL7t5FX
iHVOX0hZ5fsuGYt8EuLwa7giEQvf/PaQbTrTVMOdKH/EGVJI81MfNgzEbrA/CvcG
/lgG3DM+JwIDAQABAoIBAQ3lKAOwbtgEKwg/IwNxFL3CmmYlMqiuB3ITvvn2hGMp
iqbS1NKsfA0GcbRILrzzhhEcWRmRmGCdOF00vzkwp6iiFyRxK3JkluDxRIPMlLDa
0wwnHQIdkm/5NoeuM27kTn/qyG++x6Iitq4C+FwqczQWoyCN+9VtAd7yIL6cj9eT
9N2qPIH4dAHfbp0gN1yTqTJi/IoIk2nAFs/6CBzjDS8jbr5qdEtX/VRVhVvb4p0k
ICle9wQ6VMCUM9tEJaPea7NqieJ+z7fFVKGMthFnIKqJ9VHpjpcRHgjH/6HqAvvM
pnRnWH3pIk9AXJSZ5s5dM4W4pLEXy3OX1Eizud7HSzdRAoGBDgmZRLl3hIJZXAO7
PN+wTT+J1qg3NcIXJcJvescMLTewWymkpfDISbhHlZYVtqPlkaz6pw3mpaRQRd/k
IY4gDmNwaxgmJ5LpGk6TGu2emkKr+95Cj2HaiYTRaOz3UVlpnTYvm7UTcNkfzXXe
mVXyfzJtl8SapVFaZpV5v2QobGfrAoGBDXyrANX2PD7c1NgbmGhhKs2wzpWL6o2s
0CHYQsAuxsvbO1YZr1e/wuPNtlmHQllIa5y1yRnhUkvjs62Ne2fvjGFFbbGew9WJ
kuBwGrfCziX9OYtLumSIw1ahodA1rQRpty5KImeCWXOGoTkgrMzlQ7/avlqZk1El
xED6gbkZpQ+1AoGBAIb/yQMmqEW1Ua2aNRk6KEzAwt2i5VQbRoHdakFcBb7X0zTn
SIyZGZvgpI/01N2nXCehavEsvwBDO7zDdzc9oQy/Rmar2ES+mQxmnlZa5PSoPVgG
LBjC+vOQYl60k8vGGe/VLgZJaq3dcfyBlkUSTRD56P+rx5YczUnEPxpmIlxtAoGB
DMvdX+SiRZULZ7NHs3pNvxP8DnYbk8cqUSvbibHYb+wZrRnLMu+Z1SrZEoutZwlZ
Sikc3Zp9i9zPRbqEQ7NguJvOCP7++SYQ6teh5ee2oGuw8Dk297nNfTEkGGh5lRhb
yV7VHgGBzqdq9GtEkk+xs29D91n03q6em69fP1fFejQFAoGBB/k1UBOMCjo+iNPH
bI+OzUqOy5NL7nd+SqB9FG53VE+w1b8XfCW3Cuf0Vm52AFudtXuAt5aEsezAJsfV
2XZfr+txSIgRbbFWQ39VccOFjckVzD2egXnFdL5Ac2s9JkAJZHqWU8pppJTVEuPF
KrYFFnz13zUOg9B7zxatELWn9rNV
-----END PRIVATE KEY-----

The signature can be verified by passing the public key, the header, the reconstructed payload, and the signature to a JWS library. This signature is valid.