Edit interop-kms_ExtraMarkup.yaml incorporating changes from QKD(25)39037

        request container contains keys matching those to be delivered to the

        initiator SAE.

        Upon a valid request, the KME should aim to respond without undue delay with 

        a `202`<!-- ~op_po_kmapi_v1_ext_keys_c_202 --> ('Accepted'), 

        then it will issue a separate call (or multiple calls) to the specified 

        Upon a valid request, for the required asynchronous mode, the KME shall 

        aim to respond without undue delay with a 

        `202`<!-- ~op_po_kmapi_v1_ext_keys_c_202 --> ('Accepted'), 

        then it shall issue a separate call (or multiple calls) to the specified 

        `ack_callback_url`<!-- ~p_kmapi_v1_ext_keys_ack_cb_url -->

        endpoint once the keys are actually delivered (or fail to be delivered).

        A `400`<!-- ~op_po_kmapi_v1_ext_keys_c_400 --> error will be returned 

        If synchronous mode is to be implemented in addition to the asynchronous 

        mode, as the KMEs shall not respond with an acknowledgement, 

        `ack_callback_url`<!-- ~ref_ack_callback_url --> is omitted in this 

        implementation. Instead, the KME shall respond with a 

        `200`<!-- ~op_po_kmapi_v1_ext_keys_c_200 -->` ('Successful').

        A `400`<!-- ~op_po_kmapi_v1_ext_keys_c_400 --> error shall be returned 

        if the container format is invalid or includes initiator/target SAE IDs 

        for which a valid route is not known to the KME.

      requestBody:

        extended key request container contains keys matching

        those already passed to the KME.

        Upon a valid request, a KME shall discard keys relating to the provided 

        key IDs and post a call to the specified 

        Upon a valid request, for the required asynchronous mode, a KME shall discard

        keys relating to the provided key IDs and post a call to the specified 

        `ack_callback_url`<!-- ~p_kmapi_v1_ext_keys_ack_cb_url --> describing 

        the completed operation. After this, The KMEs shall not use the impacted 

        key, and it shall reject any requests to retrieve them using 

        ETSI GS QKD 014, ETSI GS QKD 004, or otherwise.

        A `400`<!-- ~op_po_kmapi_v1_ext_keys_c_400 --> code should be returned 

        If synchronous mode is to be implemented in addition to the asynchronous mode, 

        as the KMEs shall not respond with an acknowledgement, 

        `ack_callback_url`<!-- ~p_kmapi_v1_ext_keys_ack_cb_url --> is omitted in 

        this implementation. Instead, the KME shall respond with a 

        `200`<!-- ~op_po_kmapi_v1_ext_keys_void_c_200 --> ('Successful').

        A `400`<!-- ~op_po_kmapi_v1_ext_keys_void_c_400 --> code shall be returned 

        if the request is known without further investigation to be invalid. 

        Otherwise, failures to void keys can be reported subsequently via 

        `ack_callback_url`<!-- ~p_kmapi_v1_ext_keys_ack_cb_url -->

        reduce the risk of accidental key loss, the KME shall reject any void 

        request that does specify key ID(s) but without including the 

        `all_confirmation` URL parameter with a value of true, and return a 

        `400`<!-- ~op_po_kmapi_v1_ext_keys_c_400 --> code.

        `400`<!-- ~op_po_kmapi_v1_ext_keys_void_c_400 --> code.

      parameters:

        - $ref: '#/components/parameters/all_confirmation'

      requestBody:

        KMS. The status of all keys in the container is indicated by the status

        field.

        The `ack_status`<!-- ~ref_ack_status --> field may be `relayed`, `voided`, `failed`, or `key not

        present`.

        The `ack_status`<!-- ~ref_ack_status --> field may be `relayed`, 

        `voided`, `failed`, or `key not present`.

        - `relayed` indicates the KME has successfully relayed the specified

        keys to the requested target (where the `initiator_sae_id` and

        it can be relayed to the initiator SAE).

        A KME receiving a valid acknowledgement shall return a 

        `200`<!-- ~op_po_kmapi_v1_ack_c_200 --> code, otherwise an Error Code

        `200`<!-- ~op_po_kmapi_v1_ext_keys_ack_c_200 --> code, otherwise an Error Code

        shall be returned including details of the error.

      requestBody:

        description: Acknowledgements containers

        If this parameter is omitted the request shall be interpreted as a 

        request to invoke the endpoint in the optional synchronous mode. 

        Otherwise, it shall be interpreted as a request to invoke the endpoint 

        using the default asynchronous mode.

        using the required asynchronous mode.

        Before submitting synchronos mode requests with a blank 

        Before submitting synchronous mode requests with a blank 

        `ack_callback_url`<!-- ~ref_ack_callback_url --> to a new KME the 

        `/kmapi/versions`<!-- ~op_get_kmapi_versions --> endpoint should be 

        called to confirm that the new KME supports the optional synchronous mode 

      type: object

      description: |

        Problem Details `problem_details`<!-- ~ref_problem_details --> is an object 

        according shall satify the requirements in IETF RFC 9457<!-- ~i_rfc_9457 --> 

        according shall satisfy the requirements in IETF RFC 9457<!-- ~i_rfc_9457 --> 

        for Problem Details for HTTP APIs. 

      properties:

        type: