Inheritable key-value metadata from policy to license

[zertrin]

Hi,

We are currently implementing a licensing scheme whereby different tiers of the pricing scheme have different restrictions in our product.

One of them is CPU count, for which we can set the value for each pricing tier at the Policy level, which will be inherited by the individual licenses.

However, we also have other restrictable valued metrics for which we would like to be able to define them at the policy level and inherited by the license. Policies would be like Free / Pro / Ultimate / Ultimate Trial with each of them having a set of metrics that are restricted with different values.

We initially thought that the metadata for the policy would be inherited by the licenses, but this is not the case.
Also, the user token is not sufficient to query a policy (to read its metadata) so we can't work-around with an extra API call. (embedding the product token is not an option obviously for security reasons)

So far, I feel that would mean that, apart from the CPU count, for all the other restrictable metrics, we would need to either:

• set them in the metadata of each license when it is created. But this is hard to maintain once we have many licenses (we haven't automated the license creation for now, it's still manual), especially if we need to update these limits in the future for a given tier, or change the policy of a given license.
• create many individual entitlements to attach to the policies, the name of each of which representing:
  • either a pair of {restriction_type, tier}. For example:
    • METRIC_A_FREE
    • METRIC_A_PRO
    • METRIC_A_ULTIMATE
    • METRIC_B_FREE
    • METRIC_B_PRO
    • METRIC_B_ULTIMATE
    • ...
  • or a pair of {restriction_type, value}. For example:
    • METRIC_A_10
    • METRIC_A_1000
    • METRIC_A_Unlimited
    • METRIC_B_25
    • METRIC_B_250
    • METRIC_B_2500
    • ...

But this feels quite inelegant, and quickly adds overhead and a lot of handling code in the product.

The reason we wanted to attach the metric restrictions at the policy level is to enable us to future-proof the system so that if we need to change the value of these metrics for future policy variants (updated product pricing or limitations), without impacting the restrictions of past licenses, we would simply add a policy like Ultimate v2 with updated restrictions, which wouldn't impact existing Ultimate v1 policies.

To clarify, we would like the value of these restrictions to NOT be hardcoded in the product, but rather driven from the keygen backend.

I've been searching in the documentation but haven't really found a more elegant solution. (Groups are not an option as we use it for their intended purpose, i.e. grouping users from the same organisation)

Wondering about any other suggestions?

Otherwise, I'd see this as a potential feature request to be able to set key-value metadata at policy level that become inherited by the licenses.

[ezekg]

No plans on inheritable metadata. Metadata is unique per-resource. You can use entitlements for this use case, as you outlined. Any entitlement attached via the policy will propagate down to all of the licenses implementing said policy.

Entitlements can have metadata as well, which may be useful here.

[zertrin]

Sorry it took us a while to digest and implement something that matched our requirements. Here's our final solution for the benefit of others reading this in the future:

In the end, we went with creating a set or entitlements modelling our product tiers (e.g. TIER_FREE, TIER_PRO, TIER_ULTIMATE entitlements) and attaching the metadata we needed to convey to them. Then we attach these tier entitlements to the respective policies. The entitlement's metadata can finally be read from the client side.

Thank you very much for the prompt reply ❤️ Thanks for the great product!