Post-quantum signatures are moving closer to the token formats used by APIs, identity systems, devices, and software supply chains. On October 20, the IETF JOSE working group published revision 06 of PQ/T Hybrid Composite Signatures for JOSE and COSE. The draft defines serializations that combine ML-DSA with ECDSA or EdDSA for JSON Object Signing and Encryption and CBOR Object Signing and Encryption.
This is an active working-group Internet-Draft, not a final RFC. It may change, expire, or be replaced. It is nevertheless useful for planning because JOSE and COSE sit inside many application protocols. A new signature identifier can affect issuers, verifiers, key stores, gateways, firmware, SDKs, test tools, and policy engines at once.
An algorithm identifier hides an application graph
A hybrid composite signature presents one algorithm choice to a protocol while containing multiple cryptographic components. The draft pairs ML-DSA with traditional ECDSA or EdDSA choices and specifies how keys and signatures are serialized.
Operational readiness requires more than adding the identifier to a library. A useful inventory should capture:
- the JOSE or COSE use case, token type, issuer, verifier, and business owner;
- the exact composite algorithm label and component parameter sets;
- key generation, storage, backup, rotation, recovery, and destruction boundaries;
- JWK, COSE key, hardware-module, or other key representations;
- libraries, SDKs, gateways, identity providers, devices, and services that parse it;
- token, header, payload, transport, database, and message-size limits;
- algorithm allowlists, negotiation, fallback, and rejection policy;
- test vectors, interoperability results, and failure behavior; and
- source maturity, evidence date, confidence, owner, and review trigger.
This graph makes it possible to distinguish library capability from an end-to-end signed workflow.
Signing and verification populations move at different speeds
A token issuer may be upgraded centrally while verifiers are distributed across services, partner environments, mobile clients, gateways, or embedded devices. Conversely, verifiers may accept a new algorithm before key-management and signing systems can create it safely.
Migration plans should therefore report producer and consumer readiness separately. Teams need to know which verifiers reject unknown algorithms, which silently fall back, and which apply a broad allowlist. During staged deployment, accepting both old and new forms may be necessary, but the transition window, policy owner, and retirement criteria must be explicit.
A percentage of upgraded libraries is not the same as a percentage of protected transactions.
Composite keys change custody and recovery
The draft relies on precise serialization of composite public keys, private keys, and signatures. Operationally, the component keys must be generated and kept together in the right relationship without weakening either component.
Key-management systems may represent the pair as one logical object or as linked components. HSMs and remote signing services may support one component before the other. Backup and disaster recovery must preserve the binding, version, policy, and access controls. Rotation must account for both components and every verifier that recognizes their combined identifier.
Teams should test partial failure deliberately. What happens if one component is unavailable, corrupted, expired, or produced by a different key version? A verifier should not accidentally accept a separable fragment when policy requires the composite.
Size and parser behavior belong in the risk record
Post-quantum signatures and keys are larger than many traditional equivalents. That can expose limits in HTTP headers, cookies, authorization gateways, message brokers, QR codes, constrained links, database columns, firmware manifests, or secure-element interfaces.
Pilots should measure complete artifacts, not just raw signatures. Include encoding overhead, headers, chains, proof material, and transport framing. Test malformed lengths, unknown labels, non-canonical encodings, truncation, resource exhaustion, and rejection paths.
Parser differences are security relevant. Interoperability evidence should name the exact library and version on both sides, along with the test vector and expected result.
What organizations should do next
First, discover where JOSE and COSE are used by function: identity tokens, API requests, device attestation, firmware manifests, credentials, and signed business messages.
Second, separate issuers, verifiers, and key-custody systems. Assign readiness and owners to each population rather than to the protocol name alone.
Third, add composite structures to the cryptographic data model. Preserve component algorithms, parameters, labels, key relationships, and source maturity.
Fourth, test end-to-end size, parsing, rejection, rotation, recovery, and rollback across representative implementations and constrained environments.
Finally, treat this draft as work in progress. Track revisions and registry decisions, and do not market experimental support as standards-complete deployment.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record using discovery, canonical inventory, evaluation, action, and proof. Organizations can connect token formats and algorithms to applications, devices, keys, owners, dependencies, evidence, exceptions, and migration work.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted. Vista is not a vulnerability scanner, and incomplete discovery is not proof of absence.
Learn more about Vista’s post-quantum migration, cryptographic inventory, and CBOM capabilities.
Where uncertainty remains
The draft has not completed the standards process, and ecosystem support, validation, performance, and interoperability will vary. Hybrid composition also does not eliminate implementation flaws, key compromise, parser vulnerabilities, or weak operational policy. Its immediate lesson is to inventory the full token-signing dependency graph before a final identifier becomes a production deadline.
Source
- PQ/T Hybrid Composite Signatures for JOSE and COSE, revision 06, IETF JOSE Working Group, October 20, 2026.