Open
Conversation
Adds the JSON sister of the cose-key family from #400. Uses single-byte codes adjacent to that block so JWK-based identifiers do not pay an extra prefix byte forever. * jwk (0x44): JSON-encoded JWK per RFC 7517 section 4 * jwk-set (0x45): JSON-encoded JWK Set per RFC 7517 section 5 The existing jwk_jcs-pub (0xeb51) and jwk_jcs-priv (0x1316) entries remain; they are a strict canonical-JCS subset suited to stable peer IDs. The new entries cover full RFC 7517 JWK as a self-describing container; choose jwk_jcs-* when deterministic encoding matters and jwk/jwk-set when interoperating with arbitrary RFC 7517 producers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two self-describing JSON key container codecs, the JSON twin of the
cose-key/cose-key-setpair proposed in #400.jwk0x44application/jwk+json)jwk-set0x45application/jwk-set+json)The payload identifies its own algorithm via the
kty/alg/crvparameters. The same container carries public or private key material; private parameters (d,p,q,dp,dq,qi) mark a private key.Suggested by @achingbrain in #400 (comment).
Motivation
Same as #400: stop gating new key types in libp2p peer IDs and IPNS records on per-algorithm multicodec registrations. Once IETF/IANA registers a new
kty/algvalue, JWK producers can emit it and JWK consumers can parse it. No multicodec update required.JSON web stacks already speak JWK everywhere: OAuth and OIDC JWKS endpoints, WebCrypto's
importKey/exportKey, every JOSE library, WebAuthn passkey enrollment.cose-keycovers the CBOR-native side of the same story;jwkcovers the JSON-native side and lets JS and web stacks participate without a CBOR dependency.Relationship to existing
jwk_jcs-pub/jwk_jcs-privThe registry already contains:
jwk_jcs-pub(0xeb51)jwk_jcs-priv(0x1316)Those constrain the format on purpose: required-members-only JWK, JCS-canonicalized per RFC 8785. They give peer-ID-style identifiers a deterministic encoding, so the same key always hashes to the same bytes.
The new
jwk/jwk-setcodecs complement them as the loose-container counterparts:jwk/jwk-set: any well-formed RFC 7517 JWK or JWK Set, arbitrary members allowed, no canonicalization promised. Use when wrapping or referencing an as-is JWK (a JWKS fetched from an OIDC provider, a WebCrypto export, a JWK withkid/use/x5cmetadata).jwk_jcs-pub/jwk_jcs-priv: minimal, canonical, deterministic. Use when the codec output is the identifier itself (peer IDs, content addressing of bare keys).cose-key(loose) lacks a canonical-subset codec too, so the same asymmetry already exists on the CBOR side.Code placement
0x44and0x45extend the single-byte block #400 establishes at0x40-0x43. All six codes stay single-byte varints (< 0x80), so identifiers built on top (peer IDs, IPNS names) keep the one-byte prefix forever. Same argument as #400.The existing
jwk_jcs-*codes sit at two-byte varints (0x1316,0xeb51); a single-byte option is genuinely new real estate, not duplication.Dependencies
This PR touches
0x44-0x45; #400 touches0x40-0x43. The diffs are independent. If #400 lands first, the four containers sit consecutively. If this lands first,0x40-0x43stay vacant until #400 merges. No conflict either way.