What Is Acts-For? The Beginner's Guide to Signing In With a Handle (and Letting Your Agent Sign In Too)

CodexFuse Team · 2026-11-05T11:39:52.927Z · 19 min read min read

What Is Acts-For? The Beginner's Guide to Signing In With a Handle (and Letting Your Agent Sign In Too)

Acts-For is a new Internet-Draft that lets a person sign in to any website with a ~handle they already hold, and lets an AI agent sign in on that person's behalf. This guide answers the question what is Acts-For in plain terms.

The draft, draft-morrison-acts-for-01, is the second revision of the proposal, published on November 3, 2026, two days before this guide was written. Neither the person nor the agent needs a username, a password, or an account on each site.

The idea matters because passwords are still the weakest part of signing in, and AI agents make the problem worse. An agent that books a table or places an order for you either holds your password, which it should never be given, or it stops and hands the task back to you.

Acts-For tries to solve both problems at once: one handle for the person, and a short-lived, tightly limited pass for the agent. This guide explains what Acts-For is, how a ~handle works, how the person and agent sign-in flows run, what a website has to publish to join, and what the draft honestly cannot do yet.

What Is Acts-For?

Acts-For is a proposal for signing in to websites with a ~handle, an identifier a person already holds, instead of a username and password on every site. Acts-For explained in one sentence: you prove who you are once, to an issuer, and every site you visit learns only a number that identifies you to that site alone. Your agent gets a separate five-minute pass that names the same number, its own key and handle, and the limits you set, so it can act for you without ever holding your password.

The proposal comes as an Internet-Draft, draft-morrison-acts-for-01, written by Blake Morrison of Alter Meridian Pty Ltd. It is dated November 3, 2026, and it expires on May 7, 2027.

It is an individual draft on the Informational track, which means no IETF working group has adopted it and it is not a standard. The draft is candid about that status, and this guide treats it as a proposal, not as a finished system.

The sign-in itself runs through a standard OpenID Connect authorization code flow with PKCE, the same flow many sites already use for social login. The difference is what the site learns: a per-site number derived with HMAC-SHA256, the same hash family behind the SHA-256 hash generator, taking the first 20 bytes of the hash, or 160 bits, as the identifier. That number is different at every site, so two sites cannot join their records by comparing it.

A site that wants to accept Acts-For publishes one DNS record and nothing else. That is lighter work than the VPS hosting many small sites still run to serve their pages, and from then on sign-in needs no registration form. A number the site has seen before is a returning person, and a new number opens the account on the spot.

What Is a ~Handle?

A ~handle is an identifier a person already holds, written with a leading tilde, such as ~alice. Acts-For defines it through three companion drafts: MCPDNS defines the identifier, ALTERURI defines the alter: URI form used to write it, and IDCOMMITS defines its three tiers. The tier is read from the spelling alone, which is what makes the handle self-describing.

Only a Sovereign-tier handle belongs to a person, and only a Bot-tier handle belongs to an agent. An Instrument-tier handle is never an agent under this draft, because it has no envelope of its own and is not an independent principal. A site gets a Sovereign-tier handle of its own, ~ plus its domain in lowercase, when its DNS record verifies.

When the draft writes a handle as a reference, it uses the alter: URI form, such as alter:~alice. That form comes from the ALTERURI draft, which was provisionally registered with IANA on October 5, 2026. The handle itself is the key idea of the whole proposal: one identifier you already hold, accepted everywhere, instead of a fresh account on every site.

How Does Acts-For Work in Three Steps?

Acts-For has three actors: the person, the agent, and the site. The site joins first, the person signs in second, and the agent signs in third, each step building on the one before it.

The site's single DNS record does two jobs at once: it proves the site controls its domain, and it registers the site as an OAuth client in the same step. The person then signs in through the issuer with a passkey, and the site receives a one-hour ID token naming the person by a per-site number. The agent then asks the issuer for a pass over MCP, and the site checks that pass against a published key without calling anyone.

The design goal is visible in that last detail. The site verifies the agent's pass on its own, against a key published at the issuer's /.well-known/alter-keys.json, and it never calls the issuer during sign-in. The issuer is involved when tokens and passes are issued, but not when they are checked.

How Do You Sign In With a ~Handle?

Signing in with a handle takes five steps, and the passkey is the step that matters most. The acts-for sign in handle flow runs on the OpenID Connect authorization code flow with PKCE, and this section shows sign in with handle step by step.

1. Click "Sign in with ~alter" on the site.
2. Confirm with a passkey at the issuer. The issuer must require user verification, with WebAuthn, on every sign-in, even when the person already has a session there.
3. The issuer runs the OpenID Connect authorization code flow with PKCE (method S256), a one-time state, and a nonce.
4. The site receives an ID token signed RS256, valid for one hour, with sub set to the per-site subject and verified set to yes, plus an opaque access token valid for 600 seconds, accepted only at the userinfo endpoint. No refresh token is issued.
5. The site verifies the ID token's signature against the issuer's published JSON Web Key Set before acting on it. Checking iss, aud, exp, and nonce in the browser is not enough.

The fresh passkey on every sign-in is deliberate. A session at the issuer is never enough to sign a person in to a site, because a browser left signed in on a shared or stolen machine would otherwise let whoever holds it sign in as that person at every site. The draft puts it plainly: that one gesture is two factors, the device held and the fingerprint, face, or PIN that unlocks it.

The numbers tell the story: the ID token lasts six times as long as the access token, and twelve times as long as the agent's five-minute pass. Short lifetimes are the point. A stolen token stops working within minutes, and the agent's pass expires fastest of all.

At the consent step, the person may switch on sharing their ~handle, their email, or both, through the handle and email scopes. Only the consent step can add them. The site learns the person's ~handle or email only if the person shares them, and the per-site number alone never begins with ~ and can never be read as a handle.

What Is the Acts-For Pass for Agents?

The acts-for pass is how an agent signs in on your behalf without ever holding your password. It is a CBOR Web Token in a COSE_Sign1 structure, signed with EdDSA by the issuer's floor key, and it is valid for at most 300 seconds, or five minutes.

The acts-for agent sign in flow starts with the MCP tool alter_sign_in. An agent that holds a grant from its person calls that tool at the issuer, naming the site's domain. The issuer checks that the grant exists, is in force, and covers that site, then returns the pass.

The issuer must refuse an agent whose ~handle is not Bot-tier. If you want the background on the protocol the tool call travels over, our guide on what MCP over MOQT is explains the transport MCP can run on.

The pass carries the limits the person set. The acting claim names the tools the agent may use, through may_tools, and an optional max_value caps a purchase by amount and currency.

The site must hold the agent to both, and it must verify the request signature under the agent key named in cnf_jkt. A pass without that signature check would be a bearer token valid for up to five minutes, and the draft says so directly.

One part is still undecided: the draft does not yet say how the pass travels to the site or how the agent signs the request. HTTP Message Signatures, as Web Bot Auth uses, is one candidate, and the question is on the draft's own list for revision -02. A site that receives a pass checks it against the floor key published at /.well-known/alter-keys.json and calls nobody, which keeps sign-in working even if the issuer is unreachable at that moment.

The pattern will be familiar to anyone who already lets a coding agent work on their behalf. Our guide on how to use Claude Code shows the day-to-day workflow such an agent follows, and the acts-for pass is the sign-in half of the same idea: the agent acts, but within limits you set, and never with your password in hand.

How Does a Website Join Acts-For?

A website joins Acts-For by publishing one DNS TXT record at the label _alter in front of its domain. The record is the envelope record of the MCPDNS draft, version v=alter1, and the draft's own example, for a fictional bakery, reads: _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 issuer verifies the record when the site owner asks it to, and it must check six things: the record parses with every required field, the signature verifies under the public key, the handle equals the one being claimed, the timestamp is within seven days of the start of the claim, the ilr digest equals the computed value, and the digest of the one-time code equals the digest the issuer stored. The first record to verify wins and clears every other pending claim on that domain.

Verification produces two things in one step: the site handle, a Sovereign-tier ~handle made of ~ plus the site's domain in lowercase, and an OAuth 2.0 client for the site. The client is public, its scopes are openid and profile, and its single redirect URI is one exact https address on the proven domain or its www name. There is no wildcard, no port, no user information, and no fragment, and the site needs no separate client registration.

Three kinds of domain cannot enroll. A domain whose first label begins with a digit, one whose first label begins with cc-, and any domain under the bot top-level domain are all excluded, because each would make the site handle read as the wrong tier. The private key behind the record must not leave the device that generated it, and a site owner who loses that device proves the domain again by publishing a new record.

Acts-For vs Sign in With Google: What Is Different?

The closest thing most readers know is Sign in with Google, so the comparison is the fastest way to see what Acts-For changes. Both remove the password. The differences are who holds the identifier, what the site learns, and whether an agent can sign in at all.

The last row is the honest one. Sign in with Google is a production service used by millions of sites, and Acts-For is a draft whose first version is fifteen days old, with a test deployment of one site. The comparison shows what the proposal is aiming at, not what it has already achieved.

What Privacy Does Acts-For Give You?

The privacy core of Acts-For is the per-site subject. Two sites see different numbers for the same person, so they cannot join their records by comparing identifiers, the way they can when every site sees the same Google identifier. The handle and email stay private unless the person switches them on at the consent step.

The draft is equally candid about the limits, and they matter. The issuer sees every sign-in it issues for, and the protocol gives a person no way to keep a sign-in from it.

The issuer also holds the key the per-site subject is computed from, so it can compute any person's subject at any site. And the agent's own fields, acting.kid, acting.handle, and cnf_jkt, are the same at every site the same agent signs in to, so two sites that compare them learn that their two per-site subjects are one person.

Domain control is the only thing the site record proves. Whoever controls a domain's DNS can enroll 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, and the draft says this is accepted. A site handle whose owner leaves without handing it over becomes dormant, and proving its domain again revives it only after a wait in which the former owner, or any member, can object, because control of a domain's DNS does not show who ran the site.

Is Acts-For a Standard?

No. The acts-for ietf draft is an individual Internet-Draft on the Informational track, dated November 3, 2026, and it is not a standard, not an RFC, and not adopted by any IETF working group. The draft's own boilerplate says Internet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted at any time, and that it is inappropriate to cite them other than as work in progress.

The revisions moved fast: thirteen days passed between -00 on October 21 and -01 on November 3, and this guide was written two days after -01 appeared. From November 5, the draft has 183 days left before it expires on May 7, 2027. The -01 revision's changes are small but telling: a new person's first sign-in opens the account, and the Related Work section adds POPPY, PACT, and KYAOS, three neighboring efforts the author wants readers to compare.

The draft lists fourteen open items for revision -02, including whether the pass should travel by HTTP Message Signatures, whether a site could enroll with a file at its own https origin instead of a DNS record, and whether a seller with no domain of its own can accept sign-in at all. That list is a good map of what is still undecided, and it is the reason this guide calls Acts-For a proposal throughout.

The idea is royalty-free to implement. Alter Meridian Pty Ltd, the author's company, trading as True Alter, filed an IPR disclosure offering a royalty-free, reasonable and non-discriminatory license to all implementers of the draft. The company describes itself, in its own words in a public filing, as building identity infrastructure.

What Is Out of Scope in Acts-For?

The draft states its own limits plainly: out of scope are how a person obtains a ~handle, how the person grants authority to an agent, payment, and anything the site does after sign-in. Only the grant's effect on the pass is specified, not the grant itself.

That means this guide cannot tell you how to get a ~handle, because no published source explains it yet. It cannot tell you how to create or manage a grant, or what signing up costs, because the draft puts payment out of scope and no price exists anywhere in it. Any article that describes a sign-up flow or a price for Acts-For today is inventing it.

The same honesty applies to the companion drafts. MCPDNS defines the ~handle and the DNS discovery, ALTERURI defines the alter: URI form, and IDCOMMITS defines the commit trailers that bind handles to git work.

They are part of one author's larger identity system, and Acts-For is the sign-in piece of it. The whole family is young: the companion drafts are October 2026 revisions, and none of them is a standard either.

Is Acts-For Live Anywhere Yet?

Barely. The draft's implementation-status section, marked as a note to be removed before publication, says the ~alter service has implemented most of the document in a test deployment.

As of October 19, 2026, one small business site, on its own domain at a public host, published its site record, was verified, and minted its client, and one person signed in to that site with a passkey. Consent, code issue, and token exchange each succeeded.

That is the full extent of the deployment claim: one small business site and one test sign-in. There are no usage figures, no named adopters, and no production deployment in the draft.

The example domain in the draft, riverbakery.example, is fictional, and no independent news article, blog post, or explainer about Acts-For was found in searches run on November 5, 2026. This guide is, as far as those searches show, the first independent explainer of the draft.

The Bottom Line: Should You Follow Acts-For?

Follow it if you build sign-in flows or AI agents, and watch it if you care about where identity on the web is heading. The proposal is small, honest about its limits, and aimed at a real gap: agents need to sign in for people, and today they cannot do it without holding a password. A five-minute pass with tool and spending limits is a credible answer to that problem.

Do not build on it yet. It is an individual draft, not a standard, its pass transport is undecided, its grant mechanism is out of scope, and its only deployment is a single test sign-in.

The right stance is the one the draft itself takes: interesting, worth reading, and not ready to depend on. If you run agents in a sandbox while you wait for standards like this to settle, our guide on how to use E2B shows the environment that pattern runs in.

The next thing to watch is revision -02, due before the draft expires on May 7, 2027. If it settles the pass transport, the grant, and the DNS record questions, Acts-For will be worth a second look. Until then, the most useful thing you can do is read the draft itself, which is short, clearly written, and linked in the sources below.

Sources

• Acts-For, draft-morrison-acts-for-01 — IETF Datatracker, November 3, 2026. https://datatracker.ietf.org/doc/html/draft-morrison-acts-for-01
• Acts-For, draft-morrison-acts-for-00 — IETF Datatracker, October 21, 2026. https://datatracker.ietf.org/doc/html/draft-morrison-acts-for-00
• Diff: draft-morrison-acts-for-00 to draft-morrison-acts-for-01 — IETF Author Tools. https://author-tools.ietf.org/iddiff?url2=draft-morrison-acts-for-01
• Discovery of Model Context Protocol Servers via DNS TXT Records (MCPDNS), draft-morrison-mcp-dns-discovery-09 — IETF Datatracker, October 2026. https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-09
• The 'alter' URI Scheme for Dispatchable ~handle References (ALTERURI), draft-morrison-alter-uri-scheme-05 — IETF Datatracker, October 2026. https://datatracker.ietf.org/doc/html/draft-morrison-alter-uri-scheme-05
• Identity-Attributed Git Commits via Tier-Structured Trailers (IDCOMMITS), draft-morrison-identity-attributed-commits-04 — IETF Datatracker, October 2026. https://datatracker.ietf.org/doc/html/draft-morrison-identity-attributed-commits-04
• IPR Disclosure: Acts-For, Claim Currency, did:alter Method — IETF, submitted October 22, 2026. https://datatracker.ietf.org/ipr/7654/
• Comment on Stablecoin-Issuer Customer Identification Rule, Alter Meridian Pty Ltd — US Federal Reserve, August 20, 2026. https://www.federalreserve.gov/apps/proposals/comments/FR-2026-0005-01-C24

Frequently Asked Questions

What is Acts-For?

Acts-For is an IETF Internet-Draft, draft-morrison-acts-for-01, that lets a person sign in to any website with a ~handle they already hold, and lets an AI agent sign in on their behalf with a short-lived pass. Neither needs a username, a password, or an account on each site.

Is Acts-For a standard?

No. It is an individual Internet-Draft on the Informational track, published November 3, 2026, and it expires on May 7, 2027. No IETF working group has adopted it, and it is not an RFC or a standard.

How do I get a ~handle?

The draft does not say. How a person obtains a ~handle is explicitly out of scope in the draft, and no published source explains the sign-up flow or any price. Any guide that describes one today is inventing it.

Can an AI agent really sign in for me with Acts-For?

That is the proposal's second half. An agent holding a grant from you calls the MCP tool alter_sign_in at the issuer and receives a pass valid for at most five minutes, naming your per-site number, the agent's own key and Bot-tier handle, and the limits you set, such as which tools it may use and how much it may spend. The site checks the pass against a published key and never calls the issuer.

Is Acts-For live anywhere yet?

Only as a test. As of October 19, 2026, one small business site published its site record and one person signed in with a passkey. There is no production deployment, no named adopter, and no independent coverage yet.