You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 28, 2026. It is now read-only.
I believe we could remove the jwk import/export steps that mention "EdDSA" in webcrypto-secure-curves since there's always the crv member present that fully specifies the key's sub type. Or we could remove the alg member from export and incorporate the new ones into import only as an option to check for, albeit with the risk of the algorithm changing during the RFC process.
@twiss WDYT? I lean towards not having the alg member checked during import and also not exporting it, that would meant the steps are identical for all 4 algorithms in this spec.
See https://mailarchive.ietf.org/arch/msg/jose/3REQba16DLXxxpk8IU1pF-AiTCM/, the EdDSA alg identifier might be getting deprecated in the foreseeable future.
I believe we could remove the jwk import/export steps that mention "EdDSA" in
webcrypto-secure-curvessince there's always thecrvmember present that fully specifies the key's sub type. Or we could remove the alg member from export and incorporate the new ones into import only as an option to check for, albeit with the risk of the algorithm changing during the RFC process.@twiss WDYT? I lean towards not having the
algmember checked during import and also not exporting it, that would meant the steps are identical for all 4 algorithms in this spec.