Open proposalsProposal 1Draft 2

Jurisdictional context

A small, vendor-neutral way for software to carry, for each party to its work, which jurisdiction's law reaches that party, from the first hop to the last

Proposed by: LexLintSean McDermott, Co-Founder and CEO
Draft 2: 28 October 2026Comments to open@lexlint.io
License: CC BY 4.0Adopt it, fork it, improve it

Legal information, not legal advice. This proposal describes a mechanism for carrying facts the law turns on. It does not decide which law applies to anyone, and nothing in it is a determination; that is a question for counsel. See the notice in the footer.

Summary

A law reaches a piece of work through where one of its parties is: where the person it serves is sitting, where the data subject lives, where the operator is established, whose machine was read. Those facts exist at different hops of the work, and the hop that can see one is rarely the hop that needs it. Nothing standard carries them, so each system either guesses from its own socket, which yields the location of a point of presence, or records nothing at all. This proposal gives software one small way to carry them: a reading per party, never merged into one country code, with its source and a commitment to its evidence, as a structured HTTP header across trust boundaries and as baggage inside them, recorded at each hop exactly as given. It says how it meets each of the nine requirements in the paper Whose law was that? and why the readings stay out of the authorization credential. It is for any distributed software, agents included, and it is offered for anyone to adopt.

Figure 1. One piece of work across five hops. The principal's reading is made once, at the only hop that sees the signal, and travels as a result. Each later hop records what it was given and adds a reading only for a party it introduces.

1The problem, in one page

The law holds people and organizations responsible, not software, and it reaches each of them through where they are. Data protection law reaches a controller through its establishment and a person through their residence. Access law reaches through where the machine that was read belongs. Age rules reach through where the user was sitting at the moment of use. AI law reaches through the market a system was placed on and where its output is used. The server's region is almost never the fact a statute turns on.

Ordinary software answered this once, at launch. The company and its servers were in one jurisdiction, the customers in a known set of them, and the answer went into a policy. Distributed software answers it per call, and the facts are spread across hops that never see each other. A user in Bavaria reaches an origin in Virginia through an edge node in Frankfurt; the origin calls a payment service in Ireland, and an agent acting for that user fans out to five subagents and a hundred sites.

At an origin behind any edge, the IP address on the socket belongs to the edge, not to the person. A check run on it returns a well-formed country code, on time, with no error, and it is the country of a point of presence. The user's own IP address exists at exactly one hop, and that is the hop whose record must not keep it. So each hop downstream works from what it is told, and today nothing tells it. A service acting on a French user's request applies whatever it would have applied to anyone, logs it that way, and the record then verifies, signs and chains around a wrong answer.

The claim in one line

Which jurisdiction's law reaches each party to a piece of work is a fact that has to travel with the work, per party, from the first hop to the last, and be recorded at each hop as it was given.

This document is the mechanism. It names the parties, defines a reading, fixes the vocabulary and the rules, and binds the model to HTTP, to baggage, to message queues and to the agent protocols. It is written for the people who maintain edges, gateways, frameworks, services and record formats, and it assumes no product. Nothing in it decides which law applies; it carries the facts that question turns on.

2The model

2.1 A piece of work and its parties

The unit is a piece of work: a web request, a batch job, a message, an agent's task, and every call made on its behalf. The context belongs to the work, not to any one system, which is why every hop that acts on the work carries it. A work has parties. Five party keys are defined in this draft, each a plain legal role, with the terms common bodies of law use for it and, for readers arriving from the LexLint handbook, the group it maps to there.

Key	Who	Common legal terms	Handbook group
principal	the person or organization the work is done for	user; data subject acting for themselves; the deployer itself when software acts for its operator	uses, as principal
subject	a person whose personal data is in the work, including anyone the output is sent to	data subject; affected person; recipient	uses, as data subject or affected person
operator	the organization that runs the software and answers for the work	controller; deployer; operator	runs
provider	an organization whose service or model a hop called to do the work	processor; provider; sub-processor	makes
counterparty	a system a hop read from or wrote to, and the organization behind it	the accessed party; rightsholder; recipient system	talks_to

Two kinds of party are deliberately not carried. The overseeing party, a regulator or an auditor, is derived from the other readings: the regulator is the one whose law reached. The distributing party, a store or an importer, is a design-time fact that does not change per piece of work. New party keys are added by registration, which is open question 3.

Figure 2. Per party, never merged. Different bodies of law pivot on different parties to the same work, so one answer for the whole work is the wrong shape.

2.2 Readings

A reading is one statement about one party. It is a fact with a source and an age, never a conclusion: it says that this work was evaluated as directed at this jurisdiction, on this signal, by this issuer. It is never the sentence "this law applies" or "this law does not apply". That sentence is a legal conclusion, and the carrier never makes one.

Field	Meaning	Values
party	which party the reading is about	one of the five keys above
fact	which fact about the party the law turns on	`presence` (where they are at the time), `residence` (where they live), `establishment` (where the organization is established)
jurisdictions	one or more jurisdiction identifiers	see 2.3; `unknown` is a value
src	how the reading was made	`declared` (the party said so: an account, a configuration, a legal notice), `observed` (read from a network signal at the hop where that signal exists), `resolved` (looked up from a domain or identifier in a maintained dataset), `unknown` (no basis)
by	who made the reading	a hostname or an identifier the receiver can recognize
at	when it was made	optional; a date
ev	a commitment to an evidence record held elsewhere	optional; opaque to every reader not shown the evidence; never the signal itself
vocab	the vocabulary the identifiers are drawn from	optional; absent means ISO 3166

Each party has a default fact, so the common case names none: the principal's presence, a subject's residence, and the establishment of an operator, a provider or a counterparty. A reading about a different fact names it, so a principal's declared residence travels beside the edge's reading of their presence without displacing it.

2.3 Jurisdiction identifiers

The base vocabulary is ISO 3166: an alpha-2 country code such as FR, an ISO 3166-2 subdivision code such as US-CA, and the exceptionally reserved code EU for the European Union. unknown is a value. Identifiers are compared without regard to case and written in upper case. Any other published vocabulary may be used by naming it in vocab as a URI; a nested identifier such as urn:ungovr:us/ca is one such vocabulary, and the base is never anything but ISO 3166.

A receiver widens upward only. A subdivision is read as inside its country, and a member state as inside its union, so a reading of DE brings the law of the European Union with it. A country never brings its subdivisions, because a local rule binds inside the locality and a system that widened downward would read every local rule in the country against every piece of work.

2.4 Rules for every hop

Forward every reading you received, unchanged, on every call you make on the same work, including to subagents, queues and batch steps.
Record every reading you were given, with its issuer, in your own record of the work.
Never re-derive a reading you were given from your own network view. The IP address on your socket belongs to the hop before you.
Add a reading only for a party you introduce, and name yourself as its issuer.
Make a reading from a network signal only at the hop where that signal exists, and carry the result, never the signal.
unknown is a value. Never coerce it to a default. When the principal's jurisdiction is unknown, nothing narrows: the work is read against the declared set as a whole, not against no jurisdiction.
Across a trust boundary, verify. A reading you cannot verify is kept in the record marked unverified and treated as unknown for any decision.

A responding hop may return the readings it added, its own establishment as a provider or a counterparty and any party it introduced further down, so the caller's record can carry the fan-out. Whether a response reading is framed from the work's point of view or the speaker's is open question 2.

Figure 3. Three kinds of fact. What travels with the work, what is added at the hop that introduces a party, and what never enters a reading or a record built from one.

3Bindings

One model, several carriers. The HTTP header is the reference form; the others map onto it field for field, so a reading made at an edge and a reading read out of a message queue are the same reading.

3.1 The HTTP header

One field, a Structured Fields dictionary (RFC 9651). The name is provisional and is open question 1. It carries no X- prefix, which RFC 6648 deprecated.

Jurisdictional-Context: principal=DE;src=observed;by="edge.example.net";ev="k7Qf2m...", subject=(FR GB unknown);src=declared;by="app.example.com", operator=US-CA;src=declared;by="app.example.com"

Part	Form	Rule
key	`<party>` or `<party>.<fact>`	a bare party key means its default fact; a key appears once, so several jurisdictions for one party and fact go in the inner list
value	a token, or an inner list of tokens	`FR`, `US-CA`, `EU`, `unknown`; in another vocabulary, a string
src	token	`declared`, `observed`, `resolved`, `unknown`
by	string	the issuer
at	date	optional
ev	string	optional; an opaque commitment
vocab	string	optional; a URI naming the vocabulary of the value

Readings are about the set of jurisdictions for a party and a fact, never about an individual. The field is sent on requests, and on responses only to carry readings the responder added. An intermediary that does not understand it forwards it unchanged, as rule 1 requires.

3.2 Baggage

Inside a trust domain the same readings travel as W3C Baggage members, which the tracing libraries already on every instrumented hop propagate by default, in every language they support. The mapping is one to one: the member key is jurisdiction.<party> or jurisdiction.<party>.<fact>, several jurisdictions are joined with +, and the parameters ride as the member's properties.

baggage: jurisdiction.principal=DE;src=observed;by=edge.example.net, jurisdiction.subject=FR+GB+unknown;src=declared, jurisdiction.operator=US-CA;src=declared

The Baggage specification's own warning applies: do not carry confidential information across a trust boundary in baggage. The context is coarse by construction, so the warning is met by never putting anything else beside it, and by using the signed form of 3.4 the moment the work leaves the domain.

3.3 Messages, remote procedure calls and the agent protocols

A message queue carries the HTTP string unchanged as a message header under the same name, and remote procedure call metadata carries it under the lower-cased name. A batch step that reads a message forwards what it read, as rule 1 requires, so a nightly job is a hop like any other. The Model Context Protocol carries the string in a namespaced metadata key on each request, and the agent-to-agent protocol as an extension activated per request; both need a neutral namespace or URI that nobody owns, which is open question 7. Until one exists an implementer uses a namespace of its own and says so.

3.4 Across a trust boundary

A claim is as good as its issuer. Inside a trust domain the readings are unsigned, because the hops already trust each other. Across a boundary the header is covered by an HTTP message signature (RFC 9421), with key discovery left to the two parties, or the same readings travel as a claim in a token the edge issues to the origin. This draft profiles the header and requires one of the two across a boundary; the signature component set is open question 5. A receiver that cannot verify applies rule 7.

Figure 4. Two tiers, one model. Baggage inside a trust domain, where the tracing libraries already carry it; the signed header, or a token claim, across the boundary between two.

4Privacy

The context holds country or subdivision labels and the word unknown. A label at that granularity is a derived, non-identifying value on its own: it sits far outside the radius at which a jurisdiction such as California treats location as sensitive, and it is the granularity regulators already accept as a control rather than as surveillance. It becomes personal data only in the company of an identifier, so the rule is enforced across every field admitted to a record, never checked once on this one.

What never enters a reading, or a record built from one: an IP address, a precise coordinate, a user or session identifier, in clear or as a digest. A digest does not rescue a low-entropy value, because the space of possible inputs is enumerated in seconds and the digest is the value. The signal a reading was made from lives in the evidence record the ev commitment points to, under its own retention and access rules, and the commitment carries a random value of its own so that it is inert to anyone not shown the evidence.

5Three worked examples

Three, chosen to show that the model is for all software and not for agents alone. Each table says what a hop received, what it added, and what its record holds.

5.1 A web request

A user in Bavaria reaches an origin in Virginia through an edge node in Frankfurt. The origin, run by an operator established in California, calls a payment provider established in Ireland.

Hop	Receives	Adds	Records
Edge	nothing: the user's own connection	`principal=DE;src=observed;by="edge"`, from the one signal only it sees	the reading and the evidence commitment; never the IP address
Origin	the principal reading, verified	`operator=US-CA;src=declared`, from its configuration	both readings, with the edge as the principal's issuer
Payment provider	both readings, signed	on its response, `provider=IE;src=declared`	both readings as given, and its own

Three records, written by three parties, one reading of the principal.

5.2 A batch job

A nightly job run by an operator established in California sends messages to three recipients. There is no edge and no user: the principal is the operator itself, since the work is done for the organization that runs it.

Hop	Receives	Adds	Records
Job	nothing	`principal=US-CA` and `operator=US-CA`, both `src=declared`; `subject=(FR GB unknown);src=declared` from the account records, one recipient's residence unknown	the readings, per message
Mail relay	the readings, on each message	`counterparty=US;src=resolved` for the receiving mail service	the readings as given

Each sent message's record carries the subject reading, so the outreach law that reaches each recipient can be read later without re-deriving anything, and the recipient whose residence was unknown stays unknown rather than becoming a default.

5.3 An agent task

A person in France asks an agent run by a California operator to compare prices on five retail sites. The harness starts five subagents, one per site, and the agent calls a model whose provider is established in the United States.

Hop	Receives	Adds	Records
Edge	nothing	`principal=FR;src=observed`	the reading, never the IP address
Harness	the principal reading	`operator=US-CA;src=declared`; passes both to every subagent	both, and the delegation it made
Model call	both readings	`provider=US;src=resolved`, from the model's domain and a maintained lookup	the readings as given, and the provider
Each subagent	both readings	`counterparty=<code>;src=resolved;by="harness"` for its site	the readings as given, and its counterparty

The aggregate record shows one principal reading across five subagents, five counterparties and one provider. A subagent started without the context would have carried nothing, and that is the case rule 6 names: unknown, read against the declared set, never a default.

6What this proposal does not do

It does not decide which law applies. It does not define a policy language, and it says nothing about what any party owes. It is not a trace: the trace identifiers are a separate and already standard concern, and this context is carried beside them, never inside them. It is not an identity system. It is not a consent signal; Global Privacy Control and the Interactive Advertising Bureau's Global Privacy Platform are complementary and may be referenced from a reading, which is open question 9. It does not replace the Forwarded header, which carries the client's IP address to the origin and is the signal a reading is made from at the edge. It is not legal advice, and adopting it meets no legal responsibility by itself.

7Requirements met

The paper Whose law was that? derives nine requirements from deadlines the law already sets: what any record of a piece of work must do, whatever it is built from, for those deadlines to be read from it. They are stated there, numbered R1 to R9, and each number below links to its statement. This section says how this proposal meets each one and what it leaves to someone else (7.1), then what each kind of software would change to meet them (7.2). An objection to how a requirement is met here is an objection to this mechanism, not to the requirement.

7.1 By requirement

Requirement	How this meets it	What it leaves to someone else
R1	A reading is one statement about one party, under one of five party keys, and the readings for a piece of work are never merged into one country code (2.1, 2.2; figure 2).	Which law reaches each party, and what that law asks. The proposal carries the facts and decides nothing (6).
R2	Rule 5 lets a reading be made from a network signal only at the hop where that signal exists, rule 4 has a hop add readings only for the parties it introduces, and every reading names its issuer (2.2, 2.4).	The check that makes a reading, and the maintained dataset a resolved reading is looked up in.
R3	Rule 5 carries the result and never the signal, and no reading or record built from one holds an IP address, a precise coordinate or a user or session identifier, in clear or as a digest (2.4, 4; figure 3).	Holding the same line across every other field a record admits, since a label becomes personal data in the company of an identifier (4).
R4	The value unknown is permitted for a party's jurisdictions and for a reading's source, and rule 6 forbids coercing it to a default: an unknown principal is read against the declared set as a whole (2.2, 2.4; example 5.3).	What a policy does with an unknown, which each deployment decides.
R5	The optional ev field is a commitment to an evidence record held elsewhere, with a random value of its own, so it is inert to anyone not shown the evidence (2.2, 4).	The evidence store, its retention and who may see it. Whether a commitment has a defined shape is open question 8 (9).
R6	Rule 1 forwards every reading to subagents, queues and batch steps, so each subagent holds the principal's reading as given, and a responding hop may return the readings it added, so the caller's record carries the fan-out (2.4; examples 5.2, 5.3).	The delegation chain itself, which agent started which and with what scope, written by the framework that starts them (7.2).
R7	Rule 1 forwards each reading unchanged, rule 2 records it with its issuer, and rule 3 forbids re-deriving it from a hop's own network view (2.4; figure 1).	Verifying a reading that crosses a trust boundary, by a signature or a token claim, with key discovery left to the two parties (3.4; open question 5).
R8	Through the readings only: each record carries, per party, the jurisdictions its retention, access and location settings are keyed on (2.2).	The settings themselves, which belong to the record format (7.2).
R9	The readings travel with the work on every call, a party introduced along the way gets its reading at the hop that introduces it, and a reading may say when it was made, so a record written at the act holds the parties as they were (2.2, 2.4, 3).	A party nobody declared and no hop could read. It stays unknown rather than being reconstructed afterwards.

7.2 By component

The same requirements, read as the change each kind of software would make. Each change names the requirement it meets and where this proposal does it. A change that carries no context says so: it is here because a requirement needs it, whatever carries the readings. One change, the model's incident channel, meets none of the nine: it serves the notification clocks directly.

If you maintain	Change	Meets	In this proposal
An edge network, content delivery network or load balancer	Make the principal's reading once, at the first hop, the only one at which the user's own IP address exists, at national or subnational granularity, and say it is an observation of where a connection came from, so that a declared residence or establishment can outrank it	R2	`src=observed`, and a reading about another fact beside it (2.2); rule 5 (2.4)
	Carry the result, never the signal, and keep the IP address out of your own log	R3	Rule 5 (2.4); section 4
	Let the reading say unknown, and bind it to its evidence by a commitment held apart	R4, R5	Rule 6 (2.4); `ev` (2.2)
	Pass the result on as a reading the origin can authenticate, since every hop downstream works from what you tell it	R7	Signed across the boundary (3.4); rule 7 (2.4)
An agent gateway, proxy, policy engine or governance toolkit	Read the principal's jurisdiction from the reading the edge made, never from the peer IP address	R7	Rules 2 and 3 (2.4)
	At decision time, make a reading for each counterparty and provider a call reaches, from the destination of the call and a maintained lookup of its domain	R1, R2	`src=resolved` (2.2); rule 4 (2.4); example 5.3
	Read an unknown against the whole declared set, never as no jurisdiction	R4	Rule 6 (2.4)
	Expose tool arguments to policy at decision time, give policy authors variables for a party's jurisdiction and for the legal responsibility a rule answers to, write both into the verdict, and deny when a rule cannot be evaluated	R1, R2	Nothing: a policy reads the readings, and the proposal defines no policy language (6)
	Keep payloads out of the action record: digests there, and the content in an access-controlled evidence store with its own retention, because a record that cannot be retracted must not hold a person's data	R3, R5	Section 4; `ev` points into the evidence store (2.2)
An agent framework, harness or tool server	Pass the principal's reading to every subagent you start, unchanged	R7	Rule 1 (2.4); example 5.3
	Write the delegation chain down: which agent started which, with what scope, for which principal	R6	Nothing: the chain is the framework's own record, and the context is not a trace (6). Rule 1 carries the readings down it (2.4)
	If you publish a tool, say in its manifest who operates the service behind it and where that operator is established, so a caller does not have to guess from a domain	R1, R9	A reading with `src=declared` (2.2)
A model or a model interface	Accept the readings with a request and return them in your usage record, so that two records of one action agree	R7	Rules 1 and 2 (2.4); a response carries the readings it adds (3.1)
	Publish where the service is offered from and where its operator is established, as data a caller's provider reading and an operator's transfer record can cite	R1, R9	A provider reading with `src=declared` (2.2); example 5.3
	Give operators an incident channel with a stated response time, because your own clocks count from the moment you learn of an incident, and an operator is usually the first to know	None	Nothing: the channel carries no context
A record format, audit log or incident framework	Add a reading per party, as the result of a named check that says how and by whom it was made, never the signal it ran on, so a later reader can tell a reading from an artifact of the network path	R1, R2, R3	The reading, with `src` and `by` (2.2); rule 2 (2.4)
	Let unknown be a value, and bind each reading to its evidence, held elsewhere, by a commitment	R4, R5	Rule 6 (2.4); `ev` (2.2); section 4
	Add fields for the retention period, for who may demand the record and for where it is held, settable per jurisdiction rather than once for the deployment	R8	Nothing: these fields carry no context. They are keyed on the readings (2.2)
	In an incident framework or a runbook template, take the affected jurisdictions from the readings recorded when the work was done, and carry the rest of the fact pattern as fields, not prose: which families of law are engaged, the moments each clock counts from and the operator's roles, each an enumerated value or a timestamp, with a source and an age. A timeline the framework sets itself sits beside the statutory clocks, on one scale, and never replaces them	R9	The affected jurisdictions are readings (2.2); the families, the moments and the roles are the framework's own fields

Work	What it is	Relationship
W3C Baggage	context propagation for a distributed request	a carrier; this proposal gives it a vocabulary
W3C Trace Context	the trace identifiers	the trace, which this is not
RFC 7239 Forwarded	the edge's assertion about the client	the signal a reading is made from, at the edge only
RFC 9651 Structured Fields	header syntax	the syntax used
RFC 9421 HTTP Message Signatures	signing fields	the signed form across a boundary
RFC 6648	deprecates the `X-` prefix	why the header is not `X-` anything
Global Privacy Control	a legal opt-out signal as a header	precedent for a legal signal riding a request
Global Privacy Platform and OpenRTB	per-jurisdiction consent sections through a supply chain	the nearest structural precedent; keyed by jurisdiction, not by party
OpenID AuthZEN	the enforcement-point to decision-point interface	where a decision point would read the context
Identity Assertion JSON Web Token Authorization Grant	a grant by which an application turns a user's identity assertion into an access token for an API in another trust domain, through the identity provider that domain already trusts for sign-in; `draft-ietf-oauth-identity-assertion-authz-grant-04`, a working group document, read 25 October 2026	carries who the user is, and can carry structured authorization details; the readings stay out of it (8.1)
OAuth Transaction Tokens	a short-lived signed token that carries the user's identity, the workload's identity and the authorization context through a call chain inside one trust domain; `draft-ietf-oauth-transaction-tokens-11`, at working group consensus and awaiting its write-up, read 25 October 2026	carries who the work is for and what it may do along the call chain, with a fixed subject, and stops at its trust domain; the readings a hop adds travel beside it, not in its transaction context (8.1, figure 5)
RFC 8693 OAuth 2.0 Token Exchange	how a client asks an authorization server for a new security token in exchange for one it holds, including for delegation and impersonation; a Proposed Standard, read 25 October 2026	carries who acts for whom as a token is exchanged, which a record of delegation can cite; the readings stay out of the token, whose issuer is the authorization server and not the hop that holds the signal (8.1)
OAuth Identity and Authorization Chaining Across Domains	how identity and authorization cross trust domains: a token exchanged inside one domain for a grant the next domain's authorization server accepts, the same way at every boundary; `draft-ietf-oauth-identity-chaining-17`, in the RFC Editor's queue for publication as a Proposed Standard, read 25 October 2026	carries identity and authorization over each boundary the readings also cross; the readings cross beside it, signed as 3.4 says, because each new grant is issued by an authorization server and not by the hop that holds the signal (8.1)
IETF agent action records and audit-trail drafts	post-hoc records of what an agent did, in a transparency log or an audit trail	where readings land; the record carries the result, never the signal
W3C Data Privacy Vocabulary	role vocabulary	the source of the legal-term mapping in 2.1
LegalRuleML	how a rule names its jurisdiction	the vocabulary a rule reading the context would use
ISO 3166	country and subdivision codes	the base vocabulary

8.1 Why the readings are not in the authorization credential

A reader who builds identity and authorization systems will ask why the readings do not ride in a credential the work already carries: an access token, the authorization details an identity assertion grant can hold, or a Transaction Token's transaction context. Each is a natural home for a fact about who may do what. Each fails the requirements of the paper Whose law was that? for a fact about where each party is, and the table scores the credential against them in the order of the argument. R5 is not scored: where the evidence is held does not turn on the carrier.

Requirement	What the credential does	Why the readings cannot ride in it
R9	An access token, and the identity assertion it may be granted for, is issued for a session, and the claims it carries are fixed when it is issued.	The parties can change with every act: each site a subagent reads is a new counterparty, each model it calls a new provider. A value fixed at the start describes the parties to the first act at best.
R1	It names one subject, the party it was issued for.	Each party needs a reading of its own, and most parties to a piece of work are not the credential's subject.
R2	It is issued by an authorization server or an identity provider.	That issuer holds no signal for the subject, the counterparties or the providers. Rule 5 has a reading made where its signal exists, and the issuer would assert what it never observed.
R4	It fails closed: a request without a valid credential is refused.	The value unknown is permitted, and rule 6 forbids coercing it to a default. A reading the authorization step must accept or refuse turns an unknown into a refusal.
R3	It is a bearer credential, so it must never be logged.	The record keeps the result. A reading held only in a credential the record may not keep never reaches the record.
R8	It expires with its session, and it is kept out of every log.	Retention, access and location are settings of the record, made per jurisdiction. A reading that exists only in the credential is under none of them.
R6	A Transaction Token is typically minted when a request enters its trust domain and carried along its call chain, but its subject is fixed and it is not accepted outside the trust domain it was issued for.	Delegation crosses trust domains: a subagent at a provider, a site read on the principal's behalf. The token stops at the first boundary, where each hop beyond must still record the readings as given.
R7	A Transaction Token's transaction context is set by the token service and does not change along the call chain. A hop that needs another value can only ask the token service for a replacement token that adds it.	Inside a trust domain the context can carry the readings a hop received, but not those it adds under rule 4. Only the token service can add them, which makes it, and not the hop that holds the signal, the reading's issuer, against R2 as well.

Figure 5. Trust domains and legislation domains have the same shape and a different authority. A trust domain is drawn by the organization that runs it, and a Transaction Token stops at its edge; a legislation domain is drawn by a legislature, and its law reaches a party through where the party is. Neither contains the other. They touch at the operator, which runs a trust domain and is established in a legislation domain, and where a provider partitions its service by EU region. The parties stand outside every box, so the readings follow the parties across every boundary the token stops at.

9Open questions

These are the questions draft 2 puts to readers rather than answers. A reply to any of them is the most useful comment this document can receive.

The header name.
The frame of a response reading: the work's point of view, or the speaker's.
The party registry: whether five keys suffice, and how a sixth is registered.
Supranational codes beyond EU: a registry, or ISO.
The signature profile: the component set and key discovery.
Whether a baggage-only profile is enough inside OpenTelemetry deployments.
The neutral namespace for the Model Context Protocol's metadata key and the Agent2Agent extension URI.
Whether evidence commitments have a defined shape or stay opaque.
Whether a reading should reference a consent signal that arrived with the same work.
Where the proposal should live: the options, with their tradeoffs, are set out in Paths into standards, a companion options paper in this section.

10Status, how to take part, and disclosure

Status: Draft 2, 28 October 2026. Not yet before any standards body.
Comments: open@lexlint.io. There is no repository yet; one is opened the day a second organization wants to edit the text.
License: Creative Commons Attribution 4.0. Adopt it, fork it or improve it, with credit, without asking.
Disclosure: LexLint publishes a law library that could be one implementation of a vocabulary. The proposal does not depend on it, and LexLint will move to whatever the community decides.

About this proposalDraft 2, 28 October 2026ShowHide

Proposed by LexLint; written by Sean McDermott, Co-Founder and CEO, with AI assistance.

Draft 2 states the model, the bindings and the rules, says how they meet the nine requirements of the paper Whose law was that? and why the readings stay out of the authorization credential, and puts ten questions to readers. It adds section 7, section 8.1 and the four OAuth rows of section 8 to draft 1 of 9 October 2026, whose model, bindings and rules it keeps. The terms it uses for parties are plain legal roles; the mapping to the LexLint handbook's six groups is given once, in section 2.1, for readers arriving from there.

© 2026 UnGovr, publishing as LexLint. This proposal, its text and its figures, is licensed under Creative Commons Attribution 4.0: adopt it, adapt it, translate it, carry it into another document or a standards body, including commercially, with credit to LexLint (UnGovr). Logos and wordmarks belong to their owners.