最近、「Financial-grade API Part 2」のサポートに向けて、JWS（ES256）や、JWE（RSAES-OAEP and AES GCM, etc.）など、チョット高度なJWT作成をサポートすべく、.NETの暗号化ライブラリを調査していましたが、.NET Framework 4.5、4.6、4.7とドンドン実装が進化していることが観測できました。お陰で、#if-#endifが増えまくってますが（Open棟梁は、net452, net46, net47, netstandard2.0をtargetにビルドをしている）、この背景は、やはりクラウド間のフェデレーションで暗号技術が重要になって来た事に起因していると言うことなのでしょうか？

　また、.NET Coreでは、Linux上で動作することを考慮してRSAOpenSsl、DSAOpenSsl、ECDsaOpenSsl、ECDiffieHellmanOpenSslなどのOpenSslベースの暗号プロバイダも追加されているようです。予想外にCAPI(CSP)、CNGのプロバイダが.NET Standardに実装されている。と言う事も観測していましたが、これは、Linux上で動かすと、NotImplementedExceptionが発生したりします。

　また、実装レベルも何気に考慮すべきパターンが多いです。考えられるパターンを列挙すると、

　等々があり、色々テストしてみると、X.509 証明書を使用した際に取得できるRSAプロバイダが、.NET FrameworkではRSACsp、.NET Core on WindowsではRSACng、.NET Core on Linuxでは、RSAOpenSslになることが解っています。この辺り（暗号化や証明書ストア）は、プラットフォーム依存が強いので、クロスプラットフォーム対応は難しい部分がありそうです。

　とは言え、クロスプラットフォーム対応の方法も、実は大方見えて来ていて、基本的には、ファクトリを使用してプロバイダを生成して、ベースの型でハンドルすればイケると思います（というか行けた。そう言う意味で、次バージョンの暗号ライブラリは、かなり強化されたモノがリリースできると思います）。

　以上、落ちは特にありませんが、JWTライブラリは自作ライブラリでのサポートも見えてきたにもかかわらず、jose-jwtというOSSライブラリを使用することに決めました（餅は餅屋的な事です）。

＜参考＞

• マイクロソフト系技術情報 Wiki
• .NETの署名・暗号化アルゴリズム
• OpenID / OAuth / OpenID Connect
• Financial API (FAPI)
• jose-jwt