| Internet-Draft | DNS Account Handles | January 2025 |
| Hallam-Baker | Expires 26 July 2025 | [Page] |
A proposal for use of DNS names to support universal account identifiers 'handles' is described. Once registered, a handle may be used for authentication to any network service, to initiate communication with the holder or as the basis for IoT device management.¶
This document is a whitepaper proposing the general approach. A strawman prototype supporting single account Web login across multiple sites, onboarding of IoT devices and end to end secure messaging, file-drop, voice and video and has been built using existing and proposed IETF work.¶
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 26 July 2025.¶
Copyright (c) 2025 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.¶
The naming of devices, hosts and services has been a core concern in network protocol design from the earliest days of computer networking. In the Internet architecture, the primary means by which services and devices are identified to users is by DNS name.¶
While DNS has proved remarkably successful within its design scope, attempts to provide users with universally recognized identifiers have proved less successful. Most Web sites require users to create a separate account with a username and password for authenticated access.¶
Being required to remember they have created an account with a site at all represents an unacceptable imposition on the user, let alone remembering the username. The notion that users should be expected to create and remember a strong, unique password for every site they might with to interact with is a colossal absurdity no matter how many times 'experts' intone their sage security wisdom.¶
OAUTH2 allows a user with an account held at one service to access resources at another and OpenID connect purports to provide a form of portable account login across the Web. But in practice this only works for users with accounts at a small and shrinking number of providers and introduces serious business concerns for relying parties facing competition from the monopolist providers.¶
The ATprotocol [atproto], proposed by BlueSky allows users to use any DNS name they control as an account identifier.¶
This whitepaper shows how the ATprotocol scheme may be used as a general-purpose Web account login scheme and proposes modifications to the approach to make the use of DNS names as authentication handles entirely independent of the services that rely on them. The use of DNS handles is then extended to support all the personal identity services an Internet user might require including initiating communications with other users and provisioning IoT devices with network names and credentials.¶
Naming is a central concern in network architecture because different forms of identifiers offer different properties. The use of DNS names as identifiers emerged from the use of the 'hosts.txt' file to provide stable, user-facing names in place of the IP addresses used at the network layer.¶
Three types of handle are defined:¶
Direct Trust Fingerprints [@mbqc-7oha-rnba-frdl-r4gi-yqha-dl36]¶
An immutable globally unique identifier derived from a public key that serves as a root of trust for validating assertions related to the thing identified.¶
DNS Name Handles [@alice.example.com]¶
A public DNS name that serves as a unique user-facing identifier. For example, Alice might register the name example.com and issue herself the handle @alice.example.com. As with all DNS names, DNS name handles are mutable, particularly when the holder of the handle does not control the underlying DNS names.¶
To allow DNS Name Handles to be distinguished from Personal Names, a DNS Name Handle MUST have at least two labels.¶
Personal Names [@doctor]¶
A private name that only has interpretation for the individual user. For example, Alice might user the personal name @doctor to refer to her personal physician and @bank to refer to her banker, changing the binding of these names as necessary.¶
Personal Names typically have a single label but personal names MAY be defined with two or more labels as a means of overriding the public interpretation of a DNS Name Handle.¶
This approach does not guarantee that the interpretation of a DNS Name handle will be immutable but does ensure that it will only change when the controller of the underlying DNS registration intends.¶
Similarly, the binding of a personal name is entirely under the control of the user defining it. Thus if Bob exchanges contact details with Alice when she is using the handle @alice.example.com, he can assign Alice the personal name @alice to ensure that whenever he interacts through that handle, he will be interacting with the Alice he expects.¶
The infrastructure described in this document anticipates the provision of a suite of Internet service to permit use of the handle in different contexts:¶
To publish records corresponding to the handle under management.¶
To manage authentication requests under the handle.¶
To relay provisioning requests for network names and credentials to the relevant DNS and CA services.¶
To manage the user's contact catalog and synchronize it across their devices.¶
To broker device to device connections when establishing synchronous communication (chat, voice, video)¶
While the services proposed as the means of delivering the last three of these services are based on the Mathematical Mesh platform, these services could be provided by any platform(s) offering similar functionality.¶
It is anticipated that a range of providers will offer services under a variety of business models including free at point of delivery and subscription based. For the purposes of this document, there are two important differences:¶
The DNS name is registered by the user of the handle.¶
The DNS name is registered under a DNS name held by the service provider who allows the user temporary use of the handle that can in principle be revoked at any time.¶
At-Will registrations subordinate the user's autonomy to that of the service provider but allow service providers to offer precisely the same functionality as personal registrations without charging a registration fee.¶
Personal registration offers the name holder the ability to change service providers at any time without switching costs.¶
Use of DNS handles allow social media platforms to offer users a common identity across independent platforms. Alice can identity herself as @alice.example.com at a microblogging site, a photo sharing site and commenting on Web forums and other user's personal blogs. Other users can recognize these contributions as all being from the same person.¶
Interoperability is achieved through the use of a common identity, it is not necessary for the platforms to be members of a common information exchange federation or run any common protocol except for those used to translate DNS handles into direct trust fingerprints (DNS) and to perform authentication (OAUTH2).¶
Once it is established that a user will use a DNS handle as a common identity for authentication purposes, it is natural for them to expect use of the same handle for other purposes. If Bob knows that Alice has the DNS handle @alice.example.com, it is natural for him to expect to find a personal site about Alice at https://alice.example.com/ and to be able to use the same identifier to contact Alice through email and other modes of communication.¶
A common identification infrastructure facilitates implementation of traditional paid-content models and permits the creation of new ones. For example, Alice might subscribe to a curated feed of international news with links to articles that would normally require a separate subscription fee.¶
Traditional approaches to privacy protection have focused on making it difficult for third parties to aggregate information across sites with mixed success. While each individual DNS handle is a globally unique identifier whose very purpose is to link activity across different sites, there is no limit to the number of DNS handles a user can use and with appropriate client support, 'disposable' handles may be registered as needed.¶
When the Internet first emerged as a public infrastructure in the mid 1990s, person-to-person communication was limited to emails and a rudimentary form of chat. Today, users communicate through myriad platforms offering diverse combinations of synchronous and asynchronous messaging, text, image, audio and video, almost every platform except for the venerable SMTP is a walled garden requiring a separate account and applications.¶
DNS handles provide a basis for establishing person-to-person and person-to-group communications by any modality using a common identifier controlled by the user.¶
Support for end-to-end encryption has been widely regarded as an essential feature for new personal communications services for over a decade. But while applying encryption to the communication channel is straightforward, almost none provide end-to-end trust and those that do typically support it in a form no real user could possibly be expected to make use of.¶
All that is required to intercept end-to-end encrypted communications is the ability to perform an active on path attack and to convince the parties to use keys of the attacker's choosing. Almost every provider of such services has the ability to perform such an attack and by extension, so does any party that is able to coerce the service provider.¶
Use of a common identifier bound to a Direct Trust Fingerprint allows the user to take full control of their communications security. Once Alice and Bob have exchanged contact information, their communications will be authenticated and encrypted under the immutable Direct Trust Fingerprint stored in the contacts catalogs under their personal control.¶
When the Internet was originally built, computers were large, expensive devices, typically shared among a large number of users. Today, a typical home contains tens or hundreds of computers, an increasing proportion of which require local network or Internet connectivity for optimal functionality.¶
Provisioning consumer devices in the 'Internet of Things' with the names and credentials required for network functionality has been regarded as a hard problem for many years. Once it is decided that each Internet user is going to have their own DNS name, the solution to these provisioning difficulties becomes obvious: The devices will use the DNS for naming and PKIX credentials binding public keys to those DNS names to establish secure communications.¶
Thus, if Alice buys a coffee pot and gives it the name 'coffee', the relevant configurations should be made to the local and public DNS and a WebPKI certificate acquired to access the device as https://coffee.alice.example.com/¶
All the component protocols required to support this configuration after a device has been onboarded to the user's control exist already. Multiple options exist for supporting onboarding of devices. The only thing lacking is a service to accept network naming and credentialling requests from devices and forward the relevant configuration updates to the services selected by the user.¶
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
This is an informational document and does not contain any normative language.¶
ACME¶
At-Will Registration¶
Certificate Authority¶
Cross Certificate¶
DID¶
Direct Trust Fingerprints¶
DNS Authoritative¶
DNS Name Handle¶
DNS Primary¶
Handle¶
Intermediate Certificate¶
OAuth Client¶
OAuth Resource Server¶
Personal Name¶
Personal Registration¶
Private Certificate Root¶
WebPKI¶
Reference code under the MIT Open Source license has been developed to demonstrate all the features described in this document.¶
To access an Internet service using a DNS handle or a personal name, an application requires three pieces of information:¶
The DNS name of the service and Direct Trust Fingerprint are obtained from a DNS handle or personal name through the Handle resolution process.¶
Handle resolution is performed in the following order with resolution by means of a Personal Contact Assertion having the highest precedence:¶
Personal Contact Assertion¶
DNS TXT¶
HTTP Well-Known¶
Users MAY use the platform and technology of their choice for resolution of personal names. It is highly desirable but not essential for contacts to be synchronized across devices so that the user enjoys a consistent experience. But even here, personal requirements may come first. A developer might choose to use a separate personal name resolution platform for test purposes.¶
Mesh Contact Catalogs provide one means of expressing personal name bindings and synchronizing them between devices. Entries in the catalog contain the following information¶
A set of local names to which the contact is bound¶
A dictionary mapping DNS protocol identifiers (e.g. 'SMPT') to addresses¶
Contact credentials (e.g. PKIX certificates)¶
[Optional] Source material(s) from which the contact data was obtained¶
[Optional] Update information¶
Personal names MAY be bound to any protocol including those that do not use DNS name handles. This allows an application to allow Bob to send an email to Alice using the name @alice and select the SMTP transport and address alice@example.com if that is the most appropriate protocol Alice allows Bob to use.¶
Similarly, personal contact assertions MAY be used to provide supplemental means of contacting a user known through their DNS handle.¶
The primary means for resolving DNS Handles is through the DNS. Publication and resolution are performed according to the mechanisms described in [RFC6763], [RFC8552] and [RFC8553].¶
The ATprotocol specifies a single TXT record that binds a DNS handle to a DID. For example, the following record binds the handle @bsky.app to the DID did:plc:z72i7hdynmk6r22z27h6tvur:¶
atproto.bsky.app TXT did=did:plc:z72i7hdynmk6r22z27h6tvur¶
The ATprotocol resolution protocol defines a resolution mechanism that allows the DID to be resolved to determine the corresponding ATprotocol resource server from which the OAuth2 authentication service MAY be determined. In the case that we are using the DNS handle as a generic authentication mechanism, it is more convenient to be able to obtain the OAUTH service address directly from the DNS by means of an SRV record¶
_oauth._tcp.bsky.app SRV 1 1 443 bsky.social¶
The authorization service record MAY optionally publish a TXT record to specify the location of the authorization server metadata:¶
_oauth._tcp.bsky.social TXT \¶
"meta=https://bsky.social/.well-known/oauth-authorization-server"¶
Since the TXT record merely specifies the default URI for locating the metadata for the OAUTH service, it does not add value in this particular case. But in the case that the DNS zone is authenticated by DNSSEC, the record might contain an additional entry to authenticate the metadata document by means of a fingerprint of the document and/or a self-authenticating resolution mechanism such as an EARL [draft-hallambaker-mesh-udf].¶
While manual management of such DNS records is likely to prove impractical, a mechanism for automation of the zone entries is described in this document.¶
The same approach is used to publish the User Profile Fingerprint and services used to support communication by Mesh messaging and presence.¶
In the case that the number of services and protocols supported becomes large, it is likely to prove useful to specify a 'directory' record to specify the set of protocols that a handle supports.¶
While the DNS is the natural mechanism to use for resolution of DNS names, some DNS users lack the ability to edit DNS entries directly but do have the ability to place content on a Web service published at the domain. In this case, the HTTP .well-known mechanism MAY be used as a substitute for DNS records.¶
For example, the handle bsky.app would be resolved by an GET request to https://bsky.app/.well-known/atproto-did as described in the ATprotocol specifications.¶
One of the challenges in describing the use of the OAuth service as an authentication service is that it was originally presented as an 'authorization' service and the nomenclature applied in the documentation is confusing in the extreme.¶
The use case we consider here is one in which user Alice is attempting to authenticate to a Web site 'example.net' by means of her DNS handle which is bound to an account managed by her authentication service provider, example.com. In OAuth2 terminology, the Web site Alice is attempting to access is the OAuth 'client' and the authentication service provider is an 'authorization service'.¶
The ATprotocol is essentially a profile of OAuth2 with extensions currently under development plus the DNS handle resolution convention and PLC DID scheme.¶
In order to accept @nywhere authentication, the OAuth client generates an authentication key (and optionally an encryption key) and publishes this and other information as its client metadata at a URI which is also used as the client identifier.¶
To authenticate to the Web Site example.net, Alice provides her DNS handle 'alice.example.com'. The site then performs the first stage of the authentication process as follows as an OAuth2 client:¶
Resolves the DNS handle to a DID by means of either a DNS TXT record or a HTTPS .well-known entry.¶
Resolves the DID using the PLC protocol to obtain the list of protocols supported. This specifies an ATprotocol resource server.¶
Fetches the metadata for the resource server, this specifies the authorization service.¶
Fetches the metadata for the authorization service.¶
Generates a Proof Key for Code Exchange (PKCE) token¶
Submits a Pushed Authorization Request to the Authorization service containing the PKCE verifier¶
Receives back the HTTP redirect to return to the user.¶
Returns the HTTP redirect to the user.¶
At this point, the user is redirected to the authentication service and is asked to perform whatever additional steps are required for authentication.¶
In most cases, the user will have already authenticated to the Authorization service allowing this step to be skipped. This is important because while the currently common practice of each Web site requiring users to respond to a second factor authentication challenge is obnoxious and absurd, allowing users the option of protecting their accounts with a single challenge they are only required to respond to once in their day is much more likely to gain user acceptance.¶
After the user completes the OAuth2 interaction, they are redirected to the Web site from which the authentication request originated and the OAuth2 client completes the authentication process as follows:¶
Submits the 'Authorization Request' authenticated by the PKCE nonce to the authorization service to obtain an initial token¶
Performs a 'code' query against the Authorization server to obtain a set of access tokens bound to a specific account DID. The client MUST verify that this DID is the same as the DID for the account for which authentication was requested.¶
The user experience would be improved through definition of a microformat convention allowing the DNS handle to be filled automatically. This would ideally provide an unambiguous signal to the Web client that a DNS handle is being requested for use with the @nywhere protocol so that it can substitute the OAuth2 authentication dance involving a separate authorization server with a direct public key-based authentication.¶
For example, we might stipulate that a HTML form requesting the user enter their DNS handle have the 'dns-handle' autocomplete attribute:¶
<div>¶
<label for="anything">@</label>¶
<input type="text" id="anything" autocomplete="dns-handle" />¶
</div>¶
As previously mentioned, the ability to access multiple Web sites through a single account and a credential authenticated by a single authentication service makes use of multiple factor authentication much less burdensome.¶
Besides the advantage that the user is only required to authenticate once per day rather than for each site used, the second factor scheme does not need to be limited those available to the third party sites. In practice, this limits the second factor authentication to email and SMS challenge/response schemes which offer marginal security advantage at best.¶
An authentication service chosen by the user can make use of a second factor authentication selected by the user. For example, responding to a biometric challenge on a personal mobile device. In this case, we can achieve two factor authentication without requiring the user to enter a password at all, the factors being something carried (the mobile device) and a biometric. Should a passcode be required to unlock the mobile device, it would provide a third factor (something known).¶
The Mathematical Mesh protocols include the 'confirmation protocol', an advance on second factor authentication in which the user is told which action is being requested (e.g. enable @nywhere login for their browser) and asked to accept or reject the request.¶
In the ideal case, Web sites involving a high degree of risk such as access to a brokerage account would offer multiple levels of authentication with viewing account balances placing a minimal burden on the user and placing high value stock trades requiring individual confirmation using a trusted and trustworthy device.¶
@nywhere authentication allows users to claim a single identity across disparate Internet services under independent management. Alice can post comments to forums A, B and C under the same DNS handle allowing Bob to recognize these as all being made by Alice. The same OAuth2 infrastructure is sufficient to set up interactive group chats and meetings but not for the case of end-to-end secure, interactive, person to person.¶
The simplest means of supporting use of DNS handles for person-to-person communications is the DNS SRV record. For example, the following entries specify that Alice can be contacted through the personal messaging service 'Foo' delivered by the hosts foo1.example.net and foo2.example.net:¶
_foo._tcp.alice.example.com TXT "therealAlice@example.net"¶
_foo._tcp.alice.example.com SRV 1 1 foo1.example.net 5001¶
_foo._tcp.alice.example.com SRV 1 1 foo2.example.net 5001¶
Since these are SRV records, we can use the usual load balancing and fallback options supported by SRV.¶
While this approach is functional for a single service, it is less so if there are a large number of services. We can define a TXT record to report all the services supported, for example:¶
_nyone.alice.example.com TXT "foo=therealAlice@example.net"¶
Alternatively, a DNS record might be used to specify a location from which a contact assertion specifying a range of contact addresses can be retrieved.¶
As an example, the Mathematical Mesh is a personal PKI that manages public keys and credentials across all the devices a user binds to their personal Mesh. To interact with a Mesh user, a¶
A cryptographic digest of the list of the user's profile signature keys presented in base32.¶
The user's current Mesh service provider through which other users may request contact exchange and make message posting requests.¶
These identifiers are combined to form the user's Mesh Service Address, e.g. masn-nayb-iy7f-jcfz-rfwv-uit4-msez@example.com. This can be published in the same manner as before:¶
_nyone.alice.example.com TXT \¶
"mmm=masn-nayb-iy7f-jcfz-rfwv-uit4-msez@example.com"¶
Directing resolution to a Web Service allows the response to vary according to the party making the request. Alice may be willing to share her SMTP email address with Bob and Carol but not to Spamella.¶
A Mesh contact assertion contains a list of protocol/address pairs and optionally a set of public key credentials to be used for each. So Alice can create a contact assertion specifying her SMTP and XMPP addresses and the SSH, OpenPGP and S/MIME credentials used to secure interactions using those protocols. In addition, the Mesh defines its own messaging scheme designed to support all the traditional modes of Internet communication (short message, mail, file drop, voice, video) with end-to-end security and trust 'always on' rather than an optional feature.¶
As originally designed, the Mesh messaging infrastructure anticipated a communication pattern in which users would first establish a direct connection through one (or more) of the contact exchange modalities supported before allowing other forms of communication such as mail which present a higher risk of abuse.¶
The introduction of DNS handles and an identity shared across communications and social media allows safelists and blocklists compiled for use in social media to be applied to communications requests. Alice might opt to allow anyone she follows online or belongs to her high school reunion group to her send short messages and mails without her personal authorization. Similarly, Alice is probably not going to be interested in messages from people she has blocked in social media.¶
As it stands today, the Internet of Things has fallen far short of its original promise. While being able to connect to a device deployed in the home or office through an Internet enabled mobile is useful, the functionality typically achieved is limited to that of a remote control that will fail if the cloud service supporting it becomes unavailable for any reason.¶
For the Internet of Things to deliver real value, devices must do more than communicate with the user, they must communicate with each other and do so securely and directly without the introduction of artificial intermediaries and for this to be possible, the thing that is on the Internet name requires an Internet DNS name and the necessary WebPKI credentials to communicate directly rather than through a vendor controlled portal.¶
If Alice (@alice.example.com) buys an Internet connected doorbell, she should be able to reach it directly using a standard Web browser configuration through a domain subordinate to her DNS handle or registered DNS name.¶
To change the temperature on my thermostat from my Web browser, I am required to navigate to the vendors Web site, guess that the icon in the top left corner is my profile, select 'my home', perform an OpenID Connect login and interact with the devices supported by that particular vendor. In theory, my partner could also change the thermostat setting in the same way because I have added her to the account but she never does because it is easier to ask me, even in the case that I am in a meeting the other side of the planet.¶
While adding other family members to the account by specifying an email address with a link to a Web site with a six-hoop account verification process might appear perfectly reasonable to the designer, no member of my family other than myself has ever been sufficiently motivated to complete it. Thus a device that I bought to reduce effort for myself has substantially increased it.¶
Use of DNS handles provides an obvious advantage in authorizing additional users and temporary users by simply adding the user's DNS handles to the list of authorized users. If the property was a short term let, renters could be automatically authorized to control all the IoT devices for the duration of their stay and the authorization automatically cancel when they leave.¶
Three deployment modes are anticipated:¶
The @nything service runs in the local network only. This allows configuration of the network gateway (firewall/NAT) and provides continuity of service should the local network lose Internet connectivity but cannot host DNS services or provide reverse HTTP proxy functionality unless the network has a static IP address.¶
The @nything service runs in the cloud only. This allows hosting of DNS services and provision reverse HTTP proxy functionality but not configuration of the network gateway (firewall/NAT). If Internet connectivity is lost, devices already connected will continue to function until their credentials expire but it will not be possible to onboard new devices.¶
The @nything service is split between a local component and a cloud service. This provides all the advantages of local and cloud deployment.¶
The means by which user devices are registered to the user and provisioned with the necessary configuration data to perform their tasks is outside the scope of this document. While the Mathematical Mesh provides one approach to achieving this end, it is not necessary to fix on a single approach. For the purposes of @nything, all that is required to place a device under management is a means of provisioning it with:¶
In addition, the device will of course require some means of communicating with the @nything service during the onboarding process.¶
The @nything service receives credentialing and naming requests from devices and makes the relevant configurations as indicated by the device assertion.¶
Network Configuration¶
In the general case, IoT devices are deployed with only a network local address. If the device is to be accessed from the public Internet, either a reverse HTTP proxy or some form of NAT traversal will be required.¶
DNS Configuration¶
The A, AAAA, SRV and TXT records necessary to support host and service discovery are provisioned to local and public DNS as required. In addition, DNS records required to respond to an ACME DNS challenge are provisioned as required.¶
Device Credential Provisioning¶
If the device is to be public facing, it is provisioned with public credentials obtained from a WebPKI CA, (e.g. through ACME). Devices may also be provisioned with certificates under a private CA for purposes such as 802.11x where a long certificate lifetime is desirable.¶
Storage Configuration¶
IoT devices frequently require storage. This may be provided through a subscription service or another device belonging to the user.¶
A frequently voiced objection to the use of a single identity across multiple Web sites is that linking user activity across Web sites makes it easier for parties to link user activity across Web sites.¶
Since DNS Handles provide a mechanism for linking user activity across Internet properties, client applications MUST ensure that disclosure of the handle to a site is an overt act on behalf of the user and SHOULD provide mechanisms to allow the user to defeat unwanted linkage through creation of additional DNS Handles to separate identies.¶
For example, a browser offering a 'Private Browsing' mode SHOULD allow the user to specify which identity they are private browsing in, obtaining temporary DNS handles as required.¶
DNS Handle Providers could encourage users to invest in an identity established under a DNS name under their control and make unanticipated demands for continued use once the name has been established.¶
DNS names are effectively rented rather than owned and can be transferred to other parties without the permission of the name holder. This might occur as a result of a fraudulent name transfer, losing a challenge brought under the UDRP or simply forgetting to renew the subscription.¶
Use of DNS handles potentially represents a concentration of risk in a single identifier should the user lose the use of it.¶
A social media site could falsely claim that a post was made under a handle that it did not verify so as to allow a defamation action to be brought against the party being impersonated.¶
An attacker might make a malicious device onboarding attempt designed to trick the user into onboarding a device that does not belong to the user.¶
The onboarding processes supported should ensure that the user is required to provide affirmative confirmation that a specific request is approved. For example requiring a user to enter a security code printed next to a QR code to approve onboarding and not simply scanning the device alone.¶
This document does not specify any actions for IANA.¶
The work presented in this document builds on work by the DNS, OAuth and other IETF Working Groups over a period of decades.¶