Summary

  • An individual Internet-Draft first submitted on 28 September proposes client_instance_id, an attester-assigned identifier that may persist across a verified client key change. It is not an RFC, IETF endorsement or evidence of deployment.
  • The proposal does not rebind an existing key-bound refresh token. With the base authentication draft's default binding, a refresh made with the new key fails even if the attester correctly recognizes the same instance, unless a separate eligible profile has changed that binding.
  • A server using the proposed profile must also compare a current validated attestation with the Source Instance Identity recorded for the grant. An identity match and a valid token/key-binding proof are independent conditions.

The rotation that should not silently renew access

Imagine a mobile client replacing its instance key after routine rotation. The attester has evidence that the replacement belongs to the same enrolled installation. Its new attestation carries the same opaque client_instance_id. The authorization server sees an old refresh token and a new proof. A tempting implementation shortcut is to treat the familiar instance identifier as permission to continue the old grant. K. McGuinness's new individual draft rejects that shortcut in §5.1: the identity profile establishes a continuity claim, not a new token-binding or grant rule.

The base OAuth attestation-based client authentication draft binds a refresh token to a Client Instance Key by default. Under that rule, changing the key changes the proof the old token expects. The new identity proposal expressly says it does not rebind the token or add instance-bound grants. A refresh attempted with the new key therefore fails the default key-binding check, even when the new attestation's instance identifier is the same. A separately applicable profile could define different binding behavior; client_instance_id alone does not.

This is not a failure of the attester's continuity check. It is a refusal to confuse two records. One record asks whether the new key belongs to the same enrolled client instance. The other asks whether the presented refresh token is usable with that key under the binding rule that actually issued it. If a server substitutes the first answer for the second, an identity label has been promoted into authority without a rule authorizing the promotion.

What the identifier can and cannot carry

The proposal's identifier is attester-assigned, opaque, unpredictable and not to be reassigned. Its default scope is a Receiver, rather than a universal ID shared across every authorization server. The attester is meant to keep it over authenticated key changes for the same enrollment. A reinstall, independent clone or new execution unit instead requires new enrollment; a copied key, copied data or previously seen identifier is not evidence by itself that the same installation continues. A restored snapshot needs fresh authenticated evidence of a successor.

Those lifecycle conditions matter because a stable label with a weak successor test would be a convenient name for a copied client.

The draft also stops short of treating the identifier as a user or actor. It says instance identity is not authorization, cannot set a sub or extend an act chain solely from the attestation, and does not replace proof of possession. Its optional client_instance token or introspection context would give a resource server a distinct way to observe which client installation is involved; it is not a license to infer the human subject or widen a grant. A Receiver-scoped value reduces unnecessary correlation, but only if scope and key separation are actually preserved. Operators should not market the proposal as a universal persistent device identity.

For grants established using this profile, §5.1 introduces another explicit check: the authorization server records the Source Instance Identity and, on refresh, validates a current attestation and compares its instance identity with that record. A mismatch is a rejection signal. A match is still not proof that a key-bound refresh token has survived rotation. The key-binding verdict remains a separate gate. This detail is the news in the proposal: it describes a path to recognize an installation without quietly migrating every outstanding credential to a replacement key.

The Datatracker entry currently lists a first -00 individual Internet-Draft with IESG state I-D Exists. “Standards Track” in its header is intended status, not approval. There are no measured deployments, interoperability results or incident reports in the cited primary record. Operational consequences here are analysis of a proposal, not findings about systems already running it.

Sources