Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Public key in JWT #44

Open
bc-pi opened this issue Apr 9, 2024 · 2 comments
Open

Public key in JWT #44

bc-pi opened this issue Apr 9, 2024 · 2 comments

Comments

@bc-pi
Copy link

bc-pi commented Apr 9, 2024

Please consider using the jwk header parameter to convey the public key in the JWT sent by the browser. That would better leverage existing standards, be similar to how DPoP did much the same thing: https://www.rfc-editor.org/rfc/rfc9449.html#name-dpop-proof-jwt-syntax, and remove ambiguity of "key": "public key", in the current example.
@arnar
Copy link
Collaborator

arnar commented Apr 10, 2024

Thanks. Just to check: The jwk header field is only meant to hold a key for which the JWT itself is signed with, correct?

That works fine here because the registration is self-signed, but if it ever wasn't (e.g. if we added cross-signing between sessions at some point) would it still make sense?

@bc-pi
Copy link
Author

bc-pi commented Apr 10, 2024

Thanks. Just to check: The jwk header field is only meant to hold a key for which the JWT itself is signed with, correct?

Yes. That's from https://www.rfc-editor.org/rfc/rfc7515#section-4.1.3

That works fine here because the registration is self-signed, but if it ever wasn't (e.g. if we added cross-signing between sessions at some point) would it still make sense?

It's hard to say in the abstract or hypothetical but wouldn't it make sense to figure out how that would work and define it when/if such a thing was added?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@arnar @bc-pi