Owin.dll, the assembly inside the Owin package on Nuget.org, does not have an Authenticode signature. However, on Windows Server 2016 and Windows Server 2019, Get-AuthenticodeSignature (and sigcheck.exe) incorrectly report that Owin.dll does have an Authenticode signature.
If you deploy a Windows Server VM and run this code, it will return different signing and timestamping certificates (I only did this in Azure):
> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
> Invoke-WebRequest "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe" -OutFile NuGet.exe
> .\NuGet.exe install owin -o .
> Get-AuthenticodeSignature .\Owin.1.0\lib\net40\Owin.dll | Format-List
On Windows Server 2019, it returns a SignerCertificate with Thumbprint AE9C1AE54763822EEC42474983D8B635116C8452 and TimestamperCertificate Thumbprint 893ED0E4D032C3855D5D2296B2DE2DD1AFB897DD.
On Windows Server 2016, it returns a SignerCertificate with Thumbprint E85459B23C232DB3CB94C7A56D47678F58E8E51E and TimestamperCertificate Thumbprint CFC3E3018EA65666DCE484FC7016EB42D1F108A9.
Other certificate metadata indicates that these are, in fact, certificates from Microsoft.
What's going on here? Why does this specific assembly behave this way in these specific versions of Windows?
Whilst the signature isn't part of the Owin.dll itself, Windows Server has a "Security Catalog" (under %SystemRoot%\System32\CatRoot) which identifies Owin.dll by name/hash. The security catalog is signed by Microsoft, and it's the signing certificate of the security catalog that's being returned by Get-AuthenticodeSignature. In effect it's simply a "detached" Authenticode signature, rather than being embedded in the .dll.