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 the DRIP Provisioning Agent (DPA) or Registry to insert, update or delete information from a DRIP Information Agent (DIA). JSON Web Tokens (JWTs) are used between the entities to encapsulate and authenticate the transactions.

Introduction The DIA 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 DIA MUST:

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

This document is the definition of this interface and its behavior; specifically between the DIA and a DPA or DIA and a Registry. 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.

JWT Use When using the JWT the iss is filled with the DET FQDN of the DIME component (typically the DPA). The sub is filled with the FQDN of the entity being registered. For a Serial Number this is the Serial Number FQDN of the UA, for the Operator/GCS the DET FQDN of the Operator/GCS and for the Session ID this is the DET FQDN of the UA. A data field is filled with specific information to be stored in the RDDS by the DIA for the given subject. Another field drip is used to hold various DRIP information elements. The JWT is signed using the private key (an EdDSA25519 key) of the iss entity; the DPA.

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 .....hhit.arpa", "sub": "..mfr.hhit.arpa", "iat": 0, "exp": 0, "drip": { "det": "base16 HHIT/DET", "hi": "base64 HI", "endorsements": [ self_endorsement, broadcast_endorsement ] }, "data": { "serial": "Serial Number", "manufacturer": "Manufacturer", "make": "Make", "model": "Model", "color": "Color", "material": "Material", "weight": 1.0, "length": 1.0, "width": 1.0, "height": 1.0, "numRotors": 1, "propLength": 1.0, "batteryCapacity": 1.0, "batteryVoltage": 1.0, "batteryWeight": 1.0, "batteryChemistry": "Battery Chemistry", "takeOffWeight": 1.0, "maxPayloadWeight": 0.1, "maxFlightTime": 1.0, "minOperatingTemp": 1.0, "maxOperatingTemp": 2.0, "ipRating": "None" } } ]]>

• Note: the drip field is optional.

Operator .....hhit.arpa", "sub": ".....hhit.arpa", "iat": 0, "exp": 0, "drip": { "det": "base16 HHIT/DET", "hi": "base64 HI", "endorsements": [ self_endorsement, endorsement ] }, "data": { "name": "", "addr": { "street1": "", "street2": "", "city": "", "sp": "", "pc": "", "cc": "" }, "voice": "", "email": "", "part107": "", "recFlyerId": "" } } ]]>

Ground Control Station (GCS) .....hhit.arpa", "sub": ".....hhit.arpa", "iat": 0, "exp": 0, "drip": { "det": "base16 HHIT/DET", "hi": "base64 HI", "endorsements": [ self_endorsement, endorsement ] }, "data": { ... } } ]]>

Session ID .....hhit.arpa", "sub": ".....hhit.arpa", "iat": 0, "exp": 0, "drip": { "det": "base16 HHIT/DET", "hi": "base64 HI", "endorsements": [ self_endorsement, broadcast_endorsement, mutual_endorsement, endorsement ] }, "data": { "serial": "Serial Number", "session_id": "base16 HHIT/DET of UA", "utm_id": UUIDv4, "utm_src": URI, "operator_det": "base16 HHIT/DET", "operator_id": "CAA Operator ID" } } ]]>

Child DIME .....hhit.arpa", "sub": ".....hhit.arpa", "iat": 0, "exp": 0, "drip": { "det": "base16 HHIT/DET", "hi": "base64 HI", "endorsements": [ self_endorsement, endorsement, broadcast_endorsement ] }, "data": { "name": "", "abbreviation": "", "mfrCode": "", "addr": { "street1": "", "street2": "", "city": "", "sp": "", "pc": "", "cc": "" }, "voice": "", "email": "" } } ]]>

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

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.

OpenAPI Specification TODO