verify-key ~ check-out?

[nschloe]

I looked at checking out license files as an alternative to what I do know, i.e., validating licenses and caching its results. From what I can see, the license file contains the exact output of a validate-key call -- it's also signed with the same key --, and additionally offers to add more data (include) and optional encryption. Would it be fair to say the two methods are very similar?

[ezekg]

They do have a similar payload, sure, but in no way does the checkout action replace validation. Checking out a license does not validate the license. Validation is a separate action that performs a variety of assertions on the license and on its associations (machines, etc.)

You should continue to validate your licenses whenever an internet connection is available.

[ezekg]

But instead of caching the license validation response, you can cache the checkout response, yes. That's what license files are for — securely using license data while offline. Sorry if I misunderstood your question.

[nschloe]

Thanks for the reply! The question is little oddly posed because I don't see very clearly yet. For valid keys, they return almost the same data structure.
The differences between validate-key and checking out license files seem to be:

• For validate-key, you only need a key (perhaps an invalid one), for checking out you need the license_id and a valid key.
• validate-key returns a little meta section that contains 'valid': True/False; checked-out licenses meta section only contains info on the validity of the check-out, not the license. (Not sure if you can check out invalid licenses at all.)

I'm not sure now what license check-outs are used for at all. Don't validate-key responses always contain more info; can't I just pass around those, and perhaps set a TTL in the application?

[ezekg]

License files are used within offline environments. The validation endpoint is used for online environments.

For example, take this scenario:

1. The user is online and inputs their license key
2. The app validates the license key
3. The app also checks out a license file and stores it for later use
4. The user exits the app
5. The user goes offline
6. The user opens the app
7. The app cannot validate the license key due to being offline
8. The app fetches the stored license file and verifies/decrypts it
9. The app continues to function offline until the license file expires

As you can see, checking out a license file is not a replacement for validation at all. Licenses should still be validated while online. But license files can be used to obtain a license object while within an offline environment. Sometimes license files are even transferred to the offline device directly, e.g. via USB flash drive, for devices that never have internet access.

Perhaps I misspoke when I said you can use a license file as a replacement for validation caching. I meant for caching in offline environments, not for caching in online environments or caching for other reasons. You will likely still want to cache validation responses if you're e.g. simply using the cache to limit the number of requests made to our API.

You can continue to use validation responses without issue.

[nschloe]

1. The user is online and inputs their license key
   ...

You can do exactly the same thing with a cache, even without a second request:

1. The user is online and inputs their license key
2. The app validates the license key (via validate-key)
3. The app also checks out a license file and stores it for later use if successful, the app caches the response
4. The user exits the app
5. The user goes offline
6. The user opens the app
7. The app cannot validate the license key due to being offline
8. The app fetches the stored cache and verifies/decrypts it
9. The app continues to function offline until the license file cache expires

What's the advantage of using a license file then?

• Its more compactly formatted and "meant" to be passed around
• You can add additional data, such as product data (if sufficiently authorized)
• The app doesn't have to implement its own caching

Anyway, I think I'm beating a dead horse here. Perhaps we can say that license files and caching are similar and may even share some use cases. One is not better than the other for certain tasks. Would you agree?

I ended up looking at license files because I'd like to give new users a string that contains the license key, the account ID, and the product name such that a license manager tool (which doesn't have the keygen verify key) can display information about the license, e.g.,

license-manger show-all

/path/to/foobar.lic
    Product:    Foobar
    ID:         abc-def-ghi
    Type:       Online key
    Created:    2023-05-09
    Expiry:     2024-05-09 (in 265 days)

License files did look like what I was looking for at first sight, but it turned out no different than the caching I was already doing. In particular, when updating license files users don't have permission to fetch product info, so I'm back at square 1.

The solution I'm thinking of now is something I'd rather have avoided, namely home-cooking something: Create a base64-encoded dictionary that contains all info that I want (license key, the account ID, the product name, perhaps something else), give and give that to the user. When validating, unroll the whole thing etc.

[ezekg]

License files are a well-defined format, while your homemade cache format is arbitrary. The entirety of the license file is also cryptographically signed (and optionally encrypted), so nothing can be tampered with — not the dataset, not the TTL, not the expiry. It's all signed. While manual caching only has a signed license payload, so it could have its cache TTL or expiry tampered with since none of that is signed by Keygen (since that part is defined by you — the cache implementer).

And yes, if you want to include the product info inside of a license file, you'd need to checkout the license file server-side.

Hope that clears things up.