以前、「
.NETの暗号ライブラリが進化している件について。」と言うタイトルで投稿させて頂き、その中で、
「
JWTライブラリは自作ライブラリでのサポートも見えてきたにもかかわらず、jose-jwtというOSSライブラリを使用することに決めました（餅は餅屋的な事です）。」
と書かせて頂きましたが
、.NET Framework → .NET Core移行の中で、「
パスワード・ハッシュ関数ライブラリの下位互換維持の作業」が必要になり、
BouncyCastleの暗号化プリミティブを使用して暗号処理を組み立てたのですが、こういうのって重要だなぁ...。と思い、やはり自作することにしました。
で、出来たのが以下になります。
jose-jwtで検証済みでしたが、一応、
jwt.ioでも検証してみました。結果としては、「無事に [Signature Verified] されたぜ。クロス・プラットフォーム万歳！」的な感じになりました。
何故「万歳！」か？と言うと、コレは、ES256の「E」はECDsaの「E」で、色々と動作確認すると、JWKを（ECParameters経由で）読込めるECDsa系プロバイダのサポートが結構、限定的だったことに起因します。
具体的に言うと、
「上記の条件に合致するECDsaCngが、net47では動くケド、 netcoreapp2.0 on Windowsで動かず、色々調べて見ると、netcoreapp3.0 on Windowsでなら動作する（Linux上ではECDsaOpenSSLを使用すればnetcoreapp2.0でも動作する）。また、ECDsaのX.509証明書のサポートやECParameters構造体も、net47から追加されたものである。」
...と言う事で、上記を纏めると、ECDsaのX.509証明書やJWKを読込めるECDsa系プロバイダは、net47, netcoreapp2.0 on Linux, netcoreapp3.0 on Windows 以上でサポートされる。と言うことで、FAPI2をサポートする「
汎用認証サイト」のランタイム・サポートも「net47以上 or netcoreapp3.0以上」としました（コレも暗号化プリミティブを個別に検証しないと問題を正確に捉えることが出来なかったので良い収穫になったと思います）。
一方、JWE (RSAES-OAEP and AES GCM) ですが、コチラは、RSAES-OAEPの暗号化プリミティブ、RSAOAEPKeyExchangeFormatterクラスを使用した「アリスとボブの鍵交換」だと思って調べていて、暗礁に乗り上げていましたが、よくよくRFCを読むと、コレって、単にRSA系プロバイダ・クラスの暗号化をOAEPのオプションでやるって話っポイですね。RFCは英語で書かれていて、日本語で読むより大変ですが、言語的に詰まるのではなくて、コンテキストが解らなくて、詰まることの方が多いですね。
追記：後日、JWE (RSAES-PKCS1-v1_5 and A128CBC_HS256) の実装も追加し、jose-jwtによる検証も実施しました。
また、ちょうど今、
が問題となっていますが、「
"LoA"なんて言葉、普通は知らないですよね？」と思います。実際に、インターネットを検索してもあまり情報はありません。これはFAPI2のスペックの中にも出てくるタームなので、実際に調査した経験からそう思っています。
某弊「
汎用認証サイト」では、この辺（≒ パスワード・ハッシュの話です）についても考慮して対応を進めていこうと考えていますので、コチラのASP.NET Identity準拠のIdPを、OAuth2/OIDCのSTS経由で使用すれば安心度が高いです。是非ご活用ください。
＜参考＞
Open COBOL Solution WG
JWS (ES256)、JWE (RSAES-OAEP and AES GCM)の実装が完了しました。
