ETSI GS QKD 020 V1.1.1 (2026-06)

• Abstract:

  DGS/QKD-020_InteropKMS

• Status: Not Published
• Technical Committee: QKD - Quantum Key Distribution
• Current Stage: 12 - Completion
• Due Date: 16-Jul-2026
• Completion Date: 29-Jun-2026

GROUP SPECIFICATION
Quantum Key Distribution (QKD);
Protocol and data format of REST-based
Interoperable Key Management System API
Disclaimer
The present document has been produced and approved by the Quantum Key Distribution (QKD) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS QKD 020 V1.1.1 (2026-06)

Reference
DGS/QKD-020_InteropKMS
Keywords
API, protocol, quantum cryptography, quantum key
distribution
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI GS QKD 020 V1.1.1 (2026-06)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Description . 8
4.1 Overview . 8
4.2 Operation of the API . 8
4.3 Connection specification and security scheme . 12
4.4 Security and operational environment . 13
4.5 Extensions . 13
4.6 SAE IDs . 13
4.7 Example use case for the API . 14
5 versions: API versions available . 15
5.1 Tag description . 15
5.2 GET /kmapi/versions: Get supported API versions . 15
5.2.1 Description . 15
5.2.2 Responses . 15
5.2.2.1 200 Successful OK response application/json . 15
5.2.2.2 401 Unauthorized response application/json . 16
5.2.2.3 503 Error of server side response application/json . 17
6 ext_keys: Interoperation (external keys) . 18
6.1 Tag description . 18
6.2 POST /kmapi/v1/ext_keys: Transfer keys to external KMS . 18
6.2.1 Description . 18
6.2.2 Request Body: application/json . 18
6.2.3 Responses . 21
6.2.3.1 200 Successful response (synchronous mode) application/json . 21
6.2.3.2 202 Request accepted response . 22
6.2.3.3 400 Bad request format response application/json . 22
6.2.3.4 401 Unauthorized response application/json . 23
6.2.3.5 408 Request timeout response application/json . 24
6.2.3.6 503 Error of server side response application/json . 25
6.3 POST /kmapi/v1/ext_keys/ack: Acknowledge status of keys after API request(s) . 26
6.3.1 Description . 26
6.3.2 Request Body: application/json . 27
6.3.3 Responses . 28
6.3.3.1 200 Successful OK response . 28
6.3.3.2 400 Bad request format response application/json . 28
6.3.3.3 401 Unauthorized response application/json . 29
6.3.3.4 503 Error of server side response application/json . 30
6.4 POST /kmapi/v1/ext_keys/void: Signal keys as void to external KMS (i.e. discard keys) . 31
6.4.1 Description . 31
6.4.2 Request Body: application/json . 31
6.4.3 Responses . 33
6.4.3.1 200 Successful response (synchronous mode) application/json . 33
6.4.3.2 202 Request accepted response . 34
ETSI
4 ETSI GS QKD 020 V1.1.1 (2026-06)
6.4.3.3 400 Bad request format response application/json . 34
6.4.3.4 401 Unauthorized response application/json . 35
6.4.3.5 408 Request timeout response application/json . 36
6.4.3.6 503 Error of server side response application/json . 36
7 Schemas . 37
7.1 ack_callback_url . 37
7.2 ack_container . 38
7.3 ack_containers . 39
7.4 ack_message . 40
7.5 ack_status . 40
7.6 all_confirmation . 41
7.7 capabilities . 41
7.8 capability . 41
7.9 ext_key_container . 41
7.10 extension. 43
7.11 extension_mandatory . 44
7.12 extension_optional. 44
7.13 initiator_sae_id . 45
7.14 key_id . 45
7.15 key_id_container . 45
7.16 key_ids . 46
7.17 key . 46
7.18 keys . 47
7.19 problem_details . 48
7.20 target_sae_id . 48
7.21 target_sae_ids . 49
7.22 value . 49
7.23 version . 49
7.24 version_container . 50
7.25 versions . 50
7.26 void_container . 50
Annex A (normative): OpenAPI representation . 53
History . 54

ETSI
5 ETSI GS QKD 020 V1.1.1 (2026-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Quantum Key
Distribution (QKD).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GS QKD 020 V1.1.1 (2026-06)
1 Scope
The present document specifies a REST API that allows key management systems to interoperate to pass keys
horizontally between two systems located in a common trusted node. The API enables QKD networks to serve
applications that request shared secret keys from key management systems that are not linked by a contiguous chain of
systems from the same vendor. It is beyond the scope of the present document to describe how the underlying QKD
network agrees key material between nodes. URI formats, communication protocols (HTTPS), and the JSON data
format encoding of posted parameters and responses (including key material) are described. An OpenAPI description of
the API is available.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 9110: STD 97 (June 2022): "HTTP Semantics".
[2] IETF RFC 8259: STD 90 (December 2017): "The JavaScript Object Notation (JSON) Data
Interchange Format".
[3] IETF RFC 9112: STD 99 (June 2022): "HTTP/1.1".
[4] IETF RFC 8446 (August 2018): "The Transport Layer Security (TLS) Protocol Version 1.3".
[5] IETF RFC 3986: STD 66 (January 2005): "Uniform Resource Identifier (URI): Generic Syntax".
[6] IETF RFC 5234: STD 68 (October 2005): "Augmented BNF for Syntax Specifications: ABNF".
[7] IETF RFC 4648 (October 2006): "The Base16, Base32, and Base64 Data Encodings".
[8] IETF RFC 9562 (May 2024): "Universally Unique IDentifiers (UUIDs)".
[9] IETF RFC 9457 (July 2023): "Problem Details for HTTP APIs".
[10] OpenAPI Initiative: "OpenAPI Specification v3.1.2 (September 2025)".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI GR QKD 007: "Quantum Key Distribution (QKD); Vocabulary".
ETSI
7 ETSI GS QKD 020 V1.1.1 (2026-06)
[i.2] ETSI GS QKD 014: "Quantum Key Distribution (QKD); Protocol and data format of REST-based
key delivery API".
[i.3] ETSI GS QKD 004: "Quantum Key Distribution (QKD); Application Interface".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR QKD 007 [i.1] and the following apply:
NOTE: A term defined in the present document takes precedence over the definition of the same term, if any, in
ETSI GR QKD 007 [i.1].
interworking node: node of more than one QKD network that contains key management entities from each QKD
network interworking within the node
key management entity: entity that manages keys in a network in cooperation with one or more other key management
entities
secure application entity: entity that requests one or more keys from a key management entity for one or more
applications running in cooperation with one or more other secure application entities
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
HEXDIG HEXadecimal DIGits
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IP Internet Protocol
JSON JavaScript Object Notation
KME Key Management Entity
KMS Key Management System
PEN Private Enterprise Number
QKD Quantum Key Distribution
REST REpresentational State Transfer
SAE Secure Application Entity
TLS Transport Layer Security
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTF-8 UCS Transformation Format 8 bits
UUID Universally Unique IDentifier
ETSI
8 ETSI GS QKD 020 V1.1.1 (2026-06)
4 Description
4.1 Overview
The present document specifies a communication protocol and data format for Key Management Entities (KMEs) for
use by Quantum Key Distribution (QKD) networks to exchange keys when located together within a protected
operational environment. Use-cases include where:
• KMEs belong to different QKD networks and are located within an interworking node.
• KMEs belong to different policy domains of a QKD network.
• KMEs are otherwise incompatible, e.g. from different vendors.
Since use-cases include interworking between different network operators and policy domains, the information that
KMEs are required to exchange is intentionally limited.
A REST (REpresentational State Transfer) API is specified as a simple, scalable, widely deployed approach that is
familiar to a large developer community. The REST-based API specifies the format of the URIs, the communication
protocol "HTTPS" i.e. HTTP with TLS, as well as the data format and encoding of request and response content,
including key material.
4.2 Operation of the API
The primary purpose of QKD networks is to deliver shared secure random keys to authorized cryptographic
applications called Secure Application Entities (SAEs). APIs have been specified in ETSI GS QKD 014 [i.2] and ETSI
GS QKD 004 [i.3] for the delivery of keys from a KME to an SAE.
Where there is no direct QKD link between the KMEs from which SAEs are requesting to share keys, the KMEs within
QKD networks typically relay keys. They can consume QKD keys to help achieve this securely. Different sets of KMEs
might not be fully compatible between sets of KMEs. Sets of KMEs could also be managed separately, e.g. by different
network operators that wish to limit unnecessary sharing of internal network information.
In such cases a standardized interface is required for KMEs to pass keys horizontally between different sets of KMEs
that cannot otherwise interoperate due to incompatibility or policy, etc. The API described in the present document
enables key transfers between KMEs within a secure operational environment. This can enable shared keys to be
delivered to two (or more) SAEs connected to KMEs in different QKD networks, policy domains, etc.
There are two primary modes of operation for the API methods described in the present document: asynchronous mode
and synchronous mode. In the asynchronous mode, requests are processed in a non-blocking manner, allowing a KME
to accept a request without undue delay and close the request connection by issuing a "202" ('Request accepted')
response. Actual key processing can then be performed in the background before the KME acknowledges the result of
that key processing by issuing one or more requests back to the KME that made the initial request to provide details of
the outcome. This mode is particularly advantageous in high-traffic environments, or where request processing can be
time consuming. It avoids blocking the requestor and minimizes the number of simultaneous open connections between
KMEs. As a result, this mode can help achieve scalability as well as predictable performance under anomalous
conditions. An overview message sequence diagram for the asynchronous mode is provided in Figure 4.2-1.
ETSI
9 ETSI GS QKD 020 V1.1.1 (2026-06)

Figure 4.2-1: Overview message sequence diagram for successful required asynchronous mode
Conversely, in the synchronous mode the requestor has to wait for all parts of a request to either complete or fail before
responding since all results are returned within a single response. This mode provides a more straightforward and direct
interaction between KMEs and can be suitable where results can be returned almost immediately, but it can limit
scalability in large or congested networks. A message sequence diagram for the optional synchronous mode is provided
in Figure 4.2-2.
Figure 4.2-2: Overview message sequence diagram for successful optional synchronous mode
To ensure interoperability, all KMEs shall support the asynchronous mode of operation for the API methods defined in
the present document.
KMEs may support the synchronous mode of operation as an optional mode in addition to the required asynchronous
mode for specific implementation(s).
ext_keys" and for
A KME shall not retain an association for any key in a request that arose from a call it received to "
which it returned either a "400" ('Bad request format') or a "401" ('Unauthorised') response.
_ _ _ _
KMEs shall assume keys could have been associated with the "initiator sae id" and "target sae id" as a result of an
_
"ext keys" request unless either a "400" ('Bad request format') or "401" ('Unauthorised') response is returned.
Unless one of these two responses is successfully received, a KME shall assume that assignment(s) of the key(s) in the
request could potentially have been created.
NOTE 1: Potential associations could reside within the KME or have been created by other entities it interacted
with. Potential associations could have been created where a timeout occurs.
_
KMEs should not reassign any key that was in a "ext keys" call without considering the potential assignments that
could have been created.
ETSI
10 ETSI GS QKD 020 V1.1.1 (2026-06)
NOTE 2: KMEs will typically not release a key to SAEs until they know that the key was successfully relayed to all
_ _
intended "target sae id".
Where errors or timeouts other than a "400" ('Bad request format') or "401" ('Unauthorised') occur in an "ext_keys"
_
request, KMEs shall either retry the failed requests for all impacted keys in subsequent "ext keys" requests or void the
_
impacted keys within their network(s) and by issuing "ext keys/void" requests.
For "400" ('Bad request format') or a "401" ('Unauthorised') response KMEs may optionally retry the failed requests.
_
Where errors or timeouts occur in an "ext keys/ack" request, KMEs shall either retry the failed requests for all
_
impacted keys in subsequent "ext keys/ack" requests or void the impacted keys within their network(s) and issue
"ext_keys/void" requests.
_ _
NOTE 3: For "ext keys/ack" the call to "ext keys/void" is issued in the opposite direction to the KME that issued
_
the related "ext keys" request.
More comprehensive sequence diagrams are provided for the required asynchronous mode in Figure 4.2-3 and for the
optional synchronous mode in Figure 4.2-4.
ETSI
11 ETSI GS QKD 020 V1.1.1 (2026-06)

Figure 4.2-3: Message sequence diagram for required asynchronous mode
ETSI
12 ETSI GS QKD 020 V1.1.1 (2026-06)

Figure 4.2-4: Message sequence diagram for optional synchronous mode
4.3 Connection specification and security scheme
The common connection specifications for the API are shown in Table 4.3-1.
Table 4.3-1: Common connection specifications
Name Description
Communication Protocol "HTTPS": HTTP/1.1 and optionally higher versions in addition; TLS v1.3 or higher versions
Content-Type application/json; charset=UTF-8

All communication functions specified in this API shall be implemented using the HTTP/1.1 protocol as specified in
IETF RFC 9110 [1] and IETF RFC 9112 [3] with Transport Layer Security (TLS).
NOTE 1: This combination is often referred to as an HTTPS protocol.
Higher versions of the HTTP protocol may be implemented in addition to HTTP/1.1.
TLS v1.3 as specified in IETF RFC 8446 [4] or higher versions shall be used.
At the connection establishment, mutual authentication between the KMEs shall be performed using certificates.
Each of the two KMEs shall verify the validity of the certificate of the other KME and shall confirm its identity from
the certificate.
Where requests and responses include body content these shall be encoded using the "application/json".
ETSI
13 ETSI GS QKD 020 V1.1.1 (2026-06)
NOTE 2: OpenAPI introduced support for specifying mutual TLS security in version 3.1. While other parts of this
OpenAPI description can be easily converted to OpenAPI version 3.0 for use with older tools, it would be
necessary to ensure that whatever security is specified in a Security Scheme Object is manually
overridden according to this clause 4.3 in any implementation.
4.4 Security and operational environment
This API is for use between KMEs that are both located within the same site (an interworking node when used between
two QKD networks). The KMEs and the communications the present document specifies between them should remain
within a secure operational environment. Appropriate security measures should be considered for the operational
environment.
General security requirements for key processing and management are outside the scope of the present document.
4.5 Extensions
Some methods allow for extensions to be provided. Extensions can be specified by vendors and KMEs shall follow the
specification of any extension it claims to have implemented. Where relevant, this includes passing on without change
any information indicated to be immutable in the specification of the extension.
Properties may be of any type, but their names shall be unique and start with a vendor prefix that shall be the capital
letter "E" followed by an IANA Private Enterprise Number (PEN) followed by an underscore. The organization to
which the PEN is assigned can use the extension for their own purposes, or can provide a specification for the extension
to other organizations so they can also implement the extension. No organization shall use an extension starting with a
vendor prefix with the PEN of any other organization without following a specification from the organization associated
with the PEN.
ETSI might specify extensions in future but unless it does ETSI's IANA Private Enterprise Number "13019" is reserved
and shall not be used.
NOTE: Extensions can originate from SAE requests that triggered key relaying, or can be added by a KME, e.g.
to add metadata etc. Requirements in the specification of an extension can prohibit addition of an
extension by a KME in subsequent calls. Extensions could be deserialized to a dictionary within a KME.
Both property names and their values can be significant.
_ _
Relevant schema include "extension", "extension mandatory", and "extension optional".
4.6 SAE IDs
SAE IDs shall be unique across any set of connected QKD networks. In some circumstances, duplicate SAE IDs could
result in keys being made available to an SAE other than the intended SAE(s). To obtain a key intended for another
SAE in the presence of duplicate SAE IDs using the API in ETSI GS QKD 014 [i.2] from an otherwise securely-
_
implemented KME, a malicious target SAE would need to specify a valid "key id" associated with the other target SAE
in an appropriately-timed request. However, even where potential mitigations apply in some circumstances (such as
_
maintaining the "key id" as confidential) reliable delivery can be compromised by duplicate SAE IDs.
How connected QKD networks ensure the uniqueness of SAE ID is beyond the scope of the present document.
_ _ _ _
SAE IDs ("initiator sae id" and "target sae id") shall not exceed 64 characters in length. Where SAEs are likely to
want to communicate SAE IDs in restricted-length-parameters of other protocols connected QKD networks can
consider further limiting SAE ID lengths.
SAE IDs shall not include characters that would not be allowed within a URI as specified in IETF RFC 3986 [5] with
reference to IETF RFC 5234 [6]. SAE IDs are not required to be URIs.
NOTE: IETF RFC 3986 [5] allows unreserved characters "unreserved = (ALPHA / DIGIT / "-" / "." / "_" /
"~")", reserved general delimiter characters "gen-delims = (":" / "/" / "?" / "#" / "[" / "]" / "@")",
and sub-delimiter characters "sub-delims = ("!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," /
";" / "=")" as well as percent encoded characters "pct-encoded = "%" HEXDIG HEXDIG". See IETF RFC
5234 [6] for definitions of "ALPHA = (%x41-5A / %x61-7A; A-Z / a-z)", "DIGIT = %x30-39; 0-9", and
"HEXDIG = (DIGIT / "A" / "B" / "C" / "D" / "E" / "F")".
ETSI
14 ETSI GS QKD 020 V1.1.1 (2026-06)
4.7 Example use case for the API
_
Figure 4.7-1 shows a use-case in which the "ext keys" operation is used to pass keys between KMEs in an interworking
node of a three-node network. It is comprised of two networks X and Y that both have a presence in an interworking
node. Key delivery to applications using ETSI GS QKD 014 [i.2] is considered in this use case.
The asynchronous key delivery between two QKD networks is uncoupled from any SAE protocol or workflow. This
use case considers a reactive pattern in which keys are requested by an initiator SAE. Use cases following a proactive
pattern are also possible in which a KME node acts as an initiator SAE to request keys to fill one or more shared buffers
of keys that such KMEs can then use to delivery keys to client SAEs.
1) SAE A makes a local request within Site A to KME X1 of QKD network X for key(s) shared with SAE C,
which is in a separate Site C served by another QKD network Y.
2) QKD network X performs operations using QKD keys to establish shared key(s) between KME X1 in SAE A's
site and KME X2, which is in an interworking node at Site B. Communications can be proprietary to systems
within QKD network X and details are not indicated in Figure 4.7-1.
_
3) Within Site B KME X2 issues a request to "ext keys" on KME Y2 using the API specified in the present
document.
4) KME Y2 responds immediately with HTTP status code "202" ('Request accepted').
5) QKD network Y performs operations using QKD keys to transfer the key(s) to KME Y1 in Site C.
Communications can be proprietary to systems within QKD network Y, hence details are not indicated in
Figure 4.7-1.
6) Once QKD network Y has ensured the key(s) are available in KME Y1, KME Y2 issues a request to
_
"ext keys/ack" on KME X2 to acknowledge that the request was successful.
7) KME X2 responds immediately with HTTP status code "200" ('Successful OK') to confirm that KME X2 has
received the acknowledgement.
8) QKD network X communicates the successful result back to KME X1. Communications can be proprietary to
systems within QKD network X and details are not indicated in Figure 4.7-1.
9) KME X1 returns the key(s) to SAE A by responding to the original request from SAE A.
10) SAE A communicated the key ID(s) to SAE C. Communications can be proprietary to systems of the
application, hence details are not indicated in Figure 4.7-1.
11) SAE C uses the key ID(s) to request the key(s) from KME Y1 locally within Site C.
12) KME Y1 responds to SAE C with the key(s). Both SAE A and SAE C now share identical key(s) and can
proceed to consume them for cryptographic purposes.
_
In this manner keys are shared between SAEs A and C via the use of "ext keys" within the interworking node.
ETSI
15 ETSI GS QKD 020 V1.1.1 (2026-06)

Figure 4.7-1: Sequence diagram for use case of real-time ETSI GS QKD 014 [i.2]
key request established via interwork node
5 versions: API versions available
5.1 Tag description
Versionless path that can be used to query the available versions of this API on a KME.
5.2 GET /kmapi/versions: Get supported API versions
5.2.1 Description
Return list of versions of the API that are supported by the KME.
When an KME makes a request to another KME, it should use the most recent version of the API that the KMEs both
support.
The SAE can use this end-point to determine which API versions the KME supports.
5.2.2 Responses
5.2.2.1 200 Successful OK response application/json
_
The response body shall match the "version container" schema as shown in Table 5.2.2.1-1 encoded as media type
"application/json" in JSON format as specified in IETF RFC 8259 [2].
ETSI
16 ETSI GS QKD 020 V1.1.1 (2026-06)
Table 5.2.2.1-1: Data type "version_container" for 200 response to
GET /kmapi/versions as application/json
Field Name Type Description
REQUIRED
array of string
versions
schema: Versions "versions" shall be an array of supported API versions "version".
versions
Maximum items: 1 000
Capabilities "capabilities" shall be an array of strings each indicating a "capability"
supported by the host.
array of string
Where a host supports the optional synchronous mode it should report this capability
capabilities
schema:
of "synchronous_mode". Clients should confirm this capability before sending requests
capabilities
for synchronous mode.
Maximum items: 1 000
Extension "extension" shall be an object containing any number of properties that
each represents an extension specified by ETSI or another organization (such as a
vendor). KMEs may choose to implement a set of extensions. Specifications of
object
extensions can include requirements and KMEs that implement an extension shall
extension
schema:
comply with such requirements.
extension
Further requirements are given in clause 4.5.
Minimum properties: 1
Maximum properties: 1 024
_
EXAMPLE: An example of "200" status code "version container" response body for "/kmapi/versions" as
media type "application/json":
{
"versions": [
"v1"
],
"capabilities": [
"synchronous_mode"
],
"extension": {
"E32473_extension1": "Some string",
"E32473_extension2": {
"property1": 10111,
"property2": "Some text",
"property3": {
"subprop1": 21,
"subprop2": true
}
}
}
}
5.2.2.2 401 Unauthorized response application/json
_
The response body shall match the "problem details" schema as shown in Table 5.2.2.2-1 encoded as media type
"application/json" in JSON format as specified in IETF RFC 8259 [2].
Table 5.2.2.2-1: Data type "problem_details" for 401 response to
GET /kmapi/versions as application/json
Field
Type Description
Name
REQUIRED
A URI reference that identifies the problem type.
type
string
Format: uri
Maximum length: 1 024
The HTTP status code generated by the origin server for this occurrence of the problem.
Format: int32
status
integer
Minimum: 100
Maximum: 599
A short, human-readable summary of the problem type.
title
string
Maximum length: 1 024
ETSI
17 ETSI GS QKD 020 V1.1.1 (2026-06)
Field
Type Description
Name
Object containing one or a number of string properties to convey details about the problem.
Typically, the name of each string property will identify the topic with the string value providing
more detailed information.
details
object
"details" can be deserialized to a dictionary of strings.
Minimum properties: 1
Maximum properties: 1 024
_
EXAMPLE: An example of "401" status code "problem details" response body for "/kmapi/versions" as media
type "application/json":
{
"type": "https://qkd.etsi.org/gs020-interop-kms/unauthorized",
"status": 401,
"title": "unauthorized",
"details": {
"unauthorized": "User-supplied certificate is invalid."
}
}
5.2.2.3 503 Error of server side response application/json
_
The response body shall match the "problem details" schema as shown in Table 5.2.2.3-1 encoded as media type
"application/json" in JSON format as specified in IETF RFC 8259 [2].
Table 5.2.2.3-1: Data type "problem_details" for 503 response to
GET /kmapi/versions as applic
...