-
Notifications
You must be signed in to change notification settings - Fork 10
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.
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
Add support for JWKS #46
Comments
My did:example method specification could always say that an additional
Then, I will be able to resolve |
Of course one downside would be interoperability. Service providers that rely on that feature would need to know which DID methods support JWKS but the same holds true for any other publicKey type. |
If the example query above is not correct, could you provide an example of how the query could look like to get the |
We could think about introducing DID method decorators. One such decorator could be to add this jwks section based on the publicKey section in the DID document. In this way, we could achieve some sort of interoperability. I could imagine that other decorators could make sense as well. Every DID method author could choose which decorators are supported by their DID method. |
Coming back to this topic, there has been an extension DID parameter called "transformKeys" for a while that can convert verification methods in DID documents to JWK, or an entire DID document to JWKS: https://github.com/decentralized-identity/did-spec-extensions/blob/main/parameters/transform-keys.md |
This was discussed during the did meeting on 23 January 2025. View the transcriptw3c/did-resolution#46markus_sabadello: Could be supported by an optional flag. Would not be a DIDDoc, and the resolver would not return a DIDDoc. Flag could result in a JWK set in the dereferencing. Use cases in OpenID. manu: +1 to providing an option. Resolvers may support it or not. Extension - not in the core spec. Having to define transformational algorithms would be needed. ivan: Not sure why saying not a DID. A DID is a CID, and the CID allows you to do that. Should be valid DIDDoc. <Zakim> JoeAndrieu, you wanted to say its easy to have a DID URL to return JWKs, but they cannot be canonical |
JOSE/IETF specifications often use URIs that point to JSON Web Key Sets (JWKS), e.g., OpenID Connect. It would be great if we could find a way that allows a DID URL to be used in such a way. This could be either done by using matrix parameters, or something similar.
We could also limit the scope by just including public keys that have the
publicKeyJWK
type.Is there a way to use DID URLs in such a way already?
The text was updated successfully, but these errors were encountered: