| Internet-Draft | PQ Agent Identity | September 2026 |
| Uppalapati | Expires 1 April 2027 | [Page] |
A delegation record retained as evidence must remain verifiable long after the key that signed it is retired. A signature of any algorithm establishes who signed, not when, so such a record needs anchoring in trusted time, renewed before the algorithms protecting it weaken. That is long-settled practice for archived signatures. It is rarely required for agent delegation, and where it is, the anchor is not itself required to be post-quantum. An anchor is only as good as the protection behind it, and an RFC 3161 timestamp is itself a signature: an adversary holding a cryptanalytically relevant quantum computer can mint one bearing any date it chooses. Because such a machine may be built without announcement, anchoring must become post-quantum anchoring by a stated transition date, and be applied early, so that the only assumption left about when such a machine appeared is that none existed before a record was first anchored that way. The earlier that date, the weaker the assumption, which makes choosing it a security decision and not only a scheduling one.¶
This document states requirements that software and AI agent identity mechanisms should satisfy in order to remain sound across the transition, and identifies four that no such mechanism yet imposes on delegation credentials in general. The algorithms binding each hop of a delegation chain to its trust anchor must be visible to a verifier and retained with any record kept as evidence; where a signing key is fetched from a key set over TLS, as OAuth deployments commonly do, that binding is rarely recorded and no mechanism for agent delegation requires it to be, so in practice it is absent. Trust anchors must migrate before the credentials issued under them. Every retained record must be anchored, that anchoring must become post-quantum anchoring from a stated transition date and be maintained by renewal, and credentials of any type kept as evidence must be signed post-quantum from that same date. Delegation chains also propagate the weakest algorithm in the chain, and routinely cross organizational boundaries where no common trust anchor policy can be assumed.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The identity and authorization model for autonomous software agents is under active design. The NIST National Cybersecurity Center of Excellence has published a concept paper [NCCOE-AGENT] proposing to apply existing identity standards to agentic architectures. The Model Context Protocol relies on OAuth 2.1 [I-D.ietf-oauth-v2-1] for authorization [MCP-AUTH]. [NCCOE-AGENT] names SPIFFE and SPIRE as candidate mechanisms for issuing cryptographic identities to agent workloads. Scoped delegation between agents is being built on OAuth 2.0 Token Exchange [RFC8693].¶
Every one of these rests, in its common deployments, on classical digital signatures.¶
This is not an oversight peculiar to any one effort; it is the natural result of reusing mature identity infrastructure, which is exactly what these efforts were correct to do. But it produces a specific and avoidable outcome: an identity substrate designed during the post-quantum transition, with no requirement that it survive the transition.¶
[NCCOE-AGENT] does not mention post-quantum cryptography or cryptographic agility. It asks how key management for agents should handle issuance, update, and revocation, and it asks how non-repudiation for agent actions can be bound back to human authorization. Both questions have post-quantum answers that the document does not reach.¶
This document does not propose a new identity architecture. Its central claim is about records rather than algorithms: a delegation record kept as evidence must be anchored in trusted time and that anchoring maintained, because a signature establishes who signed and never when. That is settled practice for archived signatures and it has not reached agent delegation. Post-quantum signatures matter to it in a specific way, since an RFC 3161 timestamp is itself a signature and a cryptanalytically relevant quantum computer may be built without announcement, so the anchoring must become post-quantum too, by a date each specification states, and be applied early enough that the assumption it rests on is one the deployment controls. Around that claim the document states what an algorithm agility requirement needs to contain to be sufficient.¶
One of those requirements is not required by any current mechanism for agent delegation or OAuth key distribution, and so in practice is absent. Where a verifier obtains a signing key from a key set fetched over TLS, nothing records which algorithms bound that key to a trust anchor. Section 3 states that gap first, before the survey and the argument, because it is the one most easily missed.¶
Stating requirements rather than mechanisms is deliberate, because the mechanisms are not what is missing. [I-D.sharif-apki-agent-pki] defines a certificate hierarchy for agents, names its root as the trust anchor, and requires that certificates support migration to post-quantum algorithms, with a phased move to composite and then to ML-DSA-65 or SLH-DSA. It does not require that the root migrate before the certificates issued beneath it. The hierarchy, the migration path, and the algorithms are all present; the ordering constraint that makes them add up to post-quantum security is not. That pattern, a capable mechanism with an unstated constraint, is what this document addresses.¶
In scope: requirements on credential formats, delegation chain construction, trust anchor migration order, and verifier behavior, for identities asserted by or on behalf of software and AI agents.¶
Out of scope: the choice of any particular post-quantum algorithm; the design of agent orchestration or policy systems; confidentiality of agent traffic, which is the ordinary key establishment migration and is adequately addressed elsewhere.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A software system that takes action toward a goal with limited human supervision, on behalf of a principal.¶
The ordered sequence of authority transfers from an originating principal, through one or more agents, to the party performing an action. Each transfer is a hop.¶
A credential whose verification may be relied upon after the moment of use, as evidence that a particular principal authorized a particular action. The term "non-repudiation" is retained here because [NCCOE-AGENT] poses its question in those words. It is used in the narrow technical sense of an assertion about the past remaining verifiable, and not in the broader legal sense; [RFC4949] discusses that wider ambiguity.¶
A timestamp or evidence record whose signature and validation path use only post-quantum or PQ/T hybrid algorithms, or a publicly witnessed hash commitment. A PQ/T hybrid counts only where verifier policy under PQ-R5 requires its post-quantum component to verify.¶
A commitment held, from a stated time, by a number of independent parties that the specification sets, whose copies reach the relying party authenticated by each holder's post-quantum signature, or were obtained by the relying party before the cut-off applicable under PQ-R7(e), in which case the commitment rests also on no CRQC having existed when they were obtained. Its evidential value rests on the collision and second-preimage resistance of a hash with at least 256-bit output, on at least the stated number of holders being consulted and fewer than that number colluding, and on the copies remaining available. Witness cosignatures under classical algorithms do not count toward it.¶
The signature algorithm used at a hop, together with every algorithm on the path binding that hop's signing key to a trust anchor. Where a key is retrieved rather than certified, as from a key set over TLS, the algorithms securing that retrieval form part of the profile.¶
A cryptanalytically relevant quantum computer; one capable of breaking the public key algorithms in current use.¶
Of the requirements in Section 7, one is not required by any current mechanism for agent delegation or for OAuth key distribution, and so in practice is absent from the most widely deployed arrangement for agent authorization. It is required elsewhere: the long-term validation profiles of [JADES] oblige a signature to embed its certificate and revocation values. That is stated here, ahead of the survey and the argument, because it is the gap most easily missed: the practice exists, each piece is available, and nothing in this space requires them together.¶
A verifier checking a signed credential needs the signing key. Where the key is carried by a certificate, as in the X.509-SVID case of Section 4.2, the certification path is part of what it received: the algorithms binding that key to a trust anchor are visible, and a party retaining the record can retain them with it. Where the key is fetched from a key set URL over TLS at verification time, as OAuth deployments commonly do, none of that holds. The binding between key and anchor is the Web PKI of a live connection. It is not carried in the credential, it is not written down, and it is gone once the connection closes.¶
The consequence is not a weakness in the moment of use. TLS authenticated the key set when it was fetched, and a verifier acting then has what it needs. The consequence is archival: an auditor reading the record in 2040 cannot establish which algorithms protected that key in 2026. The certificates have expired, the intermediates have rotated, and nothing recorded which ones were presented. A record whose signature verifies against a key of unknown provenance does not establish what it appears to establish.¶
Mechanisms that could carry the binding exist. A certificate chain may travel in the "x5c" header of a JWS ([RFC7515], Section 4.1.6); OpenID Federation publishes signed trust chains; authorization server metadata may be signed ([RFC8414]); a key set may itself be signed. What none of them does is require that the binding be captured at issuance and retained alongside the record. Each is available and each is optional, so in the general case it is absent.¶
Two routes close the gap, and PQ-R7(c) accepts only these. The binding may be carried in a form that is itself signed under a post-quantum validation path, by any of the mechanisms just named. Alternatively, where the key set is available only over a connection authenticated by a quantum-vulnerable signature, the party that retains the record anchors the key set it fetched, together with the transport chain that authenticated it, alongside the record; its soundness then rests on the assumption stated in PQ-R2 for records received from another party. An issuer's own assertion about the algorithms securing its own key is not a third route: it is only as trustworthy as the binding in question.¶
The second route rests on trusting the party that retains the record. TLS authenticates a server to the client that connected to it; it produces no artifact a third party can later check, so a retaining party could pair any key set with a genuine transport chain and nothing in the archive would show it. Where the retaining party is also the relying party this is acceptable, because it is only deceiving itself. Where the record is to be shown to someone else, only the first route gives evidence that stands on its own.¶
Nothing here is unbuildable. A certificate chain in "x5c" carries it. [OIDFED] trust chains together with signed key sets carry it, and fit the first route where the signatures on them are post-quantum. Signed authorization server metadata [RFC8414] helps less than it appears to, since it binds the key set URL rather than the keys themselves. The finding is narrower and more mundane: no specification for agent delegation requires any of this, so in the general case it is not there. Naming that is the point; specifying a mechanism is not attempted here.¶
OAuth is the primary authorization mechanism for agentic tool access, and is integrated into the Model Context Protocol for that purpose. Authority is commonly conveyed in JWTs, signed using the JWS algorithms of [RFC7515] and [RFC7518]; OAuth [I-D.ietf-oauth-v2-1] does not itself require a signed token format, but the agent deployments considered here use one. The registered algorithms in general deployment (RS256, ES256, and EdDSA [RFC8037]) are all quantum-vulnerable. [RFC9864] requires fully specified algorithm identifiers in JOSE and COSE, which is a precondition for the agility and downgrade requirements of Section 7.¶
Delegation across agent hops is expressed with Token Exchange [RFC8693], which produces a new token at each hop. Each such token is independently signed.¶
An X.509-SVID [X509-SVID] is an X.509 certificate carrying a SPIFFE ID in the subject alternative name. Its signature, and the signatures on its issuing chain, use classical algorithms in every current deployment.¶
SPIFFE's short credential lifetimes genuinely do make leaf migration easier than in conventional PKI. This document notes in Section 6.4 why that advantage does not extend to the trust anchors, which is where the harder problem sits.¶
The WIMSE working group now has a working group document on agent identity. [I-D.ietf-wimse-aims] describes an identity management system for AI agents, composing existing identity, authorization, and workload standards rather than defining new protocols. It names no signature algorithm, and it does not discuss post-quantum cryptography or algorithm agility. It is the clearest current example of the pattern this document is concerned with: an actively developed agent identity architecture in which algorithm strength is not yet a design parameter.¶
Individual submissions in the same space show the same pattern. They address delegation chains ([I-D.asor-wimse-agent-delegation-chain], [I-D.atakora-wimse-sadp-delegation]) and audit records for agent authorization decisions ([I-D.gilda-wimse-agent-audit-record]); the last is the natural home for the retention requirement of PQ-R7, although it currently scopes retention out, and names [RFC3161] as one of three permitted external time anchors without requiring any particular one.¶
[I-D.reece-wimse-cross-org-delegation] states the problem of delegation across organizational boundaries and enumerates requirements that a solution should satisfy. It states that it "does not select among credential formats, signature schemes, or policy languages", which is an appropriate scope for a problem statement. Its Security Considerations nonetheless record the concern directly:¶
Where authority is long-lived, or where audit records must remain verifiable over a multi-year retention period, the long-term resistance of the chosen cryptographic mechanisms, including under a future quantum-capable adversary, is a consideration for any solution; data and signatures recorded today may need to remain unforgeable for the lifetime of the audit obligation.¶
The gap is therefore already visible from inside the work in progress. It has been named as a consideration and left open, which is the correct outcome for a document that excludes algorithm selection from its scope. What is missing is a statement of what long-term resistance has to mean for a delegation chain in order to be checkable by a verifier. That is what Section 7 supplies. It is intended to be usable by any of these efforts, or by a successor to them, without constraining the rest of their design.¶
It is important to be precise about the gap, because the serialization work is largely done:¶
ML-DSA for JOSE and COSE is specified in [RFC9964], a published standards-track RFC.¶
PQ/T hybrid composite signatures for JOSE and COSE are specified in [I-D.ietf-jose-pq-composite-sigs], combining ML-DSA with ECDSA or EdDSA. The terminology of PQ/T hybrid schemes is given in [RFC9794].¶
SLH-DSA for JOSE and COSE is specified in [I-D.ietf-cose-sphincs-plus]. An FN-DSA serialization was drafted in [I-D.ietf-cose-falcon], which has since expired, and the FN-DSA standard has not been published.¶
For X.509, ML-DSA algorithm identifiers are specified in [RFC9881] and composite ML-DSA in [I-D.ietf-lamps-pq-composite-sigs], now in the RFC Editor queue, so the X.509-SVID path is served as well as the token path.¶
The gap is therefore not that post-quantum signatures are unavailable to token formats, and it is no longer that no agent delegation work requires agility. [I-D.asor-wimse-agent-delegation-chain] requires fully specified algorithms, cites [RFC9964] as the post-quantum migration path, and binds each delegation token to its parent by a digest over the parent's JWS signing input, which is the chain-position binding property of Section 8.¶
The claim of this document is correspondingly narrower, and each gap below names the requirement that closes it.¶
First, where a mandatory floor is stated it is usually classical: where Ed25519 is mandatory to implement and ML-DSA is optional, a fully conforming deployment may be entirely quantum-vulnerable, and the weakest-hop argument of Section 6.1 applies unchanged. There are exceptions: [I-D.marques-asqav-compliance-receipts] requires that new issuance under its revision use ML-DSA-65 outright, and [I-D.fane-opena2a-aip] requires a verifier to check an ML-DSA-65 signature where the credential declares one, though that is conditional and hybrid alongside Ed25519. [I-D.mcgraw-httpapi-agent-budget] requires the issuer signature on its delegated-authority attestations to use ML-DSA, with ML-DSA-65 mandatory to implement. None of these is the common case, and a deployment conforming to the more typical profiles can still be entirely classical. PQ-R2 closes that: it requires, from a transition date each specification states, post-quantum signing for any credential type kept as evidence.¶
Second, per-hop agility does not give a verifier the algorithm strength of the chain as a whole; see Section 6.1 for the one mechanism that does evaluate the chain, and for what it still leaves open. That is PQ-R6.¶
Third, no agent identity work known to the author requires the order in which trust anchors migrate relative to the credentials they issue. [I-D.sharif-apki-agent-pki] is the clearest case: it defines an Agent Root CA as the trust anchor for its hierarchy and requires that certificates "support migration to post-quantum algorithms", and RECOMMENDS a phased move to composite and then to ML-DSA-65 or SLH-DSA, but it does not require that the root migrate before the certificates beneath it. That trust anchors must migrate first is not a novel observation; it follows from how certificate chains are validated, and [RFC9958] treats trust anchors as part of the signature migration. The mechanics of root re-keying are an active subject, with individual submissions before LAMPS ([I-D.wang-lamps-root-ca-cert-rekeying]). That is PQ-R4.¶
Fourth, no agent identity work known to the author requires that a retained delegation record remain verifiable for a stated period. [I-D.sharif-agent-audit-trail] is the closest: it sets retention periods, at SHOULD level, of twelve months for high-risk systems and six otherwise, and recommends post-quantum signatures where records must outlive classical ones. What it does not require is that a record remain cryptographically verifiable across the period it sets. That is PQ-R7.¶
The classical mandatory floor is not peculiar to one draft. [I-D.ietf-wimse-workload-creds], a working group document, requires that general purpose implementations support ES256 and says nothing about post-quantum migration, and [I-D.atakora-wimse-sadp-delegation] is Ed25519 only. Where individual submissions do provide for post-quantum issuance, they address issuance alone and do not reach PQ-R4, PQ-R6, or PQ-R7; [I-D.burls-mtac], which issues agent certificates under a single ML-DSA signature over a Merkle tree head, and [I-D.ihsanullah-dnsid], which states that implementations SHOULD add ML-DSA once post-quantum algorithms are registered for use with JWS, a condition [RFC9964] has since met, are both representative.¶
Implementation status appears to point the same way, though the author has not surveyed it systematically and claims no exhaustive view. Post-quantum credential issuance is not yet a prominent documented configuration in workload identity software, although the serializations such implementations would need have been specified for some time. Work is under way: at the time of writing the SPIFFE project has an open pull request adding the ML-DSA algorithms of [RFC9964] to JWT SVIDs and to the Workload Identity Token [SPIFFE-MLDSA-PR], and SPIRE has an open issue tracking post-quantum support [SPIRE-PQC-ISSUE]. Both were open rather than released when this was written. This is offered as an observation about sequencing rather than a criticism of any project: implementations reasonably follow requirements, and the requirement has not been stated.¶
The initial public draft of [IR8547] proposes the technical schedule: 112-bit algorithms deprecated after 2030, and all quantum-vulnerable public key algorithms, including RSA-3072, P-256, and P-384, disallowed after 2035. That document is not final and its dates may move.¶
[EO14412], Section 4(b), directs the issue of guidance requiring federal agencies to transition high-value assets and high-impact systems to post-quantum key establishment by 31 December 2030 and to post-quantum digital signatures by 31 December 2031. [M-26-15] is that guidance, placing signatures in a 2031 phase; the specific date is the Executive Order's. The one-year gap between the two reflects a judgment Section 6.2 examines. National security systems are excluded and gated earlier: newly acquired systems are expected to be CNSA 2.0 compliant [CNSA2] from 1 January 2027, so an agent identity mechanism intended for that market is constrained at procurement.¶
These are United States instruments, used here because they are the most precisely dated rather than because the problem is national. The European Union's roadmap [EU-PQC-ROADMAP] sets end-2030 for high-risk use cases and end-2035 for the remainder so far as practicable, and the United Kingdom NCSC [UK-NCSC-PQC] sets milestones at 2028, 2031, and 2035.¶
These dates bound how long classical algorithms remain permitted, not when a CRQC might appear. They serve in this document as the ceiling for the transition date that PQ-R2 and PQ-R7 require a specification to state.¶
Three observations follow.¶
First, for United States federal high-value assets and high-impact systems the operative date is 2031 rather than 2035, because agent identity is a signature problem; the confidentiality of agent traffic is the ordinary key establishment migration and is out of scope here. The 2035 disallowance remains the outer bound for the algorithms themselves, and Section 6.2 uses it in that sense. Procurement and audit obligations attach at the earlier date, and agent identity infrastructure designed today will be procured into environments already subject to them.¶
Second, and more consequentially, the federal timeline places signatures a full year after key establishment. That ordering is not arbitrary: it encodes the conventional judgment that signature migration is the less urgent half, because a signature verified live cannot usefully be forged after the fact. Section 6.2 argues that this judgment, correct for live authentication, leaves out what a record retained as evidence needs, which is anchoring in trusted time rather than a stronger signature alone. For such records 2031 is the date after which quantum-vulnerable signatures stop being issued. It is not the date after which they stop being relied upon, and a record signed before it must remain verifiable, by whatever means, long after it.¶
Third, identity infrastructure has among the longest replacement cycles of any security infrastructure. The Web PKI's migration away from SHA-1 (a substantially simpler change, affecting a single hash function, with a coordinating forum and a small number of decisive implementers) nonetheless ran for years between the first serious deprecation decisions and full distrust. Agent identity has none of those advantages and a deadline already inside that historical window.¶
The general post-quantum transition is well understood and broadly underway. Four properties distinguish agent identity from an ordinary PKI migration.¶
An agent action is authorized not by a single credential but by a chain: an originating human principal, one or more agents, possibly a sub-agent, and finally the tool or resource that acts. Each hop mints a credential. Chains are dynamic, and their length is not known when policy is written.¶
A chain's authority claim is only as strong as its weakest hop. Incremental migration guarantees mixed-algorithm chains as the normal steady state for years: a post-quantum credential at hop three, chained under a classical credential at hop one, provides classical security overall.¶
This is recognized inside the WIMSE work. [I-D.reddy-wimse-aggregate-signatures] states it directly: "A chain is only as strong as the weakest algorithm in it, whether the hops sign individually or their signatures are aggregated", and observes that because the algorithm each hop uses is carried in that hop's token, "a verifier learns what was used but not what should have been used". It gives the post-quantum downgrade case and makes verifier policy the remedy.¶
That draft does evaluate the chain as a whole. Each hop's signature input is retained, so the destination verifier obtains every hop's public key and algorithm and applies its policy to each, and the draft also presents the chain as a signed record for audit, of which workloads participated and whether each changed the message. Three things distinguish the requirement stated here. First, it is a requirement on delegation credentials in general rather than a profile of HTTP message signatures, so a chain built with Token Exchange [RFC8693] alone, which carries no algorithm information about prior hops at all, does not meet it unless the token service asserts the profiles it accepted, as PQ-R6's authorization form (Section 7) allows and Appendix A illustrates. Second, it covers the algorithms binding each hop's key to its trust anchor, not only those signing each hop. Third, it is stated alongside requirements on anchor migration order and on the period over which a retained record must remain verifiable, which that draft does not address.¶
Mechanisms to carry more than the per-token alg header do exist. A JWS may
carry the signer's certificate chain in the x5c header ([RFC7515],
Section 4.1.6), and federation profiles retain signed trust chains. What none
of them requires is that the binding be captured at issuance, so in the
general case a verifier that sees only the credential presented to it cannot
answer the question a policy engine actually needs answered: what is the
weakest algorithm anywhere in the authority chain behind this request, and in
the chain of trust anchors behind that?¶
This is a requirement gap, not merely an implementation gap.¶
This is the central argument of this document. The observation itself is not new: [I-D.bezerra-anchors-command-provenance] makes it directly, noting that records signed with ECDSA or EdDSA "become forgeable when a cryptographically relevant quantum computer exists" and that "evidence whose integrity guarantee expires before the statute of limitations is structurally inadequate". That document uses the observation to motivate a provenance mechanism of its own. What follows here turns it into requirements on delegation chains generally.¶
Conventional guidance holds that signature migration is less urgent than key establishment migration. Confidentiality is subject to harvest-now-decrypt-later: traffic recorded today is decrypted once a CRQC exists. Authentication is not, because a signature verified live, using a key retired before a CRQC exists, cannot be usefully forged after the fact. The handshake is over.¶
That reasoning is correct for live authentication. It does not hold for a record kept as evidence, and the remedy is not only a stronger signature.¶
The NCCoE concept paper asks explicitly how to ensure non-repudiation for agent actions and bind them back to human authorization. Non-repudiation is by construction a property asserted about the past: an audit record stating that a particular human authorized a particular agent action must remain trustworthy for as long as the record matters, which for regulated activity is commonly seven years or more, and for some liability regimes is indefinite.¶
One qualification belongs here rather than in the security considerations. In the common OAuth arrangement the authorization server signs the token, not the principal. The signature establishes that the server asserted the authorization, not that the human performed it, and the binding back to the human rests on what the server recorded at the time and on the server's continued integrity. The argument below is therefore about the evidentiary value of the server's assertion, which is what an auditor actually holds. A deployment needing the stronger property, a signature made under the principal's own key, has a different and harder problem that this document does not address.¶
If that record's trustworthiness rests on verifying a classical signature, then once a CRQC exists that signature no longer distinguishes the issuer from anyone else. The issuer can disclaim the record, and a verifier has no cryptographic basis on which to contradict them. This requires no access to the evidence store; it follows from the algorithm alone. The consequence is not limited to records created after that day: every delegation record that was never anchored in trusted time becomes repudiable simultaneously.¶
Anchoring is what answers this, and it is not a post-quantum technique. A signature establishes who signed, never when, so a signer may always claim the key was compromised before the event. [RFC3161] states the remedy in its Section 1: a timestamp can be used "to verify that a digital signature was applied to a message before the corresponding certificate was revoked thus allowing a revoked public key certificate to be used for verifying signatures created prior to the time of revocation". [RFC4810] takes as its premise that the lifetime of signed data exceeds the cryptanalysis period of the algorithms protecting it, and [RFC4998] defines how the protection is renewed as those algorithms weaken. Agent delegation work has begun to require anchoring: [I-D.nelson-agent-delegation-receipts] provides that no agent action may begin until a log anchor is confirmed. It specifies no post-quantum algorithm: it recommends Ed25519, requires ECDSA P-256 on root receipts, and leaves post-quantum migration to the authenticator layer. That is the pattern this document addresses: the anchoring is required, the strength of the anchor is not. An unanchored signature, of any algorithm, has no such protection at all.¶
Anchoring in trusted time supplies the when, but an anchor is only as trustworthy as the protection behind it, and an [RFC3161] timestamp is itself a signature: an adversary holding a CRQC can mint a classical timestamp bearing any date it chooses, over a record it forged. Because such a machine may be built without announcement, no relying party can know that one does not already exist.¶
The only assumption this document requires about when a CRQC appeared is that none existed before the moment a record first received post-quantum anchoring. During the transition that moment is no later than the transition date the specification states, so an earlier date is a weaker assumption and choosing it is a security decision rather than only a scheduling one. The moment is set by the deployment's own actions, not predicted, and this document requires that it be as early as possible: from the transition date, within a short stated interval of issuance for records the deployment issues, or of receipt for records it receives; before that date, no later than the transition date itself under PQ-R7(b). For records received from another party the bound is instead the receipt cut-off stated under PQ-R2, which a specification may set no later than the transition date. The record's soundness also rests, as for any evidence record, on the algorithms and hash protecting it not being broken before independent protection is added, and on the honesty and key security of the timestamping authority or witnesses.¶
For a classically signed record received from another party, that assumption amounts to "no CRQC existed before the retaining party anchored it", which follows receipt within a short interval. It is the same assumption live classical authentication already makes, and it is tolerable for the same reason, until the point at which it stops being defensible; the specification states that point.¶
It follows that new anchoring must cease to be quantum-vulnerable by the transition date, and that records the deployment issues must do the same: a classically signed record created after an unannounced break can be forged and then genuinely anchored. The policy dates of Section 5 do not bound when a CRQC appears; they bound only how long classical algorithms remain permitted, which is why they serve as a ceiling for the transition date rather than as a prediction. Timestamping authorities operating under post-quantum algorithms are, at the time of writing, scarce; this is a deployment gap, not a reason to relax the requirement.¶
For agent systems specifically, this is the load-bearing failure. The entire governance case for autonomous agents rests on attributability: that every action can be traced to an authorizing human. An attribution substrate whose assertions can be retroactively disclaimed does not provide that property; it only appears to.¶
Two qualifications apply. First, anchoring mechanisms shift trust to the timestamping authority and the log, and where agent delegation work requires them at all, as [I-D.nelson-agent-delegation-receipts] does, it does not require them to be post-quantum. Second, the date at which a CRQC exists is unknown. The argument here does not depend on any particular estimate; it depends on the assumption stated above, that none existed before a record first received post-quantum anchoring, and on the retention period of the record outlasting the classical algorithms that protect it. Disallowance is not compromise, but it bounds the period in which reliance on these algorithms remains defensible: a record signed in 2035, the last year in which IR 8547 permits them, and retained for an ordinary seven-year period must still be verifiable in 2042.¶
Agent delegation routinely spans organizations: an agent operated by one party invokes a tool operated by another on behalf of a user belonging to a third. This is the subject of [I-D.ietf-oauth-identity-chaining], which extends [RFC8693] across trust domains. No common trust anchor policy can be assumed across such a boundary, and no coordinated migration schedule can be assumed either.¶
Algorithm agility in this setting cannot be a deployment-time configuration choice. The algorithms in use on the far side of the boundary must be visible to, and checkable by, a verifier that had no part in choosing them, which is a stronger requirement than agility within a single administrative domain.¶
A post-quantum leaf credential issued under a classical trust anchor provides no post-quantum security. The adversary attacks the anchor and issues whatever leaf they wish.¶
Anchors are the slowest component to replace, because replacing them requires coordinated distribution to every verifier. [RFC9958] observes that long-lived root keys are difficult to replace, though it draws no conclusion about ordering, and the formats and protocols for managing anchors ([RFC5914], [RFC5934]) predate any post-quantum consideration. So far as the author has observed, and subject to the same caveat about systematic survey given above, the prevailing pattern (leaf credential formats advancing while post-quantum support for issuance and anchors waits) is insufficient rather than harmful: early post-quantum leaves cost nothing, but they buy nothing either until the anchors move and verifiers stop accepting the classical ones.¶
Short credential lifetimes, often cited as making workload identity migration easy, apply to leaves, and in SPIRE to the intermediate signing key as well, which rotates on a timescale of a day by default. They do not apply to the anchors that matter: upstream roots, the federation relationships between trust domains, and the Web PKI on which key distribution rests. The easy half is being solved first and mistaken for the whole.¶
The requirements below apply to an agent identity mechanism intended to remain sound across the transition.¶
PQ-R2, and the post-quantum quality of the anchoring PQ-R7 requires, are recommendations now and requirements from a transition date that each specification sets; anchoring itself is required now; PQ-R6's fail-closed rule takes effect on the same transition date. Deployments whose keys are bound only through the classical Web PKI, which today includes most OAuth deployments, cannot yet meet PQ-R2. The author invites discussion of whether the transition should be tied to the policy dates of Section 5, to a fixed period after publication, or left to each specification.¶
The table below summarises which party each requirement binds and when it takes effect. It is a summary only: where table and text differ, the text governs. "T" is the transition date the specification states under PQ-R2.¶
| Requirement | Binds | Now | From T |
|---|---|---|---|
| PQ-R1 agility | format, verifiers | MUST | unchanged |
| PQ-R2 post-quantum issuance | deployment | SHOULD | MUST |
| PQ-R3 chain binding | delegation mechanism | MUST | unchanged |
| PQ-R3 credential-level non-separability | delegation mechanism | SHOULD | unchanged |
| PQ-R4 anchor order | deployment | MUST | unchanged |
| PQ-R4 stop accepting classical anchor | verifiers | by a stated milestone | MUST by T at the latest |
| PQ-R5 downgrade resistance | verifiers | MUST | unchanged |
| PQ-R6 expose algorithm profiles | issuing party | MUST | unchanged |
| PQ-R6 absent assertion | verifiers | MUST NOT satisfy a constraint | MUST reject |
| PQ-R6 evidence form | whoever retains the record | MUST, where retained | unchanged |
| PQ-R7(a) anchoring | deployment | MUST | unchanged |
| PQ-R7(a) post-quantum quality | deployment | SHOULD | MUST |
| PQ-R7(b) back-anchoring | deployment | MUST, by T or earlier under the stated interval | MUST, within the stated interval from a later conformance claim |
| PQ-R7(c),(d) anchored data, renewal | deployment | MUST | unchanged |
| PQ-R7(e) quantum-vulnerable signatures | verifiers | n/a | MUST reject unless covered by T (or by the receipt cut-off, for records from other parties) |
| PQ-R7 two independent protections | deployment, verifiers | SHOULD | unchanged |
Each requirement below is addressed to the author of a specification, since that is what the IETF publishes, and each says which party a conforming specification must in turn bind. PQ-R1 binds the credential format and its verifiers; PQ-R3 the delegation mechanism; PQ-R4 the deployment that operates the anchors and the verifiers that accept them; PQ-R5 verifiers; PQ-R6 the issuing party, the verifier, and whoever retains a record under its evidence form; PQ-R2 and PQ-R7 the deployment, whose behaviour a specification can require but not itself perform, and under PQ-R7(e) verifiers.¶
These labels carry a PQ- prefix to avoid collision with the requirement numbering of [I-D.reece-wimse-cross-org-delegation], which uses R1 and upward for a different and unrelated set of requirements.¶
Credential formats MUST carry an explicit algorithm identifier and MUST NOT fix a signature algorithm in the specification. A specification MUST require that verifiers be able to accept multiple algorithms concurrently during migration.¶
A specification SHOULD require, and MUST require from a transition date that it states, that credentials of every type it declares retainable (see PQ-R6) be signed under a post-quantum or PQ/T hybrid algorithm, a hybrid counting only where verifier policy under PQ-R5 requires its post-quantum component to verify, and whose validation path to its trust anchor uses only post-quantum or PQ/T hybrid signatures (PQ-R4, made checkable by PQ-R6). The serializations of [RFC9964] and [I-D.ietf-jose-pq-composite-sigs] are examples of formats that permit it. A credential type whose instances a deployment retains past their validity period is retainable for the purposes of this requirement, whatever the specification declares. Instances issued under a quantum-vulnerable algorithm before the deployment began retaining them are treated as records issued by another party under the next paragraph; instances issued after that point are subject to this requirement. The transition date MUST be no later than the date the specification adopts for disallowing the classical algorithm (Section 5). Deployments whose keys are bound only through the classical Web PKI cannot yet satisfy this requirement, which is among the reasons for stating a transition date rather than requiring it at once. PQ-R2 does not substitute for PQ-R7: a signature does not establish when it was made.¶
Where a deployment retains a record issued by another party that is classically signed, or whose key-set binding rests on the second route of PQ-R7(c), the specification MUST state that the record's soundness rests on the honesty of the retaining party and on no CRQC having existed before that party first gave the record post-quantum anchoring, not before its stated issuance time, and MUST state a point after which such records are no longer received for retention, no later than the date the specification adopts for disallowing the algorithm (Section 5). An issuer under the same operational control as the retaining party is not another party. Verifiers apply local policy to such records under PQ-R5.¶
Where a PQ/T hybrid signature is used, it SHOULD provide credential-level non-separability as defined in Section 8: a component signature separated from the composite cannot be made to verify as a credential under any conforming JOSE or COSE verifier, given that component keys are never used outside the composite. The JOSE composite draft claims weak non-separability, consistent with [RFC9955]'s classification of the analogous construction; the property required here is layered on top of that claim rather than a stronger reading of it. Independently of the signature scheme, each hop in a delegation chain MUST be cryptographically bound to its parent, such that a hop cannot be removed, reordered, or transplanted into a different chain without detection. A token service satisfies the second by including in the token it issues a digest of each input credential; Token Exchange alone does not conform. Section 8 distinguishes these two properties and defines the first. Whether the composite serializations in current use satisfy it is unresolved at the time of writing, which is why this requirement is stated at SHOULD: a MUST would exclude the only hybrid serializations that exist.¶
A specification MUST state the order in which trust anchors migrate relative to the credentials issued under them, and that order MUST place anchors no later than the credentials they certify. Leaves may move earlier, but migrating them first achieves nothing on its own: until the anchor is post-quantum, an adversary who can attack the anchor can issue whatever leaf it likes, whatever algorithm the leaf uses.¶
Issuing a post-quantum anchor is not on its own the security event. A specification MUST also require that verifiers cease to accept the classical anchor for newly presented credentials, by a milestone the specification states and no later than the transition date, because a deployment that publishes a post-quantum root while relying parties still accept the classical one has changed nothing an adversary must defeat. Anchor migration completes at the verifier, not at the issuer. Records already retained are brought under post-quantum anchoring by PQ-R7(b) rather than left to rest on the classical anchor.¶
A deployment controls only its own anchors. Where a hop chains to an anchor operated by another party, as Section 6.3 describes, this requirement is discharged by PQ-R6 and PQ-R5 rather than by migration: the anchor's algorithm is made visible, and a verifier whose policy is not met rejects the chain.¶
A specification MUST require that verifiers reject a chain containing an algorithm that falls outside local policy, even where the signature itself verifies, and that they not treat an unrecognized algorithm identifier as acceptable; [RFC8725] gives the corresponding practice for JWTs generally. [I-D.reddy-wimse-aggregate-signatures] makes the same point for a single hop: "Algorithm agility does not mean a verifier accepts whatever algorithm a hop presents." Where an algorithm is selected rather than fixed, by authorization server metadata or by any other published algorithm list, that metadata MUST be authenticated, whether by signature as in the signed metadata of [RFC8414] or by the transport that carries it, in which case the transport's algorithms bound the strength of the policy itself, and a verifier MUST NOT derive the set of acceptable algorithms from algorithms asserted in a credential. This requirement is expressed in terms of local policy because PQ-R6 deliberately defines no ordering over algorithm strength.¶
A specification MUST require that a delegation chain expose, to the verifier, the algorithm profile of every hop in the chain, such that authorization policy can be evaluated over that set as a whole. Because a profile includes the algorithms binding a hop's key to its trust anchor and not only the algorithm signing the hop, a chain signed with a post-quantum algorithm at every hop but anchored under a classical root provides no post-quantum security, for the reason given in Section 6.4, and a requirement that exposed only hop signature algorithms would report it as sound.¶
This requirement takes two forms, and a specification MUST state which it imposes. In the authorization form, sufficient for a live decision, the issuing party asserts in the credential the set of algorithm profiles it accepted across the hops behind it. It is a set rather than a minimum, so PQ-R5 remains the verifier's own test and this document still defines no ordering. An absent assertion MUST NOT satisfy any profile constraint, and from the transition date stated under PQ-R2 verifiers MUST reject a credential that carries none; before that date a specification states how absence is staged.¶
Where a party issues a new credential from ones it received, as a token service does with subject_token and actor_token in [RFC8693], the set it asserts MUST be the union of the profiles it validated for each input credential, including each input's key-to-anchor binding, and of any sets those inputs themselves asserted. A chain must be able to begin somewhere. An input that asserts an empty set of prior profiles, or that is of a type the specification designates as an origin, for example an ID token, SAML assertion or client assertion presented as the first hop, is an origin; the issuing party then asserts the profile it validated for that input alone. An issuer with no inputs of its own asserts the empty set explicitly. Silence is not an origin: an input that asserts nothing and is not of a designated type yields an output that asserts nothing, so a gap behind the chain stays visible in front of it. The algorithms of the final hop are checked by the verifier directly under PQ-R5 and need not be asserted.¶
In the evidence form, required for any record retained under PQ-R7, the per-hop signed inputs themselves MUST be retained, not merely their algorithm identifiers: showing that the first hop authorized something requires that hop's own signature, and an issuer's assertion about it is second-hand. Because whether a credential will be retained is often decided after issuance, and neither PQ-R2 nor the evidence form can be applied retrospectively, a specification MUST either state which credential types may be retained as evidence or define a signal by which a requesting party asks for the evidence form at issuance.¶
Where a chain crosses administrative domains, as in [I-D.ietf-oauth-identity-chaining], no single party holds all of it: the second domain holds the grant it received, not the exchanges behind it. Each domain MUST retain its own segment under PQ-R7, and a complete record is the union of those segments rather than any one of them.¶
This has a concrete consequence: Token Exchange [RFC8693] replaces the token at each hop and records prior actors in an "act" claim that names who acted but not which algorithm signed, so a chain built from Token Exchange alone does not conform. This is not an objection to the OAuth trust model. [RFC8693], Section 4.1, is explicit that prior actors named in nested "act" claims "are informational only and are not to be considered in access control decisions": trust is placed in the token service by design. The difficulty is that the service's judgement is not carried forward in any form a later party can test. Where an earlier hop was signed with an algorithm an adversary can forge, the service can be deceived while it is running, and the destination cannot detect this, because nothing in the token states which algorithms the service accepted.¶
Token Exchange can carry the authorization form. A top-level claim asserting the profiles the service accepted leaves the trust model intact, and [RFC8693] places no obstacle in its way. What it does not carry by default is the evidence form, because the service's assertion about earlier hops is not those hops' signatures; a deployment needing it must arrange that the token service, or the party that retains the record, keeps the input tokens themselves. [I-D.reddy-wimse-aggregate-signatures] does satisfy the signature-algorithm half of this requirement for chains that use it, by retaining every hop's signature input so that the destination verifier can apply policy to each hop. This document does not define an ordering over algorithm strength; comparison across algorithm families is a matter of deployment policy. The requirement is that the verifier be given the inputs from which local policy can apply its own ordering.¶
Where each hop's key is bound by a certificate this requirement is straightforward, because the certification path is itself the evidence. Where the key is fetched from a key set URL over TLS, no current mechanism requires the binding to be captured, so in practice it is absent; Section 3 sets out why, and gives the two routes that would close it. Constraining the chain to a single algorithm would also work, but it is not a route to post-quantum: [I-D.reddy-wimse-aggregate-signatures] notes that aggregation requires an aggregate-capable scheme and that "ML-DSA does not aggregate".¶
A specification MUST require that:¶
(a) every retained record be anchored within a maximum interval of its issuance, or of its receipt for a record received from another party, that the specification states, and in any case before the record is relied on as evidence and while status information for its validation path is still obtainable or, where it was already unobtainable at receipt, with that fact recorded. That anchoring SHOULD be post-quantum anchoring, and MUST be from a transition date the specification states, subject to the same ceiling as PQ-R2;¶
(b) every record anchored only classically, and every retained record not anchored at all, have received post-quantum anchoring by that transition date, and in any case within a maximum interval the specification states, measured from the deployment's claim of conformance, whichever is the earlier where both are available; where conformance is claimed after the transition date, the assumption of PQ-R2 extends to that claim plus the stated interval. One archive timestamp over a hash tree can cover an entire archive: as timestamp renewal for records already in an evidence record whose last archive timestamp still validates, and otherwise as a new evidence record whose first archive timestamp covers the record together with any existing timestamp and its validation data [RFC4998];¶
(c) the anchored data include what is needed to validate the record and its anchor later. For the record's signing key this is either a certification path or key set whose binding to the issuer is signed under a post-quantum validation path; or, for a key set available only over a connection authenticated by a quantum-vulnerable signature, the retaining party's own copy, anchored together with the record, whose binding then rests on the assumption stated in PQ-R2 for records received from another party and on the honesty of the retaining party; a record so bound MUST NOT be presented as evidence to any other party without that caveat. The anchored data also include status information as obtained when the record was first anchored, and the timestamping authority's own path and status. The anchored data MUST state whether the record was received from another party and, if so, its receipt time, and verifiers MUST apply the received-record allowances only where so stated;¶
(d) protection be renewed on a periodic schedule set by policy, not on the announcement of a break, using the timestamp renewal and hash-tree renewal of [RFC4998] or an equivalent procedure, with the archived data kept available for hash-tree renewal;¶
(e) from the transition date, verifiers accept a quantum-vulnerable signature, whether on a record, on its key binding, or on an anchor, only where it is covered by post-quantum anchoring dated no later than the transition date, or, for records received from another party, no later than the point stated under PQ-R2, in either case plus the interval stated under (a) so that a record issued or received in the last such interval before the boundary is not excluded by it. When validating evidence records, verifiers treat quantum-vulnerable algorithms as insecure from that date. PQ-R5 applies to anchors and their validation paths as it does to credentials.¶
A verifier takes the time of the earliest anchor whose validity is established under (e), not any issuance time the record claims, as the time the record is established to have existed, and rejects a record whose anchor time exceeds its claimed issuance time, or for a record marked as received from another party its recorded receipt time, by more than the interval stated under (a), allowing a clock-skew tolerance the specification states. Without this the interval in (a) binds only the party doing the anchoring, and a record anchored long after the time it is claimed to date from would be indistinguishable from one anchored promptly.¶
Records back-anchored under (b), before or after the transition date, are an exception to the dating rule above, since the gap between issuance and anchoring is what that allowance exists to permit. A specification allowing it MUST require that such records be marked as back-anchored, with the date the anchoring was applied, and MUST state that their soundness rests on the assumption in PQ-R2 extended to that date. A verifier MAY apply a stricter policy to them, and one evaluating them as evidence of events before the transition date SHOULD do so.¶
A specification SHOULD require that each record be covered, from first post-quantum anchoring onward, by at least two protections from independent families (for example ML-DSA and SLH-DSA timestamps, or a timestamp and a publicly witnessed hash commitment), maintained as separate evidence records, and that verifiers require at least two, from different families, to verify, so that an unannounced break of one family does not permit forgery. The protections SHOULD NOT share a hash function or an authority. Alternating families across renewals does not achieve this.¶
The signing keys of the timestamping authority or witnesses are trust anchors for every record they protect, and PQ-R4 applies to them as it does to any other anchor. [I-D.alhemeiri-wathiqa-pqc-ers] is one proposal in this direction, and the transparency-log architecture of [RFC9943] is another candidate, in each case subject to the conditions above. [I-D.sharif-agent-audit-trail] recommends ML-DSA-65 at SHOULD level "where records must remain verifiable beyond the anticipated lifetime of classical signatures"; the requirement here differs in applying to every retained record rather than to a signature choice. [I-D.gilda-wimse-agent-audit-record] states the boundary plainly: it "does not address the retention half", because "a record cannot assert it about itself". [I-D.kuehlewind-audit-architecture] and [I-D.munoz-wimse-authorization-evidence] are further candidate homes for this requirement.¶
PQ-R1 and PQ-R5 restate, for the agent setting, guidance that [RFC7696] already gives generally: carry an explicit algorithm identifier, avoid fixing an algorithm in a specification, and do not permit downgrade. They are listed here because a requirements document for agent identity that omitted them would be incomplete, not because they are new.¶
PQ-R4 and PQ-R6 are not satisfied by conforming to [RFC7696], though the first is closer to it than it may appear. Section 2.6 of that document already observes that the signature on an intermediate certification authority certificate "is often expected to last decades, which hinders the transition away from a weak signature algorithm or short key length". That is the same structural fact PQ-R4 rests on. What BCP 201 does not do is state the migration order as a requirement, or draw the conclusion that a post-quantum credential issued under a classical anchor provides no post-quantum security. [RFC9958] likewise notes that signature migration implicates trust anchors and long-lived root keys. PQ-R6 has no counterpart in BCP 201 at all, because the aggregate algorithm profile of a multi-hop chain does not arise for a two-party protocol. Both are properties of the delegation topology rather than of any single credential, which is why per-credential agility guidance does not reach them.¶
PQ-R7 is likewise outside BCP 201, which does not address the maintenance of archived evidence. That subject has its own literature in [RFC4810] and [RFC4998], and the gap this document identifies is not in that literature but in its application: nothing requires it of agent delegation tokens in a form that survives the transition.¶
[RFC9955] classifies the design goals of hybrid signature schemes and defines a spectrum of non-separability properties. This document separates two requirements that are easily conflated, and needs a term of its own for the first because the property it needs is not one that document defines.¶
The first is a property of the hybrid signature as a credential carries it. A delegation credential carrying a PQ/T hybrid signature should provide credential-level non-separability: no component signature separated from the composite can be made to verify as a credential under any conforming JOSE or COSE verifier, given that component keys are never used outside the composite. Section 8.2 sets out why this is narrower than strong non-separability as [RFC9955] defines it, and why the JOSE composite draft claims only weak non-separability for its construction.¶
Weak non-separability alone, under which a stripped component merely leaves detectable artifacts, is not sufficient here, because the verifier that matters may be an auditor reading the record years later without the surrounding protocol context that would make those artifacts meaningful. Naive hybrid constructions (signing a message independently with a classical and a post-quantum key and concatenating the results) do not provide even that: a verifier that accepts either component, whether by design, by configuration error, or by downgrade, reduces the scheme to the weaker of the two.¶
The second is a property of the credential's position in a delegation chain, and is not a hybrid signature property at all. Call it chain-position binding: a credential valid at hop n of a particular chain cannot be presented as valid at any other position, or in any other chain. This is what prevents a delegation token from being removed, reordered, or transplanted, and it applies whether or not the signature is hybrid.¶
This document states these two properties as ones that a delegation mechanism must have. It deliberately does not specify a construction.¶
Key-prefixing, committing the signer's public key into the signed digest, is the technique of the BUFF transform [BUFF], whose subject is exclusive ownership and non-resignability rather than separability. Where a component algorithm already does this the question does not arise for that component: Ed25519 hashes the public key as part of every signature ([RFC8032], Section 5.1.6), and [FIPS204] has ML-DSA include a digest over the public key computed at key generation. ECDSA does not, and neither does RSA, which the LAMPS composite work permits though the JOSE work does not; among the traditional components it is those, not EdDSA, that leave the question open.¶
Separability turns on something else. Credential-level non-separability, as Section 8.1 defines it, is narrower than strong non-separability as [RFC9955] defines it. That document is explicit that its notion "is not dependent on other components, such as message content checking, or protocol-level aspects, such as public key provenance", and its worked example over an algorithm identifier and message concludes that "this case shows WNS ... but not SNS". The JOSE composite draft accordingly claims weak non-separability for its own construction, and the property named here is layered on that claim rather than a disagreement with it.¶
The layer comes from the message representative. Each component signs a value formed by prepending a fixed prefix and an algorithm-specific label to a hash of the message, with the label also passed to ML-DSA as its context string. The prefix and labels are themselves drawn from the base64url alphabet, so the distinction is not one of text against binary. It is where the first byte outside that alphabet falls. In any JWS signing input that byte is the "." separating the protected header from the payload; in the message representative it is the zero byte that the composite specification fixes after the label, marking an empty context. A second and independent obstacle applies to the post-quantum half: that component is signed with ML-DSA's context set to the composite label, where [RFC9964] uses an empty context, so it cannot verify as an ordinary ML-DSA signature whatever the encoding. The two can therefore never be equal, whichever serialization or payload encoding is used, including the unencoded payload option of [RFC7797]. The threat considered is a verifier that holds the composite public key and extracts one component signature from it; because ECDSA and RSA verify over a hash of their input, the argument holds barring a collision in that hash. A COSE signing input needs a separate argument and has one: it is a CBOR array beginning 0x84, 0x85 or, for the countersignature structures of [RFC9338], 0x86, where the message representative begins 0x43.¶
The qualification about component keys is load-bearing. A component signature over the message representative is a well-formed signature under its own algorithm, and an interface that signs or verifies raw bytes will accept it. What closes that gap is the composite specification's prohibition on using component keys outside the composite, not anything about the encoding.¶
The protected header carries a different weight. In JWS the "alg" value is integrity protected when it sits in the protected header, as it always does in the compact serialization; the JSON serialization also permits unprotected headers, which are not covered ([RFC7515], Sections 5.1 and 7.2.1). COSE requires that the "alg" parameter "MUST be authenticated where the ability to do so exists" ([RFC9052], Section 3.1), and the Sig_structure covers the protected bucket. That prevents the algorithm of a whole composite being restated. It does not prevent a separated component being reused elsewhere.¶
[I-D.ietf-lamps-pq-composite-sigs], Section 9.2.3, states that Composite ML-DSA "will provide WNS for both components and a limited form of SNS for the ML-DSA component", and that because the label naming the algorithm is included in the signed object, Composite ML-DSA "therefore provides a version of SNS for X.509". That second claim is stated without condition; it is the first, the limited form of SNS for the ML-DSA component, that the document says can be strengthened "if the prefix-based mitigation described in Section 9.4 is applied". [I-D.ietf-jose-pq-composite-sigs] uses the same construction but claims only weak non-separability.¶
This document therefore puts one question to the JOSE working group. Given the message representative that draft defines and its prohibition on standalone use of component keys, is there any JWS signing input, compact or JSON, with the payload encoded or not, or any COSE signing input, Sign1, Sign or countersignature, equal to that representative? The analysis above suggests not, barring a collision in the component algorithm's hash, because a JWS input reaches "." before any byte outside the base64url alphabet while the representative reaches a zero byte, and a COSE input begins 0x84, 0x85 or 0x86 while the representative begins 0x43. If the working group agrees, it could state that a separated component cannot verify as a JOSE or COSE object, while continuing to classify the construction as weak non-separability per [RFC9955]. The author will also raise this question on the JOSE mailing list.¶
Constructions providing chain-position binding are equally established: capability delegation systems commit each element to its predecessor, and both [I-D.asor-wimse-agent-delegation-chain] and [I-D.atakora-wimse-sadp-delegation] do so for agent delegation specifically.¶
What is absent is not a construction. It is a requirement, in the agent identity architectures being specified now, that any of them be used.¶
This document is entirely concerned with security considerations.¶
The requirements in this document address forgery of authority and fabrication of audit evidence. They do not address confidentiality of agent traffic, which is the ordinary key establishment migration.¶
Hybrid signature schemes carry a cost: credential size, verification time, and implementation complexity all increase, and in constrained or high-rate settings this may be material. That cost should be weighed per credential class. The argument of Section 6.2 applies with full force to credentials retained as evidence. Whether a credential will be retained is often decided after it was issued, which is why PQ-R6 requires that retainable types be declared in the specification, or the evidence form requested, at issuance.¶
Adding a second signature algorithm adds a second implementation that can contain vulnerabilities. Where both components must verify, a defect in one does not by itself yield a forgery, so against forgery the composition is no weaker than its stronger correctly implemented part. The costs lie elsewhere: a larger parsing surface, more implementation complexity, and a second component whose failure can deny verification. This trade is generally favorable during a transition of uncertain duration but is not free.¶
Anchoring moves trust rather than removing it. A deployment that satisfies PQ-R7 depends on the timestamping authority or log it anchors to, and the compromise of such a party is a compromise of every record it protects. This is the reason for preferring publicly witnessed commitments where they are available, and for treating those signing keys as trust anchors under PQ-R4.¶
The evidence form of PQ-R6 requires retaining per-hop credentials, and until they expire those are live bearer credentials. A deployment SHOULD hold them where they cannot be presented for access until they expire, or require that they be sender-constrained, so that an evidence archive does not become a store of usable authority.¶
A verifier that fails closed when an algorithm profile is absent, as PQ-R6 requires from the transition date, will reject chains that were previously accepted. This is why absence does not satisfy a constraint before that date but does not yet cause rejection: the staging interval is what keeps the requirement from being a denial-of-service exposure, and a specification SHOULD say how a deployment is expected to use it.¶
Any mechanism satisfying Section 8 will commit to the bound values through a hash function. A collision in that function permits substitution of the values it commits to, so the hash must be chosen with that in mind. A collision-resistant hash with at least 256 bits of output, such as SHA-256, is adequate for this purpose against both classical and quantum adversaries, and is what existing delegation constructions use. A deployment subject to [CNSA2] should note that it requires SHA-384 or stronger, so a mechanism intended for that market cannot take SHA-256 as its floor. The point is that the choice should be stated rather than left implicit.¶
PQ-R6 requires that a delegation chain expose, to the verifier, the algorithm profile of every hop. A chain that carries that information also reveals the shape of the delegation: how many hops there were, and, depending on the credential format, which parties issued them. Because the requirement extends to the algorithms binding each hop's key to its trust anchor, it also reveals which trust anchors and issuing authorities each party relies on, which is itself a signal about that party's infrastructure and suppliers. Where delegation crosses organizational boundaries, as Section 6.3 describes, that may disclose commercial relationships that the parties would not otherwise expose to a relying party.¶
This cost falls almost entirely on the evidence form of PQ-R6. The authorization form discloses only a set of algorithm profiles, which says little about who the parties were; it is the retained per-hop material that exposes the shape of the delegation and the identities in it. A deployment that needs the evidence form has accepted that its records name their participants, which is generally the point of an audit record. Mechanisms that reduce the disclosure, such as committing to hop metadata rather than revealing issuer identities, or proving a policy predicate over the chain without revealing its elements, are possible, and are out of scope here. A specification adopting PQ-R6 SHOULD state what it exposes and to whom.¶
This document has no IANA actions.¶
A large language model was used, under the author's direction, to help draft and edit prose and to search the standards and Internet-Draft literature. The author reviewed all resulting text, verified each cited document against its source, and is responsible for the content of this document.¶
This appendix illustrates PQ-R6's authorization form across the identity chaining flow of [I-D.ietf-oauth-identity-chaining]. It is not normative. Profiles are written as {alg / path}, where the path is the algorithm binding the signing key to its trust anchor (simplified here to a single algorithm; a profile as Section 2 defines it includes every algorithm on that path). The transition date is written T.¶
Origin. A user authenticates to domain A and receives an ID token signed ES256, its issuer key bound by a signed key set under a classical Web PKI path. The token asserts nothing about prior hops, as today's ID tokens do not. As an ID token presented as the first hop it is an origin by the designation rule of PQ-R6, rather than by asserting an empty set, so a party that validates it may assert a profile for it rather than being obliged to assert nothing. Asserted set after this step, once an issuer vouches for it: {ES256 / RSA-2048}.¶
Domain A token exchange. The authorization server of domain A takes the ID token as subject_token and issues a JWT grant, signing it with ML-DSA-65 under a key bound by a post-quantum path. It asserts the union of what it validated for its input and what that input asserted. It does not add a profile for its own key, because PQ-R6's union rule admits only those two sources; its own signing profile is something the next party validates rather than something it asserts. That its self-assertion would in any case not be one of the routes PQ-R7(c) accepts is a further reason. Asserted set: {ES256 / RSA-2048}.¶
Cross-domain grant. Domain B's authorization server receives the JWT grant. Validating it means validating domain A's key binding, which is published under a post-quantum path, so that profile enters the set here through the union rather than by domain A's own say-so. The classical entry is still the origin's. Asserted set: {ES256 / RSA-2048, ML-DSA-65 / ML-DSA-65}.¶
Resource server. The verifier applies PQ-R5 to the asserted set and checks the final hop's own signature directly. A policy requiring every entry to be post-quantum rejects this chain on the origin entry, which is the intended outcome: the chain is only as strong as that hop.¶
Two behaviours depend on T. Before T, a credential arriving with no asserted set does not satisfy any profile constraint, but a verifier need not reject it outright; a deployment uses that interval to fit issuers with the claim. From T, the same credential is rejected. Had the domain A server in step 2 received an input that asserted nothing and was not an origin, it would have asserted nothing on output, and the gap would have been visible to the resource server rather than hidden behind the exchange.¶
For retention, no single party holds the whole chain: domain A holds steps 1 and 2, and domain B's authorization server and resource server hold steps 3 and 4. Each retains its own segment under PQ-R7, and a complete evidentiary record is the union of the two.¶