DNS Account Handles, A Whitepaper
draft-hallambaker-any-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Phillip Hallam-Baker | ||
| Last updated | 2025-01-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hallambaker-any-00
Network Working Group P. M. Hallam-Baker
Internet-Draft ThresholdSecrets.com
Intended status: Informational 22 January 2025
Expires: 26 July 2025
DNS Account Handles, A Whitepaper
draft-hallambaker-any-00
Abstract
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.
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 26 July 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hallam-Baker Expires 26 July 2025 [Page 1]
Internet-Draft DNS Account Handles January 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Handle Types . . . . . . . . . . . . . . . . . . . . . . 4
1.2. DNS Handle Provider . . . . . . . . . . . . . . . . . . . 5
1.3. @nywhere Sign In . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Authorization Policy . . . . . . . . . . . . . . . . 6
1.3.2. Subscription Services . . . . . . . . . . . . . . . . 6
1.3.3. Privacy protection . . . . . . . . . . . . . . . . . 7
1.4. @nyone Communications . . . . . . . . . . . . . . . . . . 7
1.4.1. Authorization Policy . . . . . . . . . . . . . . . . 7
1.4.2. End-to-End Trust . . . . . . . . . . . . . . . . . . 7
1.5. @nything Device Configuration . . . . . . . . . . . . . . 8
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 9
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Related Specifications . . . . . . . . . . . . . . . . . 9
2.3.1. @nywhere . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. @nything . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. @nyone . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 11
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Handle Resolution . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Personal Contact Assertion . . . . . . . . . . . . . 12
3.1.2. DNS TXT, SRV . . . . . . . . . . . . . . . . . . . . 13
3.1.3. HTTP Well-Known . . . . . . . . . . . . . . . . . . . 14
4. @nywhere Application Authentication . . . . . . . . . . . . . 14
5. Usability Improvements . . . . . . . . . . . . . . . . . . . 15
6. Second Factor and Public Key Authentication . . . . . . . . . 16
7. @nyone Personal Communications . . . . . . . . . . . . . . . 17
7.1. Mathematical Mesh Account Binding . . . . . . . . . . . . 17
8. @nything Device Configuration . . . . . . . . . . . . . . . . 18
8.1. Requirement: Enabling Multiple Users . . . . . . . . . . 19
8.2. Deployment Modes . . . . . . . . . . . . . . . . . . . . 19
8.3. Onboarding / Offboarding Protocol . . . . . . . . . . . . 20
8.4. Configured Services . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Privacy Considerations . . . . . . . . . . . . . . . . . 21
9.2. Switching Costs . . . . . . . . . . . . . . . . . . . . . 21
9.3. Loss of DNS name . . . . . . . . . . . . . . . . . . . . 22
9.4. Concentration of Risk . . . . . . . . . . . . . . . . . . 22
9.5. Impersonation . . . . . . . . . . . . . . . . . . . . . . 22
Hallam-Baker Expires 26 July 2025 [Page 2]
Internet-Draft DNS Account Handles January 2025
9.6. Device Onboarding . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. Normative References . . . . . . . . . . . . . . . . . . . . 22
13. Informative References . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
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.
Hallam-Baker Expires 26 July 2025 [Page 3]
Internet-Draft DNS Account Handles January 2025
1.1. Handle Types
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.
Hallam-Baker Expires 26 July 2025 [Page 4]
Internet-Draft DNS Account Handles January 2025
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.
1.2. DNS Handle Provider
The infrastructure described in this document anticipates the
provision of a suite of Internet service to permit use of the handle
in different contexts:
DNS Authoritative Service To publish records corresponding to the
handle under management.
OAUTH2 Authentication Service To manage authentication requests
under the handle.
Device Provisioning Service To relay provisioning requests for
network names and credentials to the relevant DNS and CA services.
Contact Catalog Manager To manage the user's contact catalog and
synchronize it across their devices.
Presence Service 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:
Personal Registration The DNS name is registered by the user of the
handle.
At-will Registration 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.
Hallam-Baker Expires 26 July 2025 [Page 5]
Internet-Draft DNS Account Handles January 2025
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.
1.3. @nywhere Sign In
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.
1.3.1. Authorization Policy
A common identification infrastructure facilitates specification of
authorization policy. If Alice has blocked Mallet from reading her
posts on a microblogging site, it is likely she would want to block
Mallet from commenting on her personal blog as well and she is almost
certainly not going to be willing to accept emails or other messaging
communications from him.
1.3.2. Subscription Services
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.
Hallam-Baker Expires 26 July 2025 [Page 6]
Internet-Draft DNS Account Handles January 2025
1.3.3. Privacy protection
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.
1.4. @nyone Communications
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.
1.4.1. Authorization Policy
Abuse has become a severe problem in both email and telephone
communications. A common identity allows users to adopt a 'default
deny' approach to accepting inbound communications from unknown
users, with optional exceptions for specific modes (e.g. contact
request) and for those on chosen shared lists.
For example, Alice might choose to only allow voice or video
communication requests from people she has exchanged contact
information but allow anyone who is on a list of family members, her
golf club or her business club to send her email messages.
1.4.2. End-to-End Trust
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.
Hallam-Baker Expires 26 July 2025 [Page 7]
Internet-Draft DNS Account Handles January 2025
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.
1.5. @nything Device Configuration
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.
2. Definitions
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.
Hallam-Baker Expires 26 July 2025 [Page 8]
Internet-Draft DNS Account Handles January 2025
2.1. Requirements Language
This is an informational document and does not contain any normative
language.
2.2. Defined Terms
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
2.3. Related Specifications
DNS handles represent a 'glue' technology that mostly serve to
connect existing technologies and infrastructures. According, the
number of related specifications is unusually large.
Hallam-Baker Expires 26 July 2025 [Page 9]
Internet-Draft DNS Account Handles January 2025
2.3.1. @nywhere
The following documents are relevant to the use of DNS handles to
provide a ubiquitous login infrastructure:
The OAuth 2.1 Authorization Framework [draft-ietf-oauth-v2-1] Descri
bes the OAuth authentication framework.
Proof Key for Code Exchange [RFC7636] Describes the PKCE extension
used to authenticate OAUTH requests.
OAuth Client ID Metadata Document
[draft-parecki-oauth-client-id-metadata-document] A JSON document
describing an OAUTH 'client'.
OAuth 2.0 Protected Resource Metadata
[draft-ietf-oauth-resource-metadata] A JSON document describing an
OAUTH resource.
Decentralized Identifiers (DIDs) v1.0 [did] Describes the
reservation of a subdivision of the URI space for user
identifiers.
DID PLC Method [plc] Describes the PLC identifier formed as the
digest of a public signature key used to authenticated ATprotocol
interactions.
Anywhere Sign-In [draft-hallambaker-anywhere] Describes the profile
of the above documents used to implement @nywhere sign in and
proposed extensions and improvements.
2.3.2. @nything
The following documents are relevant to the provisioning of network
names and credentials:
Automatic Certificate Management Environment (ACME) [RFC8555] The
issue of TLS certificates to devices
Dynamic Updates in the Domain Name System [RFC2136] Publication of
DNS records to local and public DNS.
Mathematical Mesh 3.0 Part IV. Schema Reference
[draft-hallambaker-mesh-schema].
The assertion format used to describe Mesh devices.
Anything Service [draft-hallambaker-anything] Describes a service
Hallam-Baker Expires 26 July 2025 [Page 10]
Internet-Draft DNS Account Handles January 2025
that receives device requests for provisioning of network names
and credentials and performs the necessary actions to satisfy
authorized requests.
2.3.3. @nyone
The following documents describe one approach top use of DNS handles
for person-to-person and person-to-group communication:
Mathematical Mesh 3.0 Part I: Architecture Guide
[draft-hallambaker-mesh-architecture]. Provides an overview of the
Mesh as a system and the relationship between its constituent
parts.
Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint
[draft-hallambaker-mesh-udf]. Describes the UDF format used to
express fingerprints of public keys and other data.
Mathematical Mesh 3.0 Part V: Protocol Reference
[draft-hallambaker-mesh-protocol]. Describes the protocol used to
maintain Mesh accounts and in particular, the contact catalog.
Mathematical Mesh 3.0 Part XI: Mesh Presence Service
[draft-hallambaker-mesh-presence]. Describes the protocol used to
establish device-to-device communication for synchronous
communication.
2.4. Implementation Status
Reference code under the MIT Open Source license has been developed
to demonstrate all the features described in this document.
3. Architecture
To access an Internet service using a DNS handle or a personal name,
an application requires three pieces of information:
* The DNS prefix for the service protocol (e.g. _http._tcp).
* The DNS name of the service.
* The Direct Trust Fingerprint of the user account.
The DNS name of the service and Direct Trust Fingerprint are obtained
from a DNS handle or personal name through the Handle resolution
process.
Hallam-Baker Expires 26 July 2025 [Page 11]
Internet-Draft DNS Account Handles January 2025
3.1. Handle Resolution
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
3.1.1. Personal Contact Assertion
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.
Hallam-Baker Expires 26 July 2025 [Page 12]
Internet-Draft DNS Account Handles January 2025
3.1.2. DNS TXT, SRV
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.
Hallam-Baker Expires 26 July 2025 [Page 13]
Internet-Draft DNS Account Handles January 2025
3.1.3. HTTP Well-Known
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.
4. @nywhere Application Authentication
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.
Hallam-Baker Expires 26 July 2025 [Page 14]
Internet-Draft DNS Account Handles January 2025
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.
5. Usability Improvements
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:
Hallam-Baker Expires 26 July 2025 [Page 15]
Internet-Draft DNS Account Handles January 2025
<div>
<label for="anything">@</label>
<input type="text" id="anything" autocomplete="dns-handle" />
</div>
6. Second Factor and Public Key Authentication
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.
Hallam-Baker Expires 26 July 2025 [Page 16]
Internet-Draft DNS Account Handles January 2025
7. @nyone Personal Communications
@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.
7.1. Mathematical Mesh Account Binding
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
The User's Profile fingerprint (e.g. masn-nayb-iy7f-jcfz-rfwv-
uit4-msez) A cryptographic digest of the list of the user's profile
signature keys presented in base32.
The User's current service address (e.g. example.com) The user's
current Mesh service provider through which other users may
request contact exchange and make message posting requests.
Hallam-Baker Expires 26 July 2025 [Page 17]
Internet-Draft DNS Account Handles January 2025
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.
8. @nything Device Configuration
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.
Hallam-Baker Expires 26 July 2025 [Page 18]
Internet-Draft DNS Account Handles January 2025
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.
8.1. Requirement: Enabling Multiple Users
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.
8.2. Deployment Modes
Three deployment modes are anticipated:
Local only 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.
Hallam-Baker Expires 26 July 2025 [Page 19]
Internet-Draft DNS Account Handles January 2025
Cloud only 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.
Hybrid The @nything service is split between a local component and a
cloud service. This provides all the advantages of local and
cloud deployment.
8.3. Onboarding / Offboarding Protocol
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:
* A name for the device from which its public DNS name is to be
formed by applying a suffix.
* A public/private keypair unique to the device
* The IP Addresses to be used for local/public access
* An assertion verifiable by the @nything service stating the above.
In addition, the device will of course require some means of
communicating with the @nything service during the onboarding
process.
8.4. Configured Services
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
Hallam-Baker Expires 26 July 2025 [Page 20]
Internet-Draft DNS Account Handles January 2025
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.
9. Security Considerations
9.1. Privacy Considerations
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.
9.2. Switching Costs
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.
Hallam-Baker Expires 26 July 2025 [Page 21]
Internet-Draft DNS Account Handles January 2025
9.3. Loss of DNS name
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.
9.4. Concentration of Risk
Use of DNS handles potentially represents a concentration of risk in
a single identifier should the user lose the use of it.
9.5. Impersonation
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.
9.6. Device Onboarding
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.
10. IANA Considerations
This document does not specify any actions for IANA.
11. Acknowledgements
The work presented in this document builds on work by the DNS, OAuth
and other IETF Working Groups over a period of decades.
12. Normative References
[did] "[Reference Not Found!]".
[draft-hallambaker-anything]
"[Reference Not Found!]".
Hallam-Baker Expires 26 July 2025 [Page 22]
Internet-Draft DNS Account Handles January 2025
[draft-hallambaker-anywhere]
"[Reference Not Found!]".
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
Architecture Guide", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-architecture-23, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-architecture-23>.
[draft-hallambaker-mesh-presence]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part XI: Mesh
Presence Service", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-presence-03, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-presence-03>.
[draft-hallambaker-mesh-protocol]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol
Reference", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-protocol-16, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-protocol-16>.
[draft-hallambaker-mesh-schema]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema
Reference", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-schema-13, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-schema-13>.
[draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform
Data Fingerprint.", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-udf-19, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-hallambaker-
mesh-udf-19>.
[draft-ietf-oauth-resource-metadata]
Jones, M. B., Hunt, P., and A. Parecki, "OAuth 2.0
Protected Resource Metadata", Work in Progress, Internet-
Draft, draft-ietf-oauth-resource-metadata-13, 15 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
oauth-resource-metadata-13>.
[draft-ietf-oauth-v2-1]
Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", Work in Progress, Internet-
Hallam-Baker Expires 26 July 2025 [Page 23]
Internet-Draft DNS Account Handles January 2025
Draft, draft-ietf-oauth-v2-1-12, 15 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
v2-1-12>.
[draft-parecki-oauth-client-id-metadata-document]
Parecki, A. and E. Smith, "OAuth Client ID Metadata
Document", Work in Progress, Internet-Draft, draft-
parecki-oauth-client-id-metadata-document-02, 9 January
2025, <https://datatracker.ietf.org/doc/html/draft-
parecki-oauth-client-id-metadata-document-02>.
[plc] "[Reference Not Found!]".
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/rfc/rfc2136>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[RFC7636] Sakimura, N., Bradley, J., and N. Agarwal, "Proof Key for
Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/rfc/rfc7636>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>.
[RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications
That Use Underscored Node Names", BCP 222, RFC 8553,
DOI 10.17487/RFC8553, March 2019,
<https://www.rfc-editor.org/rfc/rfc8553>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
13. Informative References
[atproto] "[Reference Not Found!]".
Author's Address
Hallam-Baker Expires 26 July 2025 [Page 24]
Internet-Draft DNS Account Handles January 2025
Phillip Hallam-Baker
ThresholdSecrets.com
Email: phill@hallambaker.com
Hallam-Baker Expires 26 July 2025 [Page 25]