Preferred naming conventions for third-party contrib packages?

[MattCotterellNZ]

I've nearly completed work on Azure Key Vault support for #2052, however I am a little caught up on the naming conventions you'd prefer for a project like this. Would you be able to offer advice on what sort of name I should use to refer to this in:

• Project Namespaces
• NuGet Package Name
• Project Name

At the moment I'm using IdentityServer.Contrib.AzureKeyVaultTokenSigningService for all three, however it's best to check this is an ideal naming style before I'm stuck with it 😉

[leastprivilege]

I would say use:

IdentityServer3.Contrib.*

I changed some things around in the DefaultTokenSigningService for v2.2 It now has a mini pipeline and a virtual method to override for loading the actual key.

Could you have a look at that to see if it works for you?

[MattCotterellNZ]

I've just been referring to https://github.com/IdentityServer/IdentityServer3/blob/5711eb286c64f3336226e35576e4e065ac5ceeb6/source/Core/Services/Default/DefaultTokenSigningService.cs as a reference (latest on the master branch as at time of writing), is this the version you're referring to?

[leastprivilege]

no - dev branch

[MattCotterellNZ]

Thanks for your help @leastprivilege, I've got a (prerelease) package on NuGet now under this naming convention. :)

[leastprivilege]

Did you see the ISigningKeyService we introduced? That is the much better solution to your problem I think.

[omerlh]

Hey
The ISigningKeyService is great, but the main issue for me is the coupling with X509Certificate2. I guess this is because the middleware used to validate JWT tokens simply decode the JsonWebKey back to X509Certificate2. This is a problem because I am going to use HSM/Azure Key Vault, and it will be easy to generate RSA key/ JsonWebKey, but X509Certificate2 will be a bit more uglier. What do you think will be the best solution here?

[leastprivilege]

Right now it is X509 certs only. If you need full control you can derive from the DefaultTokenSigningService.

But in any case - the current identityserver is designed around x509 certs. And there is no easy way we can change that (without breaking stuff).

[omerlh]

Yes, I've understood that from digging a bit in the code.
But my question is - does it because of something that requires X509Certificate? like in the validation middleware?

[leastprivilege]

Please open a new issue for that.

[omerlh]

Done, #2727