The problem
A license server chooses which license key to grant. It can only choose well if it knows what the client can do with the key, and today the request does not tell it enough.
Finite field DSA is unavailable on macOS since .NET 11. Every license key issued until 2026 is signed with it, so on that platform such a key does not verify: the client reports
the license key is signed with a cryptographic algorithm that this platform does not support
The keys signed with ECDSA do verify there. So a pool that holds both kinds has keys that work for that client and keys that do not, and the server has no way of telling them apart for that client — version and buildDate do not say which runtime the client is on, and nothing says which operating system.
The seat is consumed anyway. The server grants the lease and records it before the client ever looks at the signature. A developer on macOS whose server picks a DSA key therefore holds a seat, on a machine that is not licensed, and takes another one at every renewal. They see a cryptographic error, their administrator sees a seat in use, and neither of the two messages mentions the other.
Proposal
Add two arguments to the lease request:
- the runtime framework the client runs on, and
- the operating system.
The server already parses every license it holds, so it already knows which authority signed each one (SignatureKeyId). With the two arguments it can skip the keys whose algorithm that client cannot verify, exactly as it already skips the ones whose version or build date do not fit, and report the same kind of explanation when nothing is left.
Both arguments are additive: a server that ignores them behaves as it does today, and a client that does not send them is served as it is today. That matters, because the clients deployed in the field will not send them for years.
What the client would send
The shape is for this issue to settle, but the values have to be tokens the server can match on, not the descriptions that RuntimeInformation.FrameworkDescription and RuntimeInformation.OSDescription return, which are prose and change between patch releases. Something in the register of framework=net11.0&os=macos, alongside the existing version and buildDate.
The question worth deciding here is whether the server should match on the framework and the operating system at all, or whether the client should name the algorithms it can verify. The second is narrower and does not need the server to carry a table of which platform dropped which algorithm — it is the client that knows, and the client is the one that will be wrong about it if the table lives on the server and the server is older than the platform. The first is more informative for everything else a server may want to do with it, including the usage statistics an administrator reads.
Scope
Server side: accept the arguments and use them when selecting a license. Client side: send them, in SharpCrafters.Backstage, alongside the product argument discussed in #8.
The problem
A license server chooses which license key to grant. It can only choose well if it knows what the client can do with the key, and today the request does not tell it enough.
Finite field DSA is unavailable on macOS since .NET 11. Every license key issued until 2026 is signed with it, so on that platform such a key does not verify: the client reports
The keys signed with ECDSA do verify there. So a pool that holds both kinds has keys that work for that client and keys that do not, and the server has no way of telling them apart for that client —
versionandbuildDatedo not say which runtime the client is on, and nothing says which operating system.The seat is consumed anyway. The server grants the lease and records it before the client ever looks at the signature. A developer on macOS whose server picks a DSA key therefore holds a seat, on a machine that is not licensed, and takes another one at every renewal. They see a cryptographic error, their administrator sees a seat in use, and neither of the two messages mentions the other.
Proposal
Add two arguments to the lease request:
The server already parses every license it holds, so it already knows which authority signed each one (
SignatureKeyId). With the two arguments it can skip the keys whose algorithm that client cannot verify, exactly as it already skips the ones whose version or build date do not fit, and report the same kind of explanation when nothing is left.Both arguments are additive: a server that ignores them behaves as it does today, and a client that does not send them is served as it is today. That matters, because the clients deployed in the field will not send them for years.
What the client would send
The shape is for this issue to settle, but the values have to be tokens the server can match on, not the descriptions that
RuntimeInformation.FrameworkDescriptionandRuntimeInformation.OSDescriptionreturn, which are prose and change between patch releases. Something in the register offramework=net11.0&os=macos, alongside the existingversionandbuildDate.The question worth deciding here is whether the server should match on the framework and the operating system at all, or whether the client should name the algorithms it can verify. The second is narrower and does not need the server to carry a table of which platform dropped which algorithm — it is the client that knows, and the client is the one that will be wrong about it if the table lives on the server and the server is older than the platform. The first is more informative for everything else a server may want to do with it, including the usage statistics an administrator reads.
Scope
Server side: accept the arguments and use them when selecting a license. Client side: send them, in
SharpCrafters.Backstage, alongside theproductargument discussed in #8.