Conversation
|
Marked this as draft because I still need to add a change to the JwksGenerator to include key ids, but the code that is already here can be reviewed. |
joachimvh
left a comment
joachimvh
left a comment
There was a problem hiding this comment.
This is to support the UMA implementation right? I'm thinking it might be better to include it in the configs specifically for that so this is only enabled when setting up as an RS for an UMA server.
| const { method, url } = request; | ||
|
|
||
| if (!allowedMethods.has(method)) { | ||
| throw new MethodNotAllowedHttpError( | ||
| methodsNotAllowed, | ||
| `Only GET or HEAD requests can target the storage description.`, | ||
| ); | ||
| } | ||
|
|
||
| if (url !== this.path) { | ||
| throw new NotImplementedHttpError(`This handler is not configured for ${url}`); | ||
| } |
There was a problem hiding this comment.
There is a RouterHandler class that we generally use to cover these cases, that can wrap around this one. If you looked at the StaticAssetHandler for inspiration, that one doesn't have it because it was made before we had that and we never bothered to update.
|
We use this in the UMA setup, yes, but I specifically separated it because it can also be used by packaging (signatures as provenance), HTTP Message Signatures (used in GNAP, which I hope to work on soon), and in fact any protocol relying on server-wide asymmetric crypto (often on the Well-Known jwks path). |
2 participants
This PR adds a
JwksHandlerthat publishes the public key of aJwksGeneratoras a JWK Set on a given path.