Client's Public Key Retrieval
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Domain
- api, authentication, security
Research direction
This is a standards and design discussion rather than a scoped implementation task. Start by reviewing the OpenID Federation and introspection approaches named in the issue, including jwks_uri and the proposed client_jwks_uri. Done would require a decided, documented approach for resource servers to retrieve clients’ public keys.
Written by the indexing model from the issue text.
Description
Originally submitted by Takahiko Kawasaki (Takahiko Kawasaki) on 2025-05-09
Are there any standards other than OpenID Federation that allow resource servers to retrieve a client’s public key? To verify an HTTP message signature in a resource request, the resource server needs the client application’s public key - that is, the counterpart to the private key used to sign the HTTP message. However, there is currently no standardized way for the resource server to obtain this public key. Has there been any discussion in the community about standardizing a method for retrieving clients' public keys?
As far as I know, OpenID Federation is currently the only standard that enables resource servers to retrieve client metadata (and subsequently the client’s public key via the jwks_uri property). However, adopting OpenID Federation is too heavy for most API systems, as it requires authorized third parties to operate trust anchors and intermediate authorities.
A straightforward solution to obtain the client’s public key might be to include a property - such as client_jwks_uri - in the introspection response that indicates the location of the client’s JWK Set. But I’m not sure if that’s an appropriate approach…
Bitbucket status: open
Bitbucket origin: issue 740
- Dominant language
- HTML
- Stars
- 4
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openid/fapi
-
component: FAPI 1: Advanced migrated-from-bitbucket priority: major type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
migrated-from-bitbucket priority: trivial type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
-
component: Implementation & Deployment Advice
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
AOSSIE-Org/DebateAI#611 ·
Maintainers usually reply within 3 days
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
openzim/mwoffliner#2933 ·
Maintainers usually reply within 1 day
-
Use the README category name for website links and submissionsPossibly taken @dajiaohuang claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
birobirobiro/awesome-shadcn-ui#647 ·
Maintainers usually reply within 2 days