A Method For Identifying a Domain Operator's Point of Contact (WHOAMI)
draft-brown-whoami-01

Abstract

This document proposes a decentralised alternative to traditional WHOIS directories.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 26, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Conventions Used in This Document
• 1.2. Definitions
• 2. WHOAMI Protocol
• 2.1. URI Record
• 2.1.1. URI Record with a data: scheme
• 2.2. Well-Known URL
• 3. Operational Considerations
• 3.1. Domain Registries
• 3.2. Domain Registrants
• 3.3. Domain Operators
• 3.4. WHOAMI Clients
• 4. Security Considerations
• 5. Privacy Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Change History
• A.1. Change from 00 to 01
• Author's Address

1. Introduction

It is common for Domain Registries - whether country-code or generic, operating at the second-level or lower - to operate a directory service to allow interested parties to identify the entity to which a Domain has been allocated. Typically, access to this directory service is provided using WHOIS or RDAP services.

Consequently, Domain Registries have developed a model whereby the Extensible Provisioning Protocol (EPP) is used to collect large volumes of data - much of which is Personal Data (see [RFC6973] for further discussion) - and then make this data available, with few restrictions, to anyone who might want it, for reasons both benign and malign. This is especially the case for generic Top-Level Domain Registries, who are subject to policy obligations which, as of writing, require a uniform data model for Registration Data, and do not permit differentiated access to this data.

This document proposes a decentralised alternative to traditional WHOIS directories. To avoid the need for Domain Registries to collect Registration Data, it provides a means by which Domain Operators may, at their own discretion (or in compliance with a Domain Registry's policy requirements), publish their contact information in a machine-readable manner.

It is contended that this approach eliminates the need for registries to maintain large databases of contact information, while still allowing supporting most of the uses to which such databases are put.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.2. Definitions

In addition to the terms definied in this section, this document makes use of the terminology defined in [RFC7719].

Domain:

A domain object as specified in [RFC5731]. In the DNS, this object corresponds to a Delegation of a "child" Zone from the "parent" Zone operated by the Domain Registry.

Domain Registry:

The entity which (a) operates a provisioning service (such as EPP) for one or more Zones, the Authoritative server(s) for those Zones, and optionally a WHOIS and/or RDAP service.

Domain Registrant:

The entity to whom the operation and usage of a Domain is assigned by a Registry.

Domain Operator:

The entity (or entities) responsible for the administration of the Zone in the DNS corresponding to Domain. The Operator of a Domain may or may not also be its Registrant.

Registration Data:

Metadata about a Domain object, such as its creation, update, and expiration date, the nameservers to which it is delegated, and the sponsoring registrar, plus a collection of zero or more Points of Contact for the Domain Registrant, Domain Operator and/or other entities responsible for the administration of a Domain.

Point of Contact (PoC):

Contact information, including Contact Name, Organisation Name, Postal Addres, email, voice and fax numbers, for a single entity (which may be a natural person or legal entity).

WHOAMI Record:

A Point of Contact in vCard format.

2. WHOAMI Protocol

Domain Operators MAY choose to publish a WHOAMI Record in conformance with this specification. It may be published (a) at a URL indicated by a URI record published in the DNS (as described in Section 2.1), or (b) at a well-known URL (as described in Section 2.2).

Software which consumes WHOAMI records SHOULD first perform a DNS query for the URI record for a Domain, falling back to the well-known URL if the query does not return a positive result.

2.1. URI Record

Domain Operators MAY publish the URL of their WHOAMI record as a URI record in the DNS. An example of such a record is below:

$ORIGIN example.com.
_nicname._tcp IN URI 10 1 https://example.com/whoami/whoami.vcf

Note: the Owner Name, Priority, Weight, and Target in the above record are illustrative only.

The Service Tag of the URI record is constructed as per Section 4.1 of [RFC7553], with the "_nicname" tag being derived from the "Who Is Protocol" entry in the "Service Name and Transport Protocol Port Number Registry (see [RFC6335]).

2.1.1. URI Record with a data: scheme

Domain Operators MAY publish a record with a "data:" scheme. This allows the WHOAMI record to be embedded in the URI record itself. An example of such a URI is below:

data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4w
DQpVSUQ6dXJuOnV1aWQ6NGZiZTg5NzEtMGJjMy00MjRjLTljMjYtMzZjM2UxZWZmNmIxD
QpGTjtQSUQ9MS4xOkouIERvZQ0KTjpEb2U7Si47OzsNCkVNQUlMO1BJRD0xLjE6amRvZU
BleGFtcGxlLmNvbQ0KQ0xJRU5UUElETUFQOjE7dXJuOnV1aWQ6NTNlMzc0ZDktMzM3ZS0
0NzI3LTg4MDMtYTFlOWMxNGUwNTU2DQpFTkQ6VkNBUkQ=

If a "data:" scheme is used, the MIME type of the data MUST be "text/vcard".

2.2. Well-Known URL

Domain Operators MAY publish their WHOAMI record at the following URL:

http://example.com/.well-known/whoami/whoami.vcf

The "whoami" path segment has been registered in the "Well-Known URI Registry" (see [RFC5785]).

Software which consumes WHOAMI records SHOULD follow 3xx redirections return in server responses.

It is RECOMMENDED that web servers which support HTTP over Transport Layer Security provide a 3xx redirect to the HTTPS version of this URL.

The Content-Type header of the server response MUST be "text/vcard".

3. Operational Considerations

3.1. Domain Registries

TODO

3.2. Domain Registrants

TODO

Domain Operators MAY configure the HTTP server which hosts their WHOAMI record to restrict access to this information (based some form of authentication such as HTTP Basic Authentication or OAuth 2.0.

3.3. Domain Operators

TODO

3.4. WHOAMI Clients

TODO

4. Security Considerations

• TODO, but probably lots.

5. Privacy Considerations

• TODO, but probably lots.

6. IANA Considerations

This specification registers the "whoami" well-known URI in the "Well-Known URIs" registry as defined by [RFC5785].

URI suffix: whoami

Change controller: IETF

Specification document(s): (this document)

Related information: no remarks

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Change History

A.1. Change from 00 to 01

Author's Address