Acts-For: Signing In to a Website with a ~handle, for a Person or an Agent Acting for One
draft-morrison-acts-for-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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Blake Morrison | ||
| Last updated | 2026-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-morrison-acts-for-00
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational 21 October 2026
Expires: 24 April 2027
Acts-For: Signing In to a Website with a ~handle, for a Person or an
Agent Acting for One
draft-morrison-acts-for-00
Abstract
Acts-For lets a person sign in to any website with the ~handle they
already hold, and lets an AI agent sign in or register at that
website on the person's behalf. Neither needs a username, a password
or an account per site. A website joins by publishing one DNS
record. A person signs in through a standard OpenID Connect
authorization code flow and the site receives a short-lived token
naming the person by a number unique to that site. An agent obtains
a short-lived pass from the issuer over the Model Context Protocol
and presents it to the site. The pass names the same per-site
number, the agent's own key and ~handle, and the limits the person
set. The site checks it against a published key and calls nobody.
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 24 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Morrison Expires 24 April 2027 [Page 1]
Internet-Draft Acts-For October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Site Record . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Location and Format . . . . . . . . . . . . . . . . . . . 5
4.2. The Site Handle . . . . . . . . . . . . . . . . . . . . . 5
4.3. Verification . . . . . . . . . . . . . . . . . . . . . . 6
4.4. What Verification Produces . . . . . . . . . . . . . . . 7
5. Person Sign-In . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. On the Page . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. The Flow . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. The Per-Site Subject . . . . . . . . . . . . . . . . . . 9
6. Agent Sign-In . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Asking for a Pass . . . . . . . . . . . . . . . . . . . . 9
6.2. The Acts-For Pass . . . . . . . . . . . . . . . . . . . . 9
6.3. Presenting and Checking the Pass . . . . . . . . . . . . 10
7. Returning and Recovery . . . . . . . . . . . . . . . . . . . 11
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 13
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Normative References . . . . . . . . . . . . . . . . . . . . 15
15. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Document History . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Most websites ask a person to register with a username, a password
and an email address to confirm. Single sign-on from a large
provider removes the password but ties the person to that provider
and gives every site the same identifier for them. An agent that has
to place an order or book a table for a person either holds the
person's password, which it should never be given, or stops and hands
the task back.
Morrison Expires 24 April 2027 [Page 2]
Internet-Draft Acts-For October 2026
Under Acts-For the person signs in with a ~handle they already hold
([MCPDNS], Section 2). A website that wants to accept it publishes
one DNS record. That record proves the site controls its domain and
registers the site as a client in the same step. From then on:
* a person clicks "Sign in with ~alter" and confirms with a passkey.
The site learns a number that identifies the person to that site
only. It learns the person's ~handle or email only if the person
shares them;
* an agent the person has authorised asks for a pass for that site
over MCP and presents it. The pass names the person by the same
per-site number and the agent by its own key. The site then knows
who the person is to it and which agent is acting.
Out of scope are how a person obtains a ~handle, how the person
grants authority to an agent (only the grant's effect on the pass is
specified here), payment, and anything the site does after sign-in.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~handle: An identifier as defined in [MCPDNS], Section 2, with the
grammar of handle-name in [ALTERURI], Section 3.3, and the tiers
of [IDCOMMITS], Section 3. The tier is read from the lexical form
alone: a trailing .bot is the Bot tier, a leading cc- is the
Instrument tier, and anything else is the Sovereign tier. Where
this document names a ~handle as a reference it is written as an
alter: URI [ALTERURI], as [MCPDNS] does.
Person: A human who holds a Sovereign-tier ~handle.
Agent: Software acting for a Person under scoped delegation, holding
its own signing key and its own Bot-tier ~handle ([IDCOMMITS],
Section 3). An Instrument-tier ~handle is never an Agent under
this document, because it has no envelope of its own and is not an
independent principal ([ALTERURI], Section 3.4).
Site: A website that accepts sign-in under this document. Its
operator is the Site owner.
Site handle: The Sovereign-tier ~handle a Site receives when its
record verifies (Section 4.4).
Morrison Expires 24 April 2027 [Page 3]
Internet-Draft Acts-For October 2026
Issuer: The service that authenticates the Person, issues tokens and
passes, and publishes the keys that verify them. In the
deployment described in Section 8 this is ~alter.
Site record: The DNS TXT record of Section 4.
Per-site subject: The identifier the Issuer gives a Person for one
Site (Section 5.3).
Acts-for pass: The token an Agent presents to a Site (Section 6.2).
Floor key: The Issuer's Ed25519 key that signs acts-for passes,
published at the Issuer's /.well-known/alter-keys.json
(Section 6.2).
Collective: A Site handle held by more than one Person
(Section 4.4).
3. Overview
Site owner DNS Issuer Person / Agent
| | | |
| 1. publish _alter record | |
|--------------->| | |
| 2. verify | | |
|---------------------------------->| |
| | 3. read record | |
| |<-----------------| |
| 4. Site registered as a client | |
|<----------------------------------| |
| | |
| Person: 5. click, passkey, consent (OIDC + PKCE) |
|<------------------------------------------------------->|
| 6. ID token, sub = per-site subject |
| |
| Agent: 7. ask for an acts-for pass over MCP |
| |<--------------------|
| 8. present pass, signed by the Agent's key |
|<--------------------------------------------------------|
| 9. verify pass against the Issuer's published key |
Figure 1: Acts-For in one picture
Steps 1 to 4 happen once per Site. Steps 5 and 6 are the person
signing in. Steps 7 to 9 are an agent signing in for the person.
4. The Site Record
Morrison Expires 24 April 2027 [Page 4]
Internet-Draft Acts-For October 2026
4.1. Location and Format
A Site joins by publishing one TXT record at the label _alter
prepended to its domain [RFC8552], as the envelope record of
[MCPDNS]:
_alter.riverbakery.example. IN TXT
"v=alter1; h=~riverbakery.example; pk=ed25519:<key>; ilr=<digest>;
ts=<unix-seconds>; rev=<digest>; sig=<signature>; code=<code>"
The fields v, h, pk, ilr, ts, rev and sig are the envelope of
[MCPDNS], Section 7, signed over the input of [MCPDNS], Section 7.4,
with these values:
* h is the Site handle (Section 4.2), with its leading tilde as
[MCPDNS], Section 7.3.2 requires;
* pk is an Ed25519 public key [RFC8032] generated on the Site
owner's device. The private key MUST NOT leave that device;
* ilr is, as built, the base64url [RFC4648] SHA-256 of the JSON
canonical form [RFC8785] of the object with members h, domain and
ts;
* rev is the SHA-256 of a revocation pre-image held by the Site
owner.
The record also carries one field [MCPDNS] does not define, code, a
one-time code the Issuer hands the Site owner when the claim starts.
code sits outside the signed input. The same signed envelope can be
published again with a new code and no new signature. A resolver
that implements [MCPDNS] alone ignores it ([MCPDNS], Section 7.5).
ilr and code do not conform to [MCPDNS]. Its Section 7.3.4 defines
ilr as the digest of an IdentityLog root, and its Section 7.5 forbids
repurposing a required field and admits a new field only with a new
envelope version. Here ilr is a binding digest and code is a new
field under v=alter1. See Section 13, item 3.
4.2. The Site Handle
The Site handle is ~ followed by the Site's domain, in lowercase, in
its A-label form [RFC5890], with no trailing dot. The domain the
record proves is its zone, and the Site handle's dispatchable
reference carries that zone as its org-scope:
alter:~riverbakery.example@riverbakery.example
Morrison Expires 24 April 2027 [Page 5]
Internet-Draft Acts-For October 2026
The spelling of a Site handle never establishes its zone. A party
that reads ~riverbakery.example MUST NOT resolve it against the
riverbakery.example zone on the strength of its characters
([ALTERURI], Section 6.9; [MCPDNS], Section 12.3). Only the verified
record, or a reference that carries the zone, does.
A domain whose Site handle would not be a Sovereign-tier handle-name
MUST NOT be enrolled. That excludes:
* a domain whose first label begins with a digit, since handle-name
does not admit it;
* a domain whose first label begins with cc-, since its Site handle
reads as an Instrument-tier handle;
* a domain under the bot top-level domain, since its Site handle
reads as a Bot-tier handle.
See Section 13, item 11.
4.3. Verification
The Issuer verifies a Site record when the Site owner asks it to, and
MUST check all of the following:
1. the record parses as an envelope with every required field;
2. sig verifies under pk over the envelope's canonical signing
input;
3. h equals the ~handle being claimed;
4. ts is within seven days of the start of the claim, with five
minutes allowed for clock skew;
5. ilr equals the value computed from h, the domain and ts;
6. the digest of code equals the digest the Issuer stored when the
claim started. The Issuer stores only the digest.
Morrison Expires 24 April 2027 [Page 6]
Internet-Draft Acts-For October 2026
The first record to verify wins and clears every other pending claim
on that domain. DNSSEC validation is reported but not required.
This conflicts with [MCPDNS], Section 8. That section requires a
signed zone for every record at this label, and requires an
onboarding wizard or recognition verifier to treat a record read over
an unvalidated path as unauthenticated TXT. A Site handle from an
unsigned zone also fails step 2 of [MCPDNS], Section 12.3 and step 3
of [ALTERURI], Section 3.4. The Issuer accepted it and no third
party can verify it. See Section 13, item 1.
A Site record already published under the same pk MAY be accepted in
place of a new one, without a new code, when the claimant proves
possession of the matching private key. This lets a Site owner who
has set up once, on the same device, add a second domain or return
without editing DNS again.
4.4. What Verification Produces
A verified Site record produces, in one step:
* the Site handle (Section 4.2), owned by the Site owner's own
~handle as a sole-owned entity. An owner who does not already
hold a ~handle claims one in the same flow, and the Site is paired
to a person from the start. When a second person joins, the Site
handle becomes a collective and is held under the collective's own
rules. Members of a collective need not all hold the same
permissions. Only the owner can change the Site's client;
* an OAuth 2.0 client [RFC6749] for the Site. The client is public
(token_endpoint_auth_method is none), its scopes are openid and
profile, and its single redirect URI is one exact https address on
the proven domain or its www. name, with no wildcard, port, user
information or fragment.
The Site needs no separate client registration [RFC7591].
A Person who signs in to a Site, or for whom an Agent signs in, is
the Site's counterparty. Sign-in never makes a Person a member of
the Site handle.
5. Person Sign-In
5.1. On the Page
The Site embeds a button and a script:
Morrison Expires 24 April 2027 [Page 7]
Internet-Draft Acts-For October 2026
<div data-alter-sign-in></div>
<script src="https://issuer.example/sign-in/v1.js"
integrity="sha384-<hash>" crossorigin="anonymous"
data-client-id="<client_id>"
data-return-page="https://riverbakery.example/callback"
data-issuer="https://issuer.example"
data-authorize="https://issuer.example/authorize"></script>
The script is pinned by its integrity hash. A changed script is
published at a new path.
5.2. The Flow
The flow is the OpenID Connect authorization code flow [OIDC] with
PKCE [RFC7636], method S256, a one-time state and a nonce. The
Person confirms with a passkey at the Issuer, and the Issuer MUST
require user verification [WEBAUTHN]. That one gesture is two
factors, the device held and the fingerprint, face or PIN that
unlocks it. The Issuer MUST ask for it on every sign-in to a Site,
including when the Person already has a session at the Issuer. At
the consent step the Person MAY switch on sharing their ~handle,
their email, or both. These travel as the scopes handle and email,
and only the consent step can add them. email is the scope of [OIDC],
Section 5.4. Neither scope carries an alter: prefix, because a scope
token with one would read as an alter: URI [ALTERURI], and a scope is
not one.
The Site receives:
* an ID token, signed RS256 [RFC7518] by the Issuer, with iss the
Issuer, aud the client identifier, a lifetime of one hour, sub the
per-site subject (Section 5.3), verified set to yes, the same band
the acts-for pass carries (Section 6.2), and handle and email only
where the Person switched them on. email and email_verified are
the claims of [OIDC], Section 5.1. handle carries the Person's
~handle in the bare form of [MCPDNS], Section 7.3.2. auth_time is
the time of the passkey confirmation for this sign-in, never the
time the token was minted, and amr [RFC8176] lists the methods
that confirmation used;
* an opaque access token, valid for 600 seconds, accepted only at
the userinfo endpoint. No refresh token is issued.
The Site MUST verify the ID token's signature against the Issuer's
published JSON Web Key Set [RFC7517] before acting on it. Checking
iss, aud, exp and nonce in the browser is not enough.
Morrison Expires 24 April 2027 [Page 8]
Internet-Draft Acts-For October 2026
5.3. The Per-Site Subject
The per-site subject is a pairwise identifier in the sense of [OIDC],
Section 8.1. It is the lowercase base32 [RFC4648] encoding of the
first 20 bytes of an HMAC-SHA256 [RFC2104], keyed by an Issuer
secret, over a fixed label, the Person's internal identifier and the
Site's domain, each prefixed by its length as a four-byte big-endian
integer.
The domain is normalised once before use, and the same normalised
form is the pass's aud. It is lowercased, one trailing dot is
removed, it is taken in its A-label form [RFC5890], and then one
leading www. is removed. The fold is applied exactly once, because
it is not idempotent: www.www.example names the Site www.example.
The per-site subject never begins with ~ and can never be read as a
~handle.
A Person has the same subject at a Site whether they sign in
themselves or an Agent signs in for them. At different Sites they
have different subjects, and two Sites cannot join their records by
subject.
6. Agent Sign-In
6.1. Asking for a Pass
An Agent that holds a grant from its Person calls the MCP [MCP] tool
alter_sign_in at the Issuer, naming the Site's domain. The Issuer
checks that the grant exists, is in force and covers that Site, then
returns an acts-for pass. The Issuer MUST refuse an Agent whose
~handle is not Bot-tier.
alter_sign_in is a tool surface name in the sense of [TOOLNAMES]; see
Section 11.
6.2. The Acts-For Pass
The pass is a CBOR Web Token [RFC8392] in a COSE_Sign1 structure
[RFC9052], algorithm EdDSA [RFC8032], signed by the Issuer's floor
key. It carries the registered claims iss (1), sub (2), aud (3), exp
(4), iat (6) and cti (7), and nbf (5) where present, and the
following claims under Private Use keys, below -65536 as [RFC8392],
Section 9.1 allows:
profile (-65537): the text alter-site-pass-v0. A verifier MUST
refuse a pass whose profile it does not know.
Morrison Expires 24 April 2027 [Page 9]
Internet-Draft Acts-For October 2026
grant (-65538): the 32-byte content address of the grant the pass
was issued under.
bands (-65539): a map of band name to text label. A site pass
carries {"verified": "yes"}. No number is ever a band value.
acting (-65540): a map naming the Agent: kid (its key), handle (its
Bot-tier ~handle, in the bare form of [MCPDNS], Section 7.3.2),
may_tools (an array of tool surface names), valid_until (Unix
seconds), and optionally max_value (a map of amount, a decimal
string, and currency, a code).
cnf_jkt (-65541): the JWK thumbprint [RFC7638] of the Agent's
signing key.
The claims have these values:
* iss is the text alter;
* sub is the per-site subject of the Person at this Site, and is
never a ~handle;
* aud is the Site's domain, normalised as in Section 5.3;
* exp is at most 300 seconds after iat, never later than
acting.valid_until, and never more than 3600 seconds after iat.
acting and cnf_jkt MUST appear together. A pass presented without
both MUST be refused. The pass MUST NOT carry the Person's ~handle
or email; those reach a Site only through the ID token of Section 5.
Private Use keys are not interoperable between issuers. Whether
these claims should be registered, and whether cnf_jkt should instead
be the cnf claim of [RFC8747] carrying a COSE Key thumbprint
[RFC9679], is Section 13, item 2.
6.3. Presenting and Checking the Pass
The Agent presents the pass to the Site with a request signed by its
own key. This document does not yet say how the pass travels or how
the request is signed (see Section 13, item 12). The Site MUST:
1. verify the pass under the Issuer's Ed25519 floor key, published
at the Issuer's /.well-known/alter-keys.json [RFC8615];
2. check profile, check that aud is its own domain normalised as in
Section 5.3, and check that exp has not passed;
Morrison Expires 24 April 2027 [Page 10]
Internet-Draft Acts-For October 2026
3. verify the request signature under the Agent key whose thumbprint
is cnf_jkt, and check that the key's identifier equals
acting.kid. A pass presented without that signature MUST be
refused, since the pass alone is a bearer token;
4. hold the Agent to may_tools and max_value.
The Site then treats sub as it would after a Person sign-in. A
subject it has seen before is a returning Person. A new one is a
Person the Agent has just registered.
No token exchange [RFC8693] happens at sign-in. The Site does not
call the Issuer.
7. Returning and Recovery
A Site owner who loses the device holding the Site key proves the
domain again by publishing a new record. Proving a domain again
signs its owner straight back in only where the business account has
no confirmed email; otherwise the way back is a link sent to that
email. Proving a domain never signs anyone in to an account holding
a personal ~handle, because proving a domain proves the business and
not the person.
A Site handle whose owner leaves without handing it over becomes
dormant. Proving its domain again revives it only after a wait in
which the former owner, or any member, can object. Revival is never
immediate, because control of a domain's DNS does not show who ran
the Site.
8. Implementation Status
Note to the RFC Editor: please remove this section before
publication, per [RFC7942].
~alter has implemented most of this document in a test deployment.
As of 19 October 2026:
* A small business site, on its own domain at a public host,
published its Site record, was verified, and minted its client.
* A Person signed in to that site with a passkey through the
embedded button; consent, code issue and token exchange each
succeeded.
Morrison Expires 24 April 2027 [Page 11]
Internet-Draft Acts-For October 2026
9. Security Considerations
Domain control is the only thing the Site record proves. Whoever
controls a domain's DNS can enrol it, including a former agency, a
new registrant of a lapsed domain, or an attacker holding the DNS
host login. A published record counts for as long as it stays
published, with no time limit, while the device that made it still
holds its key. A seller who never finished setup and still holds
that key can therefore claim a domain whose buyer leaves the old
record in place. This is accepted. A record left up is still being
published by whoever controls the zone, and any age bound would
refuse every older record. A domain that was deleted and registered
again is a different case. [MCPDNS], Section 13.1.2 already gives
the signal for it, a changed registry creation date. See Section 13,
item 5.
The Site handle spelled like a domain is a Handle-Domain Confusion
surface ([ALTERURI], Section 6.9). A surface that shows a Site
handle to a person MUST keep its leading tilde.
A session at the Issuer is never enough to sign a Person in to a
Site. A browser left signed in at the Issuer, on a shared or stolen
machine, would otherwise let whoever holds it sign in as the Person
at every Site. Each sign-in therefore asks for a fresh user-verified
passkey (Section 5), and auth_time reports when that happened. A
Site that sends max_age or prompt=login [OIDC] is always met, because
every sign-in is already fresh. A Site can read amr to see how the
Person confirmed.
A Site should act only on the ID token and only after checking its
signature. The browser script does not check the signature and is
not a substitute.
The acts-for pass is short-lived and bound to one audience. It is
useless without a request signed by the Agent key it names. A Site
that skips the signature check turns the pass into a bearer token
valid for up to five minutes.
The one-time code is stored only as a digest. A claimant can satisfy
only their own pending code and cannot replace another claimant's.
10. Privacy Considerations
The per-site subject stops Sites joining their records by identifier.
The Person's ~handle and email reach a Site only when the Person
switches them on, and never through an acts-for pass. The Issuer
sees every sign-in it issues for, and this protocol gives a Person no
way to keep a sign-in from it.
Morrison Expires 24 April 2027 [Page 12]
Internet-Draft Acts-For October 2026
The per-site subject does not stop Sites joining their records by the
Agent. acting.kid, acting.handle and cnf_jkt are the same at every
Site the same Agent signs in to. Two Sites that compare them learn
that their two per-site subjects are one Person. See Section 13,
item 10.
The Issuer holds the key the per-site subject is computed from and
can compute any Person's subject at any Site.
11. IANA Considerations
This revision makes no IANA request. The _alter label is requested
in [MCPDNS]. A revision meant for publication would need to request:
* the well-known URI suffix alter-keys.json [RFC8615];
* the CWT claims of Section 6.2, unless they stay under Private Use
keys;
* the ID token claim handle;
* the tool surface name alter_sign_in [TOOLNAMES].
12. Related Work
Each part of Acts-For has been published elsewhere. None of the
documents below takes one DNS record carrying the Site owner's own
key and turns it into the domain proof, a public ~handle for the
business and the relying-party registration at once, or serves people
and agents through one per-site subject.
* AAuth [AAUTH] already makes the first call to a resource its
registration, gives a pairwise subject per resource, and treats
registration and login as one flow. Resources identify themselves
by HTTPS metadata, with no DNS and no direct human sign-in.
* auth.md [AUTHMD] publishes a file at the domain root telling
agents how to register, including a path where a trusted platform
vouches for the user. It matches users by issuer, subject and
email with no pairwise subject, and it covers agents only.
* OpenID Connect pairwise subjects [OIDC] are the per-site subject's
mechanism. Dynamic registration [RFC7591] and client ID metadata
documents [CIMD] remove per-provider registration over HTTPS;
neither uses DNS or a key made by the site owner.
Morrison Expires 24 April 2027 [Page 13]
Internet-Draft Acts-For October 2026
* Web Bot Auth [WBA] puts a bot operator's keys in a directory at a
well-known URL. The keys are the operator's and there is no sign-
in for a person.
* Token exchange [RFC8693] already names the agent in act with the
person in sub; see Section 13, item 2.
* AT Protocol handles [ATPROTO] make a domain a handle with one
_atproto TXT record, holding only an identifier, and are not used
to sign in elsewhere. DNS domain verification guidance
[DOMVERIFY] recommends a separate, removable challenge label with
the token first. The Site record does not follow it; see
Section 13, item 3.
13. Open Issues
For review before -01:
1. [MCPDNS] requires DNSSEC at _alter, and this document reports it
without requiring it, because most domains are not signed, large
ones included. A Site handle from an unsigned zone is then one
that only the Issuer accepts (Section 4.3). Either this
document defines its own label, or [MCPDNS] relaxes the
requirement for business records, or Sites must sign their
zones. The _org-alter record of [MCPDNS], Section 6 requires
the organisation's registered legal name and, per [MCPDNS],
Section 8, only recommends DNSSEC.
2. Should the acts-for pass carry the Agent in an RFC 8693 act
claim and the key in the cnf claim of [RFC8747], where existing
verifiers can read them, in place of acting and cnf_jkt? The
other choice is to register the claims of Section 6.2.
3. Should the one-time code move to a separate, removable challenge
label and leave _alter holding only the long-lived envelope?
That would also let ilr return to the meaning [MCPDNS],
Section 7.3.4 gives it, and both changes are needed for the
record to conform to [MCPDNS], Section 7.5.
4. Should a Site be able to enrol by publishing a file at its own
https origin instead of a DNS record, for owners who cannot edit
DNS?
5. Should the Issuer apply the change-of-control signals of
[MCPDNS], Section 13.1.2 to a Site record? A domain deleted and
registered again could then not be claimed under a record its
former owner left up. That checks the registry's creation date
and sets no age bound.
Morrison Expires 24 April 2027 [Page 14]
Internet-Draft Acts-For October 2026
6. Can a seller with no domain of its own accept sign-in?
7. A Site publishing its own client metadata document, beside the
one exact return page.
8. An agency setting up many client domains from one account, and
handing each over.
9. The ID token is RS256 under a key in the Issuer's JSON Web Key
Set and the pass is EdDSA under the separate floor key, and the
ID token's iss is the Issuer's URL while the pass's is the text
alter. Should the two converge?
10. The same Agent signs in to every Site under the same key and
~handle. That joins the Person's per-site subjects
(Section 10). Should an Agent present a key and ~handle per
Site?
11. Which domains can become a Site handle. Section 4.2 refuses
those beginning with a digit, since handle-name does not admit
them, and those beginning with cc- or under bot, since they read
as another tier. Digit-led domains are common and [ALTERURI]
may need to admit them. A proven www. name is folded by the
per-site subject and not by the Site handle.
12. How the pass travels to the Site and how the Agent signs the
request. HTTP Message Signatures [RFC9421], as Web Bot Auth
[WBA] uses, is one candidate.
13. The grant is out of scope here. Should it be a consent grant of
[CONSENT], Section 5.2, with grant as the grant_ref of its
Section 5.3?
14. One-tap record writing at the DNS host (Domain Connect
[DOMAINCONNECT]), where the Site owner never sees the record.
15. Who in a collective can act for its Site handle, change its
client, or sign in to other Sites as it. Members need not all
hold the same permissions. This revision does not cover an
Agent acting for a collective.
14. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
Morrison Expires 24 April 2027 [Page 15]
Internet-Draft Acts-For October 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7636] Sakimura, N., Ed., 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/info/rfc7636>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8176] Jones, M., Hunt, P., and A. Nadalin, "Authentication
Method Reference Values", RFC 8176, DOI 10.17487/RFC8176,
June 2017, <https://www.rfc-editor.org/info/rfc8176>.
Morrison Expires 24 April 2027 [Page 16]
Internet-Draft Acts-For October 2026
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[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/info/rfc8552>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[ALTERURI] Morrison, B., "The 'alter' URI Scheme for Dispatchable
~handle References", Work in Progress, Internet-Draft,
draft-morrison-alter-uri-scheme-05, n.d.,
<https://datatracker.ietf.org/doc/html/draft-morrison-
alter-uri-scheme-05>.
[IDCOMMITS]
Morrison, B., "Identity-Attributed Git Commits via Tier-
Structured Trailers", Work in Progress, Internet-Draft,
draft-morrison-identity-attributed-commits-04, n.d.,
<https://datatracker.ietf.org/doc/html/draft-morrison-
identity-attributed-commits-04>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[WEBAUTHN] W3C, "Web Authentication: An API for accessing Public Key
Credentials, Level 3", January 2025,
<https://www.w3.org/TR/webauthn-3/>.
Morrison Expires 24 April 2027 [Page 17]
Internet-Draft Acts-For October 2026
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", Work in Progress, Internet-Draft,
draft-morrison-mcp-dns-discovery-09, n.d.,
<https://datatracker.ietf.org/doc/html/draft-morrison-mcp-
dns-discovery-09>.
15. Informative References
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object
Signing and Encryption (COSE) Key Thumbprint", RFC 9679,
DOI 10.17487/RFC9679, December 2024,
<https://www.rfc-editor.org/info/rfc9679>.
[CONSENT] Morrison, B., "Consent-Bound Identity Disclosure with
Subject Settlement for HTTP-Native Agent Payments", Work
in Progress, Internet-Draft, draft-morrison-consent-
settlement-07, n.d.,
<https://datatracker.ietf.org/doc/html/draft-morrison-
consent-settlement-07>.
Morrison Expires 24 April 2027 [Page 18]
Internet-Draft Acts-For October 2026
[TOOLNAMES]
Morrison, B., "An IANA Registry for Model Context Protocol
Tool Surface Names", Work in Progress, Internet-Draft,
draft-morrison-mcp-tool-surface-names-registry-03, n.d.,
<https://datatracker.ietf.org/doc/html/draft-morrison-mcp-
tool-surface-names-registry-03>.
[AAUTH] Hardt, D., "AAuth Protocol", Work in Progress, Internet-
Draft, draft-hardt-oauth-aauth-protocol-11, 25 September
2026, <https://datatracker.ietf.org/doc/html/draft-hardt-
oauth-aauth-protocol-11>.
[AUTHMD] WorkOS, "auth.md", May 2026,
<https://github.com/workos/auth.md>.
[CIMD] Parecki, A. and E. Smith, "OAuth Client ID Metadata
Document", Work in Progress, Internet-Draft, draft-ietf-
oauth-client-id-metadata-document-02, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
client-id-metadata-document-02>.
[WBA] IETF Web Bot Auth Working Group, "HTTP Message Signatures
for Automated Traffic", Work in Progress, Internet-Draft,
draft-ietf-webbotauth-httpsig-protocol-00, 1 September
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
webbotauth-httpsig-protocol-00>.
[ATPROTO] Bluesky Social PBC, "AT Protocol Handle Specification",
n.d., <https://atproto.com/specs/handle>.
[DOMVERIFY]
IETF DNSOP Working Group, "Domain Control Validation using
DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-
domain-verification-techniques-13, 22 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
domain-verification-techniques-13>.
[DOMAINCONNECT]
Domain Connect, "Domain Connect", n.d.,
<https://www.domainconnect.org/>.
[MCP] Model Context Protocol, "Model Context Protocol
Specification", 18 June 2025,
<https://modelcontextprotocol.io/
specification/2025-06-18>.
Morrison Expires 24 April 2027 [Page 19]
Internet-Draft Acts-For October 2026
Appendix A. Document History
* draft-morrison-acts-for-00 (2026-10-19): first version.
Acknowledgments
None yet.
Author's Address
Blake Morrison
Alter Meridian Pty Ltd
Email: blake@truealter.com
Morrison Expires 24 April 2027 [Page 20]