AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com

HTT Consulting

Oak Park MI 48237 USA rgm@labs.htt-consult.com

Internet drip Working Group Internet-Draft This document defines an HTTP based interface using either JSON or CBOR for object encodings for clients to register in a DRIP Identity Management Entity (DIME). The DPA is a logical component of the DIME that handles various DRIP specific functions and is the public interface for clients that wish to register.

Introduction The DPA is one of the required components in a DIME for it to fulfill the role of registration of DRIP Entity Tags (DETs) of clients. A standardized interface is needed for this to avoid interoperability issues between vendors supporting DRIP and the various logical components of the DIME. Per the DPA MUST:

• provided an HTTP interface for clients to access with JSON or CBOR encoding of objects being sent to the DPA.

This document is the definition of this interface and its behavior; specifically between the DPA and a registering client. A snapshot of the OpenAPI specification is in at the time of this documents publishing; with a URI to access an updated specification.

Terminology

Required Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Endpoint Definitions & Behavior All endpoints that send DRIP Endorsements use the JSON/CBOR forms as specified in . If there is any failure during validation in any endpoint a HTTP 400 code MUST be sent to the client with a detailed reason for the error.

Serial Number

Standard Serial Number When a Serial Number request comes in the Serial Number MUST be validated to the formatting specified in }. If the Serial Number is valid the DPA MUST check to confirm that there is no collisions are present for the Serial Number in both the Registry/Name Server (using the Serial Number FQDN) and the DIA. If no collisions are detected the metadata can be sent to the DIA using the Serial Number as the primary key value. A successful registration MUST return a HTTP code 200 with the following payload: ..mfr.hhit.arpa." } ]]>

DET Serial Number The self_endorsement in the request is a Self-Endorsement: UA. The serial parameter when using a DET-based Serial Number must be checked to confirm that the DET in the Self-Endorsement: UA properly encodes into the Serial Number specified. The formatting and process of a DET encoded Serial Number can be found in . If the Serial Number is valid the DPA MUST check to confirm that there is no collisions are present for the Serial Number, DET and HI in both the Registry/Name Server (using the DET FQDN and Serial Number FQDN) and the DIA. If no collisions are detected the metadata can be sent to the DIA using the Serial Number as the primary key value. A DET FQDN is formed using the DET and used for the HIP RR and CERT RRs. Two CERT RRs are required; one for the Self-Endorsement: UA sent in the registration request, and one for the Broadcast Endorsement: DIME, UA generated by the DPA. A Serial Number FQDN is used to create a CNAME RR pointing to the DET FQDN. A successful registration MUST return a HTTP code 200 with a payload containing the following: ..mfr.hhit.arpa." "hhit_fqdn": ".....hhit.arpa." } ]]> The broadcast_endorsement in the response is a Broadcast Endorsement: DIME, UA.

Operator / Ground Control Station (GCS) The self_endorsement in the request is a Self-Endorsement: Operator or Self-Endorsement: GCS. A successful registration MUST return a HTTP code 200 with a payload containing the following: .....hhit.arpa." } ]]> The endorsement in the response is a Endorsement: DIME, Operator or Endorsement: DIME, GCS.

Session ID The endorsement in the request is an Endorsement: Operator, UA or a Endorsement: GCS, UA. The mutual_endorsement in the request is Mutual Endorsement: DIME, Operator or a Mutual Endorsement: DIME, GCS. When the e and me are on or with an Operator then the operator_det MUST match the HHIT/DET found in those endorsements. A successful registration MUST return a HTTP code 200 with a payload containing the following: .....hhit.arpa." } ]]> The broadcast_endorsement in the response is a Broadcast Endorsement: DIME, UA. The endorsement in the response is an Endorsement: DIME, Operator, UA or an Endorsement: DIME, GCS, UA.

Child DIME

• Note: the mfrCode field is only used by an MRA when registering with an IRM and holds the ICAO assigned Manufacturer Code for .

A successful registration MUST return a HTTP code 200 with a payload containing the following: .....hhit.arpa." } ]]> The broadcast_endorsement in the response is a Broadcast Endorsement: Parent DIME, Child DIME. The endorsement in the response is an Endorsement: Parent DIME, Child DIME.

References Normative References This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. AX Enterprize, LLC AX Enterprize, LLC HTT Consulting RTFM llp This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS technologies and practices. Discovery of DETs and their artifacts are through the existing DNS structure and methods by using FQDNs. A general overview of the interfaces required between components is described in this document with supporting documents giving technical specifications. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References HTT Consulting AX Enterprize AX Enterprize Linköping University This document describes the use of Hierarchical Host Identity Tags (HHITs) as a self-asserting and thereby trustable Identifier for use as the UAS Remote ID. HHITs include explicit hierarchy to provide Registrar discovery for 3rd-party ID attestation.

OpenAPI Specification TODO