Internet Engineering Task Force G. Brown
Internet-Draft CentralNic Group plc
Intended status: Experimental February 22, 2018
Expires: August 26, 2018

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

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

5. Privacy Considerations

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M. and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011.
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015.

7.2. Informative References

[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013.
[RFC7480] Newton, A., Ellacott, B. and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015.
[RFC7719] Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015.

Appendix A. Change History

A.1. Change from 00 to 01

Author's Address

Gavin Brown CentralNic Group plc 35-39 Moorgate London, England EC2R 6AR GB Phone: +44 20 33 88 0600 EMail: gavin.brown@centralnic.com URI: https://www.centralnic.com