]> Alter Meridian Pty Ltd

blake@truealter.com

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.

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. Under Acts-For the person signs in with a ~handle they already hold (, 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.

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 when, and only when, they appear in all capitals, as shown here.

~handle:

An identifier as defined in , Section 2, with the grammar of handle-name in , Section 3.3, and the tiers of , 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 , as 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 (, 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 (, 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 ().

Issuer:

The service that authenticates the Person, issues tokens and passes, and publishes the keys that verify them. In the deployment described in this is ~alter.

Site record:

The DNS TXT record of .

Per-site subject:

The identifier the Issuer gives a Person for one Site ().

Acts-for pass:

The token an Agent presents to a Site ().

Floor key:

The Issuer's Ed25519 key that signs acts-for passes, published at the Issuer's /.well-known/alter-keys.json ().

Collective:

A Site handle held by more than one Person ().

Overview

Acts-For in one picture | | | | 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 | ]]>

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.

The Site Record

Location and Format A Site joins by publishing one TXT record at the label _alter prepended to its domain , as the envelope record of : ; ilr=; ts=; rev=; sig=; code=" ]]> The fields v, h, pk, ilr, ts, rev and sig are the envelope of , Section 7, signed over the input of , Section 7.4, with these values:

• h is the Site handle (), with its leading tilde as , Section 7.3.2 requires;
• pk is an Ed25519 public key generated on the Site owner's device. The private key MUST NOT leave that device;
• ilr is, as built, the base64url SHA-256 of the JSON canonical form 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 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 alone ignores it (, Section 7.5). ilr and code do not conform to . 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 , item 3.

The Site Handle The Site handle is ~ followed by the Site's domain, in lowercase, in its A-label form , 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: 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 (, Section 6.9; , 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 , item 10.

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.

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 , 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 , Section 12.3 and step 3 of , Section 3.4. The Issuer accepted it and no third party can verify it. See , 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.

What Verification Produces A verified Site record produces, in one step:

• the Site handle (), 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 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 . 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.

Person Sign-In

On the Page The Site embeds a button and a script: ]]> The script is pinned by its integrity hash. A changed script is published at a new path.

The Flow The flow is the OpenID Connect authorization code flow with PKCE , 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 . 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 , Section 5.4. Neither scope carries an alter: prefix, because a scope token with one would read as an alter: URI , and a scope is not one. The Site receives:

• an ID token, signed RS256 by the Issuer, with iss the Issuer, aud the client identifier, a lifetime of one hour, sub the per-site subject (), verified set to yes, the same band the acts-for pass carries (), and handle and email only where the Person switched them on. email and email_verified are the claims of , Section 5.1. handle carries the Person's ~handle in the bare form of , 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 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. It suits one read of userinfo at sign-in.

The Site MUST verify 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. A sub the Site has seen before is a returning Person. A sub it has not seen is a new Person, and the Site opens the account from this sign-in with no registration form.

The Per-Site Subject The per-site subject is a pairwise identifier in the sense of , Section 8.1. It is the lowercase base32 encoding of the first 20 bytes of an HMAC-SHA256 , 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 , 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.

Agent Sign-In

Asking for a Pass An Agent that holds a grant from its Person calls the 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 ; see .

The Acts-For Pass The pass is a CBOR Web Token in a COSE_Sign1 structure , algorithm EdDSA , 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 , Section 9.1 allows:

profile (-65537):

the text alter-site-pass-v0. A verifier MUST refuse a pass whose profile it does not know.

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 , 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 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 ;
• exp is at most 300 seconds after iat and never later than acting.valid_until.

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 . 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 carrying a COSE Key thumbprint , is , item 2.

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 , item 11). The Site MUST:

1. verify the pass under the Issuer's Ed25519 floor key, published at the Issuer's /.well-known/alter-keys.json ;
2. check profile, check that aud is its own domain normalised as in , and check that exp has not passed;
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 happens at sign-in. The Site does not call the Issuer.

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.

Implementation Status Note to the RFC Editor: please remove this section before publication, per . ~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.

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. , Section 13.1.2 already gives the signal for it, a changed registry creation date. See , item 5. The Site handle spelled like a domain is a Handle-Domain Confusion surface (, 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 (), and auth_time reports when that happened. A Site that sends max_age or prompt=login 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.

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. 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. The Issuer holds the key the per-site subject is computed from and can compute any Person's subject at any Site.

IANA Considerations This revision makes no IANA request. The _alter label is requested in . A revision meant for publication would need to request:

• the well-known URI suffix alter-keys.json ;
• the CWT claims of , unless they stay under Private Use keys;
• the ID token claim handle;
• the tool surface name alter_sign_in .

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.

• 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.
• The Personal Agent Protocol has a person's agent reach a company through a file at /.well-known/poppy.json, sign in by OAuth, and hold a delegated key and a pairwise user identifier for each company. The agent assigns that identifier. It uses no DNS record.
• PACT profiles OAuth for private agent delegation, with limits on grants and pairwise agent identifiers. The authorization server is the issuer.
• KYA-OS has a service authorise a request from a signed proof and a delegation chain carrying scopes, time bounds and budget caps.
• auth.md 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 are the per-site subject's mechanism. Dynamic registration and client ID metadata documents remove per-provider registration over HTTPS; neither uses DNS or a key made by the site owner.
• Web Bot Auth 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 already names the agent in act with the person in sub; see , item 2.
• AT Protocol handles 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 recommends a separate, removable challenge label with the token first. The Site record does not follow it; see , item 3.

Open Issues For review before -02:

1. 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 (). Either this document defines its own label, or relaxes the requirement for business records, or Sites must sign their zones. The _org-alter record of , Section 6 requires the organisation's registered legal name and, per , 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 , where existing verifiers can read them, in place of acting and cnf_jkt? The other choice is to register the claims of .
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 , Section 7.3.4 gives it, and both changes are needed for the record to conform to , 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 , 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.
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. Which domains can become a Site handle. 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 may need to admit them. A proven www. name is folded by the per-site subject and not by the Site handle.
11. How the pass travels to the Site and how the Agent signs the request. HTTP Message Signatures , as Web Bot Auth uses, is one candidate.
12. The grant is out of scope here. Should it be a consent grant of , Section 5.2, with grant as the grant_ref of its Section 5.3?
13. One-tap record writing at the DNS host (Domain Connect ), where the Site owner never sees the record.
14. 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.

Normative References This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Alter Meridian Pty Ltd n.d. Alter Meridian Pty Ltd n.d. W3C Alter Meridian Pty Ltd n.d. Informative References This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. Alter Meridian Pty Ltd n.d. Alter Meridian Pty Ltd n.d. Personal Agent Protocol project KYA-OS Working Group WorkOS IETF Web Bot Auth Working Group Bluesky Social PBC n.d. IETF DNSOP Working Group Domain Connect n.d. Model Context Protocol

Document History

• draft-morrison-acts-for-01 (2026-11): a new Person's first sign-in opens the account. Related Work adds , and .
• draft-morrison-acts-for-00 (2026-10-19): first version.

Acknowledgments None yet.