Hierarchical ORCHID Management Entity (HOME) Interfaces for Registration & Differential Access Query

1.1. Purpose

An ecosystem using Overlay Routable Cryptographic Hash IDentifiers (ORCHIDs, [RFC7343]) as its primary identifier can be a strong option for modern systems. The Hierarchical Host Identity Tags (HHITs, [RFC9374]) are used in the fast growing sector of Unmanned Aircraft Systems (UAS) to provide identity and authentication services using the Domain Name System (DNS).¶

With standardization, identity ecosystems can be created around the use of ORCHIDs to serve various use-cases. This provides widespread interoperability of the functions of registration, public query and private query using a selection of existing standards and methods. Being backed by cryptographic keys allow existing key infrastructure, certificates and policy to be leveraged with minimal overhead, modification or redeployment.¶

1.2. Background

HHITs are an evolution of the Host Identity Tags (HITs) in the Host Identity Protocol (HIP, [RFC9063]). All of these tags are categorized as an ORCHID which were standardized in [RFC7343] and updated by [RFC9374]. HHITs solve the problem of HITs being a flat namespace, which is hard to manage at a global scale, by adding hierarchy into the identifier. When the hierarchy is laid onto the DNS, interoperability of lookups becomes trivial.¶

[RFC9434] introduces the concept of the DRIP Identity Management Entity (DIME) that provides the critical function of registering and querying information around DETs. It further specifies logical entities of the Public Information Registry and Private Information Registry of which the former has been specified in [RFC9886] using the DNS.¶

The concept of the DIME can be backported to ORCHIDs in general with the addition of the term ORCHID Management Entity (HOME). In relation to key infrastructure policies and certificates the terms ORCHID Key Infrastructure (OKI) and ORCHID Key Infrastructure X.509 (OKIX) are introduced here to mirror but be distinct from the existing Public Key Infrastructure (PKI) and Public Key Infrastructure X.509 (PKIX).¶

1.3. Scope

This document provides specification of the interfaces and models for registration and differential access query of ORCHIDs to support identity services under an HOME. This is to provide specification for the final missing pieces of a DIME and is the exemplar use-case of using HHITs, such as the DET, as the core of an identity ecosystem.¶

The term HHIT is used when discussing the general technology while DET is used with discussion around UAS/aviation specific elements when possible. Additional terms reinforcing this delineation are found in Section 2. This document defines all data models in the Concise Data Definition Language (CDDL, [RFC8610]) with the full specification in Appendix B.¶

2.1. Additional Definitions & Abbreviations

Hierarchical ORCHID Management Entity (HOME):

A term to describe an entity providing various identity management functions (such as registration, query, etc.) to clients at a specific point in the hierarchy. HOME's have four major functional components that can be co-located or distributed as a system of systems: Registrar, Registry, Authoritative Name Server and Certificate Authority. The DRIP Identity Management Entity (DIME) is a specialization of HOME in support of the UAS/aviation ecosystem.¶

ORCHID Key Infrastructure (OKI):

A key infrastructure consisting of policies around entities using HHITs in a domain space. An example of an OKI is the DRIP Key Infrastructure (DKI) for UAS/aviation.¶

ORCHID Key Infrastructure X.509 (OKIX):

A set of X.509 certificate profiles in compliance of Public Key Infrastructure X.509 (PKIX, [RFC5280]) that support an OKI. An example of an OKIX is the DRIP Key Infrastructure X.509 (DKIX) for UAS/aviation.¶

HOME Token:

In the context of this specification; a HOME Token can be any of the Concise Binary Object Representation (CBOR; [STD94]) Object Signing & Encryption (COSE; [STD96]) or JavaScript Object Notation (JSON; [STD90]) Object Signing & Encryption (JOSE; [RFC7515], [RFC7516]) structure. See Section 4.1.¶

HRI Token:

A HOME Token containing an HRI claim per Section 4.2.1.¶

HRR Token:

A HOME Token containing an HRR claim per Section 4.2.2.¶

4.1. HOME Token

A HOME Token MUST be encoded in either COSE or JOSE. A token MAY contain multiple layers and SHOULD have the Content-Type parameter, as part of an unprotected header, set accordingly for each.¶

4.2. Claims Set

A HOME Token is at its core a set of claims using a CWT or JWT claim set. The claims defined in this section are registered in the respective registries in Section 7.2 and either or both MUST be included in the claim set for HOME Tokens. A HOME Token carrying either of these claims is considered as an HRI Token or HRR Token respectively.¶

The claim set SHOULD also contain the claims of nbf, exp, and iat. The set MAY contain the aud or iss claim with a targeted HHIT, encoded per Appendix B.3, if known. Additional claims are out of scope for this document.¶

The layer (Section 4.1.1 or Section 4.1.2) carrying a claim set is RECOMMENDED to set the Content-Type parameter, as part of the unprotected header, to application/home+cbor or application/home+json. This SHOULD include the ctx parameter to indicate the set of keys/parameters being used for any maps in the payload structure as they are application specific.¶

inquiry = [
  entities: { &(entity-id) => entity },
  metadata: map / null
]
entity = [
  hhit_entity_type: uint,
  keys: { &(key-id): key },
  metadata: map / null
]
key = [
  csr: bytes / text .b64u bytes,
  metadata: map / null
]

response = [
  success: [
    entities: { &(entity-id): success-data },
    shared: map
  ] / null,
  failure: [ + error-data ] / null
]
success-data = [
  keys: { &(key-id): map },
  shared: map
]
error-data = [
  eid: &(entity-id) / null,
  kid: &(key-id) / null,
  cat: any,
  msg: any
]

4.3. Considerations

4.4. Transport

This document defines the use of HTTPS as the transport for the HOME Tokens. The use of other transports are out of scope for this document.¶

For COSE, the resulting CBOR content MUST use a proper CBOR Tag to indicate what object is encoded. For JOSE content, the General or Flattened JWE JSON Serialization syntax MUST be used.¶

The "Content-Type" header of HTTPS SHOULD be used to indicate the content typing. For JOSE this is application/jose+json and for COSE is one of the following: application/cose; cose-type="cose-sign, application/cose; cose-type="cose-sign1, application/cose; cose-type="cose-encrypt, application/cose; cose-type="cose-encrypt0.¶

5.1. RDAP Query

A Querent with an HHIT looking for private information is RECOMMENDED to perform a series of DNS queries to build a URI that is then used for an HTTPS GET query. The same URI MAY be obtained using the RDAP bootstrap process if the HOME followed RFC9224, but Querants MUST NOT expect this.¶

The base URI needed is part of Subject Alternative Name extension of a Canonical Registration Certificate found in HHIT RRType defined in Section 5.1 of [RFC9886] and accessed by one or more reverse IPv6 DNS lookups. The exact certificate with the base URI for an HOME and its clients is determined by policy and where the URI is minimally duplicated across many certificates.¶

Once the base URI is found the Querant concatenates the /.well-known/home/query/ string then the nibble-reversed HHIT to form the full query string.¶

The HTTPS GET method MUST be authenticated using one of the methods defined in Section 5.2.¶

5.2. Differential Access Control

Per REG-2 and REG-4 of Section 4.4.1 of [RFC9153], RDAP queries to an HOME MUST be protected using fine-grained AAA policies in a both human- & machine-readable form for automated enforcement. RDAP supports only HTTP-based mechanisms for authentication as defined in Section 3.2 of [RFC7481]. A federated authentication mechanism, such as the examples in Section 3.2.1 of [RFC7481], is RECOMMENDED.¶

For international and/or global harmonization, this document standardizes the following RDAP behavior for authentication of clients and servers:¶

• MUST support HTTP Basic or Digest Authentication Scheme per Section 3.2 of [RFC7481] AND¶

• MUST support Mutual TLS per Section 7.4.6 of [RFC5246] for global and/or international queries AND¶

• SHOULD use Mutual TLS but MAY do any RDAP compatible AAA for domestic queries¶

An HOME, when supporting Mutual TLS, SHOULD accept valid OKIX-compliant certificates and MAY accept other [RFC5280] (PKIX) compliant certificates. Standard TLS rejection methods MUST be followed to signal to the Querant the rejection of the certificate and authentication.¶

The use of other RDAP compatible authentication mechanisms are out of scope for this document.¶

5.3. RDAP Extension & Response

A HOME MUST respond to a successful query using RFC9083. The HOME RDAP Extension shown in Figure 6 is placed under the key home as part of the main JSON map. The rdapConformance array MUST include the string literal of "home_v0" to signal conformance with this specification. Other RDAP specifications MAY be part of the response such as Section 5.4 of [RFC9083].¶

[
  hhit: [ ip6: text, hhit_entity_type: uint ],
  canon_x: text .b64u bytes,
  metadata: map / null
]

hhit:

Array structure contain the HHIT Entity Type and the HHIT encoded per Appendix B.3.¶

canon_x:

Canonical Registration Certificate encoded in base64url.¶

metadata:

Map that contains private information elements associated with the registration. Elements included are based on access policy and registration requirements of the HOME. Elements are redacted or removed using policy methods of the HOME and is out of scope for this document.¶

6.1. Hierarchy Responsibilities

An HOME has a number of responsibilities depending on its place in the hierarchy. This section covers the technical responsibilities of each level of an HHIT's hierarchy. Specific non-technical policies for hierarchy levels are out of scope for this document and are expected to be developed into OKI policy guidance or added to existing PKI policy guidance for each use-case.¶

6.2. ORCHID Key Infrastructure X.509 (OKIX)

Existing Public Key Infrastructure X.509 (PKIX) certificate profiles can be augmented to support HHITs creating ORCHID Key Infrastructure X.509 (OKIX) profiles.¶

Other X.509 fields and OIDs MAY be required in a given jurisdiction. This is up to the original PKI(X) policy if applicable and is out of scope for this document.¶

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: <subject to policy>
        Subject Public Key Info: <subject to policy>
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: critical
                IP Address: <subject HHIT>
    Signature Algorithm: <subject to policy>

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: <1 byte in size>
        Signature Algorithm: <subject to policy>
        Issuer: CN = <issuer HHIT>
        Validity
            Not Before: <subject to policy>
            Not After : <subject to policy>
        Subject: <subject to policy>
        Subject Public Key Info: <subject to policy>
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address: <subject HHIT>
    Signature Algorithm: <subject to policy>

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: <20 bytes in size>
        Signature Algorithm: <subject to policy>
        Issuer: CN = <issuer HHIT>
        Validity
            Not Before: <subject to policy>
            Not After : <subject to policy>
        Subject: <subject to policy>
        Subject Public Key Info: <subject to policy>
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address: <subject HHIT>
                URI: <subject to policy>
            X509v3 Subject Key Identifier: <subject HHIT>
            X509v3 Authority Key Identifier: <issuer HHIT>
            X509v3 Basic Constraints: critical
            X509v3 Key Usage: critical
    Signature Algorithm: <subject to policy>

7.1. Well-Known URIs

IANA is requested to add the following entries in the "Well-Known URIs" registry [IANA.WellKnownURIs].¶

• Author Note: should we also add Well-Known URIs for update and delete methods? This would then cover all parts of CRUD.¶

7.2. CWT & JWT Claims

HOME Tokens contain a Claim Set compatible with those of CWT and JWT, so the CWT and JWT Claims registries, [IANA.CWT.Claims] and [IANA.JWT.Claims], are reused. No new IANA registry is created.¶

Per this specification, the following values are requested to be added to the "JSON Web Token Claims" registry established by [RFC7519] and the "CBOR Web Token (CWT) Claims" registry established by [RFC8392]. Each entry is requested to be added to both registries. The "Claim Description", "Change Controller", and "Reference" fields are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Type" fields are for the CWT registry only. The "Claim Name" field is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" field is equivalent to the "Claim Name" field in the JWT registry.¶

Claim Name: HOME Registration Inquiry
Claim Description: HOME Registration Inquiry
JWT Claim Name: hri
Claim Key: TBD1
Claim Value Type: array
Change Controller: IETF
Reference: This RFC

Claim Name: HOME Registration Response
Claim Description: HOME Registration Response
JWT Claim Name: hrr
Claim Key: TBD2
Claim Value Type: array
Change Controller: IETF
Reference: This RFC

7.3. RDAP Extensions Registry

IANA is requested to register the following value in the "RDAP Extensions" registry [IANA.RDAP.Extensions].¶

Extension Identifier:
  home_v0
Registry Operator:
  Any
Specification:
  This specification
Contact:
  IETF <iesg@ietf.org>
Intended Usage:
  This extension is used to convey private information
  stored under a HOME registration.

7.4. HHIT Entity Types

IANA is requested to make the following changes to the "HHIT Entity Types" registry under [IANA.DRIP] to align with Table 7.¶

The above changes include two new fields for "Abbreviation" and "Operational (Y/N)", re-arrangement of the first 15 values and addition of entries for Authorization and Issuing for applicable entity types.¶

7.5. HOME Parameters

This document requests IANA create a new registry under [IANA.DRIP] called "HOME Parameters" with registry policies described in Table 8.¶

The positive integer values (including zero) MUST NOT be directly allocated. Instead new registries for specific use-case parameters/keys are created, inherit the HOME Common Parameter registry (Section 7.6) for negative values, and setup new allocation schemes for the positive integers in their scope. See Section 7.7 for an example. Such a new registry SHOULD have an associated Media Type to allow participants a mechanism to explicitly provide context for the parameter set in use.¶

Key:
Description:
Name:
Label:
Value Type:
Change Controller:
Reference:

7.6. HOME Common Parameters

This document requests IANA create a new registry under [IANA.DRIP] called "HOME Common Parameters" with registry policies described in Table 9. Initial entries for this registry are in Figure 15 and uses the registration form of Section 7.5.2.¶

Key: HHIT
Description: Hierarchial Host Identity Tag & Entity Type
Name: hhit
Label: -1
Value Type: array
Change Controller: IETF
Reference: This RFC

Key: VNB
Description: Valid Not Before
Name: vnb
Label: -2
Value Type: tdate / time
Change Controller: IETF
Reference: This RFC

Key: VNA
Description: Valid Not After
Name: vna
Label: -3
Value Type: tdate / time / number
Change Controller: IETF
Reference: This RFC

Key: Publish
Description: Boolean to publish to DNS
Name: publish
Label: -4
Value Type: bool
Change Controller: IETF
Reference: This RFC

Key: Certificate Signing Request (CSR)
Description: DER Encoded X.509 CSR
Name: csr
Label: -5
Value Type: bytes
Change Controller: IETF
Reference: This RFC

Key: Oracle Certificate
Description: DER Encoded Oracle X.509 Certificate
Name: oracle_x
Label: -6
Value Type: bytes
Change Controller: IETF
Reference: This RFC

Key: Canonical Certificate
Description: DER Encoded X.509 Certificate
Name: canon_x
Label: -7
Value Type: bytes
Change Controller: IETF
Reference: This RFC

Key: Canonical Certificate Chain
Description: List of DER Encoded X.509 Certificates
Name: canon_chain
Label: -8
Value Type: array
Change Controller: IETF
Reference: This RFC

Key: Contact
Description: Base64 Encoded jCard Contact Information
Name: contact
Label: -9
Value Type: text
Change Controller: IETF
Reference: This RFC

7.7. HOME Aviation Parameters

This document requests IANA create a new registry under [IANA.DRIP] called "HOME Aviation Parameters" with registry policies described in Table 10. Initial entries for this registry are in Figure 16 and uses the registration form of Section 7.5.2.¶

When using this registry the "ctx" parameter of Section 7.8 is set to "aviation".¶

Key: UAS Type
Description: ASTM F3411 UAS Type Enumeration
Name: uas_type
Label: 0
Value Type: uint
Change Controller: IETF
Reference: Section 5.2 of RFC9886

Key: UAS Identifiers
Description: UAS ID Type & Value Pairs
Name: uas_ids
Label: 1
Value Type: array
Change Controller: IETF
Reference: Section 5.2 of RFC9886

Key: Authentication Data
Description: Authentication Type & Data Pairs
Name: auths
Label: 2
Value Type: array
Change Controller: IETF
Reference: Section 5.2 of RFC9886

Key: Self ID
Description: Self Description Type & Value
Name: self_id
Label: 3
Value Type: array
Change Controller: IETF
Reference: Section 5.2 of RFC9886

Key: UAS Classification
Description: UAS Category & Class
Name: classification
Label: 4
Value Type: array
Change Controller: IETF
Reference: Section 5.2 of RFC9886

Key: Area
Description: Count, Radius, Floor & Ceiling
Name: area
Label: 5
Value Type: array
Change Controller: IETF
Reference: Section 5.2 of RFC9886

Key: Operator ID
Description: UAS Pilot Operator ID
Name: operator_id
Label: 6
Value Type: array
Change Controller: IETF
Reference: Section 5.2 of RFC9886

7.8. Media Types

IANA is requested to add the entries of Table 11 to the "Media Types" registry [IANA.MediaTypes].¶

Type name:
  application
Subtype name:
  home+cbor
Required parameters:
  N/A
Optional parameters:
  "ctx" (Context as a string for map keys. Case insensitive.)
Encoding considerations:
  binary
Security considerations:
  N/A
Interoperability considerations:
  N/A
Published specification:
  This RFC
Applications that use this media type:
  Entities that exchange CBOR/COSE data as part of HOME interactions.
Fragment identifier considerations:
  N/A
Person & email address to contact for further information:
  DRIP WG mailing list (tmrid@ietf.org)
Intended usage:
  Common
Restrictions on usage:
  None
Author/Change controller:
  IETF
Provisional registration:
  No

Type name:
  application
Subtype name:
  home+json
Required parameters:
  N/A
Optional parameters:
  "ctx" (Context as a string for map keys. Case insensitive.)
Encoding considerations:
  same as STD90
Security considerations:
  N/A
Interoperability considerations:
  N/A
Published specification:
  This RFC
Applications that use this media type:
  Entities that exchange JOSE/JSON data as part of HOME interactions.
Fragment identifier considerations:
  N/A
Person & email address to contact for further information:
  DRIP WG mailing list (tmrid@ietf.org)
Intended usage:
  Common
Restrictions on usage:
  None
Author/Change controller:
  IETF
Provisional registration:
  No

7.9. CoAP Content-Format

IANA is requested to add the entries of Table 12 to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.CORE].¶

8.1. AAA

OMEs use and provide various methods to protect data through: Attestation, Authentication, Authorization, Access Control, Attribution, Accounting, and Audit (AAA). All data, handled under DRIP, MUST be protected by AAA, as per applicable regulation and policy (which, in some cases, for public data, may impose minimal requirements). All private data MUST also be protected by strong encryption where permitted by applicable law etc. These requirements apply to data at rest and in transit in all phases of the process, i.e. registration and query.¶

Attestation may be mandated by a jurisdiction for devices. Remote ATtestation ProcedureS (RATS, [RFC9334]) is recommended for such mandates. The specific attestation mechanisms are out of scope for this document.¶

8.2. Cryptographic Materials

Best practices dictate that cryptographic materials that should only be available to selected parties SHOULD be generated by one or more of those parties and stored accessibly only on those parties devices. E.g. the asymmetric key-pair from which an HHIT will be derived SHOULD be generated by the entity identified by that HHIT and the corresponding private key should be stored only on that entity's device. There may be scenarios where other parts of a system, such as a UAS, generates the cryptographic materials and provision them as needed during an operation. Any such system MUST ensure security of the cryptographic material is guaranteed.¶

10.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5246]

Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/rfc/rfc5246>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7516]

Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/rfc/rfc7516>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9153]

Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022, <https://www.rfc-editor.org/rfc/rfc9153>.

[RFC9164]

Richardson, M. and C. Bormann, "Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021, <https://www.rfc-editor.org/rfc/rfc9164>.

[RFC9374]

Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, <https://www.rfc-editor.org/rfc/rfc9374>.

[RFC9434]

Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July 2023, <https://www.rfc-editor.org/rfc/rfc9434>.

[RFC9886]

Wiethuechter, A., Ed. and J. Reid, "DRIP Entity Tags (DETs) in the Domain Name System", RFC 9886, DOI 10.17487/RFC9886, December 2025, <https://www.rfc-editor.org/rfc/rfc9886>.

[STD95]

Internet Standard 95, <https://www.rfc-editor.org/info/std95>.
At the time of writing, this STD comprises the following:

Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-editor.org/info/rfc7480>.

Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-editor.org/info/rfc7481>.

Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, <https://www.rfc-editor.org/info/rfc9082>.

Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, <https://www.rfc-editor.org/info/rfc9083>.

Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, <https://www.rfc-editor.org/info/rfc9224>.

[STD96]

Internet Standard 96, <https://www.rfc-editor.org/info/std96>.
At the time of writing, this STD comprises the following:

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/info/rfc9052>.

Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, <https://www.rfc-editor.org/info/rfc9338>.

10.2. Informative References

[IANA.CBOR.Tags]

IANA, "CBOR Tags", November 2025, <https://www.iana.org/assignments/cbor-tags/cbor-tags/>.

[IANA.CORE]

IANA, "CoAP Content-Formats", July 2025, <https://www.iana.org/assignments/core-parameters>.

[IANA.CWT.Claims]

IANA, "CBOR Web Token (CWT) Claims", November 2025, <https://www.iana.org/assignments/cwt/>.

[IANA.DRIP]

IANA, "Drone Remote ID Protocol", October 2025, <https://www.iana.org/assignments/drip/>.

[IANA.JWT.Claims]

IANA, "JSON Web Token (JWT) Claims", November 2025, <https://www.iana.org/assignments/jwt/>.

[IANA.MediaTypes]

IANA, "Media Types", July 2025, <https://www.iana.org/assignments/media-types>.

[IANA.RDAP.Extensions]

IANA, "RDAP Extensions", July 2025, <https://www.iana.org/assignments/rdap-extensions/>.

[IANA.WellKnownURIs]

IANA, "Well-Known URIs", July 2025, <https://www.iana.org/assignments/well-known-uris/>.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC7343]

Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, <https://www.rfc-editor.org/rfc/rfc7343>.

[RFC7401]

Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/rfc/rfc7401>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8003]

Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, <https://www.rfc-editor.org/rfc/rfc8003>.

[RFC8004]

Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, <https://www.rfc-editor.org/rfc/rfc8004>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC9063]

Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, <https://www.rfc-editor.org/rfc/rfc9063>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[STD69]

Internet Standard 69, <https://www.rfc-editor.org/info/std69>.
At the time of writing, this STD comprises the following:

Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.

Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.

Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, <https://www.rfc-editor.org/info/rfc5732>.

Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, <https://www.rfc-editor.org/info/rfc5733>.

Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, <https://www.rfc-editor.org/info/rfc5734>.

[STD90]

Internet Standard 90, <https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[STD94]

Internet Standard 94, <https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

A.1. Use Case Example

An an example, the binding between UAS Serial Number and Operator ID should already be known by the CAA, as typically this information is required out of band of DRIP directly to the CAA in some form. The CAA should provide or itself have access to an "oracle" that can validate these claimed bindings for registration to proceed. When an "oracle" is not consulted there is a risk that the a recorded binding between UAS and Operator is non-existent, resulting in faulty CAA enforcement capabilities.¶

A.2. Expected HOME Behavior

HOME's when presented with additional information that requires an "oracle", MUST forward without modification the Registrants HOME Token for processing to their RAAs "oracle-as-a-service" endpoint. HOME's acting as an RAA under this specification MUST always provide the "oracle-as-a-service" endpoint (/.well-known/home/oaas) and respond as follows:¶

• return an applicable HTTP Response error when the "oracle" does not exist within a given jurisdiction¶

  • OMEs receiving such a response SHOULD proceed as if the "oracle" successfully validated the request¶

• perform a redirect to appropriate system when "oracle" is being provided as a 3rd party service that the HDAs are expected to independently consult¶

• process and respond following Appendix A.3¶

OMEs process non-error HTTP codes by including the returned "oracle" certificate in artifacts in the Private Information Registry and continuing the registration process. An error HTTP code received by a HOME MUST be mimicked back to the Registrant.¶

A.3. Expected Oracle Behavior

The "oracle" MUST validate the HOME Token signature before processing any of the claim data it has authority over. Additional authentication and/or authorization on the endpoint MAY be required by a jurisdiction and its selection, implementation and policy are out of scope for this document.¶

If an "oracle" accepts the data presented it MUST respond with a valid X.509 certificate, RECOMMENDED to be OKIX compliant, with the Subject set to the same contents as the Registrant CSR. When a "oracle" denies any data presented it MUST respond with an appropriate HTTP Response code and MUST NOT include a reason. This is to avoid clients data mining information to forge malicious requests. Once the "oracle" has completed its validations on fields it has authority over and responded accordingly the HOME Token MUST be deleted from the "oracle".¶

The policy and other inner mechanics of the "oracle" are out of scope for this document.¶

B.1. Prelude

The HOME CDDL Prelude of Figure 19 is built upon the prelude defined in Appendix E of [RFC8610] to allow interoperability with JSON encodings. The conversion of fields to/from CBOR and JSON MUST use the advice in Section 6 of [RFC8949].¶

entity-id = int / text
key-id = int / text
map = { &(int, text) => any }

B.2. HRI & HRR Claims

The full claim set for HRI and HRR, including prelude, are shown in Figure 20.¶

rdap = [
  hhit: [ ip6: text, hhit_entity_type: uint ],
  canon_x: text .b64u bytes,
  metadata: map / null
]

response = [
  success: { &(entity-id): success-data } / null
  failure: [ + error-data ] / null
  shared: map / null
]
success-data = [
  keys: { &(key-id): map },
  shared: map / null
]
error-data = [
  eid: &(entity-id) / null,
  kid: &(key-id) / null,
  cat: any,
  msg: any
]

inquiry = [
  entities: { &(entity-id) => entity },
  metadata: map / null
]
entity = [
  hhit_entity_type: uint,
  keys: { &(key-id): key },
  metadata: map / null
]
key = [
  csr: bytes / text .b64u bytes,
  metadata: map / null
]

entity-id = int / text
key-id = int / text
map = { &(int, text) => any }

B.3. IPv6 Handling

IPv6 addresses MUST be tagged using [RFC9164] when encoded in CBOR. For JSON, IPv6 addresses MUST be an address string as defined in [RFC4291], Section 2.2.¶

B.4. HOME Common Parameters

hhit = [
  ip6: #6.54(bytes .size(16)) / text, ; ip6 addr tstr
  hhit_entity_type: uint
]
vnb = tdate / time
vna = tdate / time / number
publish = bool
csr = bytes / text .b64u bytes ; DER encoded
oracle_x = bytes / text .b64u bytes ; DER encoded
canon_x = bytes / text .b64u bytes ; DER encoded
canon_chain = [ bytes / text .b64u bytes ] ; DER encoded
contact = text ; b64 encoded jCard object

B.5. HOME Aviation Parameters

These parameters are carried over from Section 5.2 of [RFC9886]. The content in Figure 22 carries the same semantics from [RFC9886] but is more well-defined in syntax of CDDL.¶

uas_type = (uint .le 15) .default 0
uas_ids = [ + [
  id_type: uint .le 15,
  uas_id: bytes .size(20)
] ]
auth = [ + [
  type: uint .le 15,
  data: bytes .size(1..362)
] ]
self_id = [
  type: uint .size(1),
  description: text .size(23)
]
area = [
  count: (uint .size(1)) .default 1,
  radius: number,
  floor: number,
  ceiling: number
]
classification = [
  type: (uint .le 8) .default 0,
  class: (uint .le 15) .default 0,
  category: (uint .le 15) .default 0
]
operator_id = [
  type: uint .size(1),
  id: bytes .size(20)
]