Summary

  • draft-mcguinness-oauth-client-instance-id-00 lets an attester retain a scoped client_instance_id across a verified key change, but the stable value is credible only because an enrollment ledger records continuity, lifecycle and custody evidence.
  • Instance continuity, key-binding continuity, current attested state, Receiver trust, grant authority, downstream mapping and current presenter attribution are separate decisions.
  • A defensible receipt names the attester, enrollment, granularity, Receiver Scope, old and new keys, lifecycle event, evidence freshness, token mapping, Consumer Scope and sender proof without promoting the ID into authority or outcome.

The old public key is retired. A new attestation arrives with a new key and the same client_instance_id. The authorization server finds the identifier it suspended last week and applies the old decision to the new request.

That result feels obvious only because the hard decision happened somewhere else.

The new key contains no memory of the old one. The opaque identifier does not explain its scope, granularity or lifecycle. A matching string cannot show whether the software was updated in place, reinstalled, cloned, restored from a snapshot or replaced by another claimant. The continuity exists because a Client Attester says that the new claimant succeeds the prior enrolled instance and has records supporting that statement.

Revision 00 of draft-mcguinness-oauth-client-instance-id, published 28 September 2026, makes this dependence unusually visible. It is an individual Standards Track Internet-Draft, not an OAuth Working Group document or RFC. It replaces a separate client-instance assertion design. The related base attestation specification is WG work in Last Call, but that status does not adopt this profile. There is no implementation, interoperability or deployment result in the frozen evidence.

A current key cannot prove a continuous instance

The base attestation mechanism asks whether an authorized Client Instance possesses a particular key. The profile adds a different question: is this the same instance the Receiver encountered before? The draft explains why another valid attestation cannot settle it. Every new key needs fresh attestation, and after rotation a continuing installation can otherwise look identical to a new installation.

The proposed client_instance_id gives the Receiver a stable handle. Its authority is the attester issuer, so the actual Source Instance Identity is the pair (iss, client_instance_id), not the identifier alone. The Logical Client identified by client_id is wider: many laptops, containers or agent runtimes may authenticate as instances of one Logical Client. The authorization principal is different again.

This separation prevents an attractive mistake. Authentication of one key is a present-tense possession fact. Instance continuity is a historical succession claim. Authorization is a local decision about what that recognized instance may do. A successful operation is an observed outcome. One credential should not be made to answer all four.

The identifier is the label; enrollment is the evidence

The draft requires identifiers to be opaque, unpredictable, distinct and never reassigned, even after retirement. They cannot embed a hostname, user identifier or instance attribute. A URI-shaped value carries no URI semantics. Receivers compare exact strings and must not infer permissions, granularity or key location by parsing them.

Those rules make the label safer, but they do not create continuity. The attester must maintain an active enrollment that binds the instance, Logical Client, Receiver Scope, granularity and previously verified keys. When the key changes, it verifies fresh possession and authenticated evidence of an authorized custody transition. It records continuity checks, freshness and lifecycle observations.

The state transition matters more than the string. Renewal, verified rotation, an installation-level process restart or in-place update may retain the identifier. Reinstallation, an independent clone, replacement, an execution-level restart or a granularity change requires new enrollment. A restored snapshot retains identity only with fresh evidence that its claimant succeeds the former holder; copied keys and data alone do not suffice. A detected fork requires retirement or separate enrollment unless evidence identifies the continuing holder.

The product therefore is not “persistent ID.” It is a governed enrollment state machine. If the continuity records are deleted, the draft requires new enrollment. If the derivation secret changes, already assigned values must still be reproducible. A platform-stable input cannot be used alone because it could recreate a retired identifier after reinstall.

Receiver Scope is real even though the Receiver cannot see it

The identifier is scoped by default to one Receiver. Yet Receiver Scope is an enrollment or issuance input, not an OAuth parameter or attestation audience. The Receiver cannot verify the intended scope from the identifier.

This is a profound operational boundary. The attester must issue distinct IDs per Receiver unless an administrative agreement creates an explicitly shared scope. A shared client or trust domain is not enough. The client must also use distinct Client Instance Keys across scopes that the deployment means to separate, because a shared key links the instances even when identifiers differ.

If the client presents a scoped attestation to the wrong Receiver, that Receiver cannot detect the scope violation from the ID. The resulting correlation can expose the end user. Enforcement therefore depends on the client and attester following configuration that is not self-describing in the artifact.

The receipt needs the configured scope and policy version, not merely the ID. It also needs a statement of which system was responsible for enforcing that scope. Otherwise a post-incident reviewer sees identical syntax without knowing whether the trust agreement was honored.

Attester authority is another configured association

The Receiver must bind an approved Attester Issuer to validation keys and authorized Logical Clients. A claimed iss, possession proof or client-published metadata does not establish that authority. Client Attester Endorsement can supply one input for authorization servers, but resource servers validating directly still need configured associations.

This keeps two approvals apart. The attester says “this is the same enrolled instance.” The Receiver decides whether that attester may speak for this Logical Client under this policy. A correct signature from an unapproved issuer is not continuity evidence for the Receiver. Conversely, a configured issuer can still be compromised or overstate the assurance of its evidence.

The draft acknowledges the consequence. A compromised attester can impersonate instances within its approved associations. Self-reported, platform-verified and hardware-rooted evidence are not interchangeable. When copied keys and enrollment state cannot be distinguished from the original without independent platform evidence, the profile cannot manufacture clone detection.

Identity continuity does not move the refresh-token key

The profile records an identity that persists across verified key change. It does not automatically rebind an existing refresh token. Default refresh-token binding remains attached to the original Client Instance Key unless a separate authorized profile changes that rule.

On refresh, the authorization server must check two invariants independently: the new attestation's Source Instance Identity matches the recorded identity, and the proof/key binding satisfies the base mechanism or an authorized rebinding profile. The first says the historical instance matches. The second says the current request possesses the key that this grant accepts.

This is a useful model beyond OAuth. Stable subject identity and credential continuity are related but different. Operators frequently preserve a database row, rotate a certificate and assume the old authorization moved with it. The safer question is: which decision authorized the credential transition for this grant, under which policy, and what evidence proves possession now?

Suspension has several clocks

An attester must stop issuing for a suspended or retired enrollment. An authorization server suspending an instance should revoke its grants or make tokens inactive. But the system is not instantly consistent.

An attestation issued before suspension can remain acceptable until expiration and clock skew. An access token can survive for its own lifetime. A local revocation does not notify an offline resource server. Status distribution is outside the profile. Re-enrollment or a different Receiver Scope can create a new identity that a Receiver cannot correlate with the suspended one.

Containment therefore has a time budget and an admission boundary. A Receiver that treats suspension as durable control may need prior enrollment, coordination with the attester over replacement enrollment and explicit revocation distribution. “Suspended” without its authority, effective time, affected enrollment, token set and notification coverage is only a local row.

Downstream context creates a second identity authority

The optional client_instance object lets a token issuer convey validated instance context to a resource server. It is not necessarily the attester's raw ID. The token issuer maps the Source Instance Identity into its own (iss, id) namespace for a Consumer Scope selected from the token audience.

The mapping has its own continuity obligations. It must keep distinct instances separate, remain stable across attestation renewal and verified rotation, and survive while relevant grants or tokens remain valid. If the issuer can no longer reproduce it, the context must be omitted rather than silently replaced. A token with no audience or audiences spanning Consumer Scopes has no single correct mapping and must omit it. An introspection caller outside the scope must not receive it.

The system now contains two ledgers: the attester's enrollment-to-Source-Identity ledger and the token issuer's source-to-consumer mapping ledger. Their authorities and retention periods differ. Losing either can turn a policy-enforced request into missing context, but inventing a replacement would falsely merge or split history.

Participation at issuance is not the current presenter

Instance Context grants no authority. By itself it says only that the named instance participated in obtaining the token. It does not prove that the current HTTP request came from that instance.

Presenter attribution needs sender constraint: DPoP, mutual TLS or another mechanism defined by a consuming profile, using a key associated with the instance at issuance. A shared binding key establishes no individual attribution. A bearer token without sender constraint cannot support the claim. If attribution is required and the issuer cannot provide the binding, it must omit context and the consumer must reject when context is mandatory.

Token exchange makes provenance harder. Validating the input token authenticates that token issuer's assertions, not every upstream authority named inside. A consuming profile must define whether context represents the current presenting instance or an upstream instance, how the association is authenticated, and when identifiers are remapped, preserved or omitted. The context is one instance reference, not an actor chain or delegated token.

This is the difference between an issuance receipt and an execution receipt. The token can accurately preserve who helped obtain it while another process later presents it. Only the sender proof closes that new edge, and even then it does not prove the resource server authorized or executed the requested action.

Privacy is a choice among observers

Pairwise Receiver identifiers reduce correlation between Receivers, but the attester learns the Receiver Scope supplied during enrollment or issuance. A single scope spanning many Receivers hides the individual destination from the attester only by allowing those Receivers to correlate the instance.

Distinct instance IDs are not sufficient if token-binding keys are reused. Different Consumer Scopes can carry different mapped IDs while the same DPoP thumbprint links them. Other claims and application data can do the same. Privacy therefore requires coordinated separation of identifiers, instance keys, sender-constraining keys and payload data.

There is no universally private setting. The question is which observer may correlate what, for how long and for which operational purpose. That decision belongs in the deployment contract and its receipt.

The continuity receipt

A practical receipt begins with authority: attester issuer, validation key, Logical Client, Receiver trust-policy version and enrollment identifier. It records configured granularity and Receiver Scope without exposing unnecessary user attributes.

For each transition it links the previous and current key fingerprints, lifecycle event, custody evidence, continuity checks, evidence freshness, decision time and outcome: retained, new enrollment, retired, suspended or forked. It records outstanding attestation and token lifetimes so containment windows are visible.

For grants it records Source Instance Identity separately from key binding and any authorized rebinding profile. For downstream use it records token issuer, mapping input, mapped Instance Context, Consumer Scope, audience, mapping-retention epoch and preservation/remapping provenance. For each request it records sender constraint and the resource server's local authorization decision.

Finally it links the protected operation and observed result. That last edge prevents the elegant identity system from claiming an outcome it never saw.