Consider embedding key derivation sources instead of relying on Microsoft.AspNetCore.Cryptography.KeyDerivation

[kevinchalet]

Hey @henkmollema,

As part of OpenIddict 3.0, I'd like to remove the Microsoft.AspNetCore.Cryptography.KeyDerivation dependency from the OpenIddict core package. I had to lobby hard to convince the ASP.NET team to keep DP compatible with .NET Standard 2.0, which motivated me to get rid of DP in the core stuff.

Do you think it would be possible to copy the key derivation classes you need from Microsoft.AspNetCore.Cryptography.KeyDerivation and ship a version of CryptoHelper with no dependency?

Cheers!

[henkmollema]

Microsoft will keep shipping .NET Standard 2.0 packages for Microsoft.AspNetCore.Cryptography.KeyDerivation right? Is it really a problem to keep using these packages then? KeyDerivation and its dependency Internal consists of 20-30 classes. Copying them and keeping them in up to date seems cumbersome and I'm not sure I would want to do that. What do you think?

[kevinchalet]

Microsoft will keep shipping .NET Standard 2.0 packages for Microsoft.AspNetCore.Cryptography.KeyDerivation right?

Right, but they also said pretty clearly that DP was not intended to be used outside of ASP.NET Core: dotnet/aspnetcore#3774. I wouldn't be surprised if the .NET Standard 2.0 TFM was removed in the next major version.

Is it really a problem to keep using these packages then?

There's also a naming issue: the key derivation packages live in Microsoft.AspNetCore.*: OpenIddict 3.0 will be compatible with ASP.NET 4.x/OWIN/Katana and as part of this release, I'd like to remove this dependency (so things are less confusing for people using OpenIddict 3.0 in non-ASP.NET Core environments).

Copying them and keeping them in up to date seems cumbersome and I'm not sure I would want to do that.

It definitely makes sense and I can certainly understand that. I'll try to explore other options 😃