Security
and
Privacy
This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v5.0.0:
R5
-
STU
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
|
Responsible
Owner:
Security
Work
Group
|
Standards
Status
:
|
Digital Signatures are needed to prove the authenticity and integrity of health records generally, and specifically for FHIR content and to establish the grounds for non-repudiation.
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 rely on non-repudiation of the content. This functionality is provided through the Signature type found in the signature element in the Provenance Resource. The signature can either be 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
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
recommends
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:
If implementers follow all the conformance points below (both the "SHALL" and the "SHOULD" points), then any FHIR consumer will be able to verify any digital signature.
The use of digital signatures with FHIR content comes with multiple challenges that implementers using digital signatures have to manage:
Once
a
resource
or
JSON
set
of
resources
is
signed,
any
change
to
the
URLs,
identifiers
and
the
expression
of
internal
references
will
invalidate
the
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,
at
a
minimum,
to
update
relevant
elements
that
it
manages
(id,
lastUpdated,
etc.).
These
changes,
although
expected
of
normal
RESTful
create/update
operations,
will
break
any
existing
Digital
Signatures
Signature
that
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, which requires systems must first confirm that the resulting created/updated Resource is as expected, and then sign with the Digital Signature. Another solution is to use a canonicalization that excuses these dynamic 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.
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
signatures.
Resources
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.
There are multiple aspects to signature verification:
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.
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:
.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.
A 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"
}
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.
The
Signature
datatype
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
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:
This
canonicalization
method
is
identified
by
the
URI
http://hl7.org/fhir/canonicalization/json-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:
<?xml
version="1.0"
encoding="UTF-8"?>
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.
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
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
types
including
non-repudiation
purposes.
Further
details
serves,
per
the
discussion
above.
This
specification
may
define
additional
canonicalizations
in
the
future,
and
other
specifications
might
also
define
additional
canonicalization
methods.
This
specification
makes
rules
about
the
use
of
JWS
-
JSON
Web
Signatures,
and
XML
Digital
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
creation
the
W3C
Verifiable
Credentials
Data
Model,
and
validation
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
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.
When the signature is a JWS Digital Signature, the following rules apply:
application/jose
and
this
SHOULD
be
populated
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
Signature
(where
the
content
that
is
signed
is
separate
from
the
signature
itself),
and
the
payload
SHALL
be
omitted
targetFormat
element
as
described
above.
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
)
kid
or
an
x5c
property
Signature.type
shall
come
from
ASTM
E1762-95(2013).
The
Signature.type
SHALL
contain
the
same
values
as
the
srCms
element.
sigT
and
the
Signature.when
SHOULD
be
populated,
and
if
they
are
both
populated,
their
values
SHALL
agree
or
any
other
profiling
of
JOSE-Signature.
When the signature is an XML Digital Signature, the following rules apply:
application/pkcs7-signature
and
this
SHOULD
be
populated
Signature.targetFormat
SHOULD
be
populated,
and
the
value
SHOULD
contain
a
canonicalization
URL
from
those
defined
above
Signature
(where
the
content
that
is
signed
is
separate
from
the
signature
itself)
targetFormat
element.
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.
SigningTime
and
the
Signature.when
SHOULD
be
populated,
and
if
they
are
both
populated,
their
values
SHALL
be
equal
X509Certificate
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
In
addition,
documents
may
When
a
provenance
resource
is
used
to
carry
a
signature,
the
following
rules
apply:
type
,
when
,
who
,
and
onBehalfOf
duplicate
the
Provenance
elements
agent.type
,
occurredDateTime
,
agent.who
,
and
agent.onBehalfOf
and
SHOULD
not
be
used
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
signature.
A
specification
for
enveloped
),
where
the
the
signed
data
is
included
within
the
signature
itself,
or
make
the
Provenance
resources
avilable
separately.
However,
if
the
signature
is
profiled
being
embedded
in
the
IHE
DSG
profile
.
Bundle,
then
the
following
rules
SHALL
be
observed:
Provenance.target
with
a
reference
value
of
exactly
Bundle/[id]
where
id
is
the
id
of
the
Bundle,
such
that
Provenance.signature
element
that
contains
the
signature
of
Bundle/{id}
#
which
indicates
that
it
signs
itself
in
addition
to
the
Bundle
(but
not
including
any
Provenance.signature
containing
a
digital
fullUrl
of
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.
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
pre-adopted
when
working
with
earlier
versions
of
the
FHIR
specification).
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"
}]
}
}]
}
Here's an 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 the signature is (after decoding the base64):
eyJ0eXAiOiJKT1NFIiwic3JDbXMiOlt7ImNvbW1JZCI6eyJpZCI6InVybjpvaWQ6MS4yLjg0MC4xMDA2NS4xLjEyLjEuMSIsImRlc2MiOiJBdXRob3IncyBTaWduYXR1cmUifX1dLCJhbGciOiJSUzI1NiIsInNpZ1QiOiIyMDI1LTA3LTAxVDA4OjQ4OjA1WiIsImNhbm9uIjoiaHR0cDovL2hsNy5vcmcvZmhpci9jYW5vbmljYWxpemF0aW9uL2pzb24iLCJ4NWMiOlsiTUlJRG96Q0NBb3FnQXdJQkFnSUJBREFOQmdrcWhraUc5dzBCQVEwRkFEQnJNUXN3Q1FZRFZRUUdFd0oxY3pFUk1BOEdBMVVFQ0F3SVRXbHpjMjkxY21reEREQUtCZ05WQkFvTUEwaE1OekVRTUE0R0ExVUVBd3dIYUd3M0xtOXlaekVTTUJBR0ExVUVCd3dKUVc1dUlFRnlZbTl5TVJVd0V3WURWUVFMREF4SlJ5QlFkV0pzYVhOb1pYSXdIaGNOTWpVd05qRTVNREl6TURNeldoY05Nall3TmpJd01ESXpNRE16V2pCck1Rc3dDUVlEVlFRR0V3SjFjekVSTUE4R0ExVUVDQXdJVFdsemMyOTFjbWt4RERBS0JnTlZCQW9NQTBoTU56RVFNQTRHQTFVRUF3d0hhR3czTG05eVp6RVNNQkFHQTFVRUJ3d0pRVzV1SUVGeVltOXlNUlV3RXdZRFZRUUxEQXhKUnlCUWRXSnNhWE5vWlhJd2dnRWpNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJFQUF3Z2dFTEFvSUJBZ0M5VXM4djBVeU95K1hXTFJmZjI5R0hRYTlheHF0RGFvN2F6c1duRjIvQUJkZzFnNmRPRi8wWmtyaExkcUpJU2o4TWxTUDVWTG91NjdpWklIMFJ4Uk1mU0EwZS9maTlERThRU3pwSU9sdWVlSDJNOFEyVmVzS3AzaElrcCt4Q2FHUGJjNEwwa1pWa0U2RVcrVFVSN1FUczFOa2F4dHdZdlc4N2dLem42QkwwWXgvNW11MVVGV2NKL1h0TEhraWFndEliU2lFWFNkc2p4dmlPYkpNMlNhVjN0YUNhYXlHS1ZGcFU2clBMRC9WUmFydDZaUDFDSlEyemxJc2tFRU9ublVLRVV1d2NGcEw3dDVGWGlIVk9YMGhaNWZzdUdZdDhFdUx3YTdnaUVRdmYvUGFRYlRyVFZNT2RLSC9FR1ZKSTgxTWZOZ3pFYnJBL0N2Y0cvbGdHM0RNK0p3SURBUUFCbzFBd1RqQWRCZ05WSFE0RUZnUVVxQktvMmlRMFI1cjVHaU5saDJzTkN6RXE5UUl3SHdZRFZSMGpCQmd3Rm9BVXFCS28yaVEwUjVyNUdpTmxoMnNOQ3pFcTlRSXdEQVlEVlIwVEJBVXdBd0VCL3pBTkJna3Foa2lHOXcwQkFRMEZBQU9DQVFJQWk4RlZzcVpKNE9maWlnamdwNCtDZUhEeDZMSlJ1cTZZb2lOZXJ4SjRsK0VUNEJiN2o4RS9ERGVFZmViRVF2d1ByaGxPeUZPZnlvc3phQm5GOEVwL0hrN09qNmNwTGhvQUhqZVYzR1V5KzN4ZzNOQjNEdUU3SmhueDk5a3dmUkw5dE9YSjUrTGwxQUloeVQwSklEOEo2Lzk5UTVWbXdTQ1VlUmZuaG5uaWdabHdTNFZoQW9hbmhycXp3WHZwT2NvK0h5aEwweTNtbWJCSC9lS1UrSDVQK0wySUZpU0ZMNlhBTDRQTTNwWUkvemorTnloQVhaWlp3bGxSam9JS2ZsR09POEhVYzVpSmlUSGhZbzBpS1MxbFB4Q0hvS3lBK2FWRWFWRS9nb3FCd29lM1Y5bXhIQXo0VXE4ZS9hUTBPZmNpRm1qNTVzNm14NWVVZHk1bFFxZm9la0U9Il19..oP1UwlGBYvNYKDAishza8Pm8cl9m1y0mi1Tc-e7DGgT0EF0mqI_-7z7hSPGSOXBHJdjpM40uY0q5RRx1qTv-cmXFAnv4wxMqGc6wSudm6f1tdLgLlfpQ9Z98tpFgH0Pz56ijf-LjoB5uPmm_RoSrwewFQn7LhpY9ZopAeTUSScTy9AF9mBvwu1vTmaLxOSJDzoGcnlfWtJgO_7or2e_KfJd53tdXfANiZfADYpQ3hxf-2SX_Gc5ZgrxXitWkFP5RhTXoyrqC3HYJ6J63PgK8DVlLqcE-x3QpY00wQpv1A-HgcPhJctasy7BbpnK3zW_uLMDVFb9t8uIWOykmtRRpeKI
This JWS signature has 3 parts: header, payload, and signature.
Note
to
Implementers:
Header
The
use
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
contents
of
signatures
with
RESTful
interfaces
the
header:
srCms
is
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
canon
is
optional,
but
if
it
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
kid
that
identifies
the
key,
which
must
be
retrieved
from
some
key
management
arrangement
Payload
Feedback
The
payload
is
welcome
here
.
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 determine whether there is a content or a canonicalization problem, and this can be useful when debugging signatures.
Signature
The key that signed this is 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.
FHIR
®©
HL7.org
2011+.
FHIR
R5
hl7.fhir.core#5.0.0
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Sun,
Mar
26,
2023
15:26+1100.
Mon,
Nov
24,
2025
20:53+0000.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R4B
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change