Skip to content

Support RFC 9864 Fully specified algorithms (Ed25519, Ed448, etc.) #1190

Description

@matt-allan

Feature request

Add support for fully specified algorithms such as Ed25519.

These algorithms were added by RFC 9864.

You can see the full list of registered algorithms here: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

My issue

I tried using Ed25519 with the PyJWKClient and it didn't work. The key was silently skipped, and then I got a confusing keyset has no key for kid error.

The actual error was:

jwt.exceptions.PyJWKError: Unable to find an algorithm for key: {'kty': 'OKP', 'crv': 'Ed25519', 'alg': 'Ed25519', 'use': 'sig', 'x': '--OMITTED--', 'kid': '--OMITTED--'}

Then I tried to workaround the issue by manually re-registering EdDSA as Ed25519, but that didn't work because PyJWK only consults the default algorithms.

If it was possible to override the algorithms used, that would fix my issue too.

Activity

  1. mangrisano commented on Aug 18, 2026

    @mangrisano

    Hi! If no one's already working on this, I'd be happy to take it. The fix should be simple: add Ed25519 and Ed448 to get_default_algorithms() (validating the curve, like the recent EC change).

  2. auvipy commented on Aug 18, 2026

    @auvipy
    Collaborator

    you are welcome

  3. wbolster commented on Aug 18, 2026

    @wbolster
    Contributor

    heya 👋🏼,

    i also would like to see this happen, and i already started working on it last week. didn't want to post here until it was ready, but since others also expressed interest, it would be good to avoid unnecessary duplicated efforts.

    get_default_algorithms() indeed needs some changes, but it's slightly more involved though, b/c of all the extra checks, and covering all that with tests, which should test all cases including backwards compat, invalid key types, etc. in addition it also needs some doc updates, etc.

    i'll try to find some time to dust off my work in progress and cook up a MR this week!

  4. mangrisano commented on Aug 18, 2026

    @mangrisano

    @wbolster Don’t worry about it. Carry on with your work, and if you run into any problems, feel free to write here. I’ll be happy to help.

  5. wbolster commented on Aug 19, 2026

    @wbolster
    Contributor

    i've just opened PR #1199 that adds support for ‘alg: Ed25519’ and ‘alg: Ed448’.

    maintainers and those who showed interest (👋🏼 @mangrisano @auvipy), please have a look!

  6. mangrisano commented on Aug 20, 2026

    @mangrisano

    LGTM. Just a non-blocking note: Ed448’s hash is SHAKE256 specifically (SHA-3 family), so SHA-3 is a little imprecise — might be worth naming it SHAKE256. Does that sound right?

  7. added a commit that references this issue on Aug 20, 2026
    3d3e878
  8. wbolster commented on Aug 20, 2026

    @wbolster
    Contributor

    Ed448’s hash is SHAKE256 specifically (SHA-3 family) […] might be worth naming it SHAKE256

    sure! i've just pushed a change that makes the text more generic and specifically mentions SHAKE256.

    (pls use review on the pull request #1199 itself if possible)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions