The start of snap entitlements

Hello all,

This is something we’ve been discussing for quite some time in some circles, but we haven’t managed to get started on it or even write anything down. You may have heard about this as “entitlements”, and it has some similarities to what is well known as “in-app purchases” as well, except such features may not necessarily have an association with money.

This is an attempt to bootstrap a more formal conversation so we can start the initial steps towards eventually having the whole idea working.


In some cases snaps may offer optional features that depend on the authorization of one or more third-parties for the feature to work. The simplest case to imagine is the availability of the entire application being conditional on payment, where the feature is being able to run the application at all, but there’s a gradient of richer use cases that benefit from finer grained control of what specifically is the application capable of doing, and then how to prove that it can indeed do it. For example, a backup snap might use that feature to communicate to the snap that remote backups to one or more storage services is available.


Tersely, the idea is this:

  • A snap has some optional features locally or that requires access to third-parties
  • A snap may ask the store about which optional features are usable
  • A snap may also ask the store for a token to provide to third parties as proof


We still depend on the terminology to settle (see below), but here are some ideas to get our minds ticking:

See what is enabled for a given snap:

$ snap entitlements mysnap
Snap      Entitlement  Expiration
mybackup  storage      -

From inside the snap, query to see if an entitlement is supported:

$ snapctl entitled storage

Ask the store for a token to communicate with the third-party:

$ TOKEN=$(snapctl entitled storage --token)
$ curl "https://...?token=$TOKEN"

The third-party can then double check with the snap to make sure that the communicating snap is indeed entitled to whatever it was trying to do.

We can also extend the entitlement latter with individual attributes if necessary. Most probably not the exact command line interface we’d want, but something along the lines of:

$ SIZE=$(snapctl entitled storage --attr=size)

We don’t need to cover that before we have everything settled, and there’s a chance this won’t even be necessary.


To get started on this we don’t really need much. The initial implementation might just ask the store for tokens of the authenticated user when necessary. Using assertions might be interesting, but we need to discuss the fact systems would access independent assertions to enable particular entitlements.

The token feature might work similarly on a first version. Ideally the client would handle it as an opaque piece of data that is just conveyed to the third-party for validation with the store, if and when that’s indeed desired.


I would like to avoid using “entitlements” in the final implementation of the feature. It feels too long, and somewhat entangled, unfriendly to non-native speakers and hard to type. We discussed “feature”, but that’s going to create plenty of confusion in conversations when talking about snap features. Also considered “permit”, but that’s too bureaucratic… and “subscriptions”, but that has a connotation of recurrence that may not apply. I’m leaning towards “skill” right now… but it still needs more discussions.

@roadmr This is vaguely what I had in mind. We need to evolve it still, but hopefully this provides a good basis for us to discuss it further.

How about we call it snap powers.

The same idea, as described above, stands. I think the name is just more powerful and easy at the same time.

1 Like

That sounds very nice, actually!

So snap will have Super Cow Powers?


Thanks for kicking this off. Lots of angles to dig into but I’ll start with a couple.

Terminology: we had used the term “capabilities” (also somewhat long) in some prior discussions.

How do you see these being enabled for a particular device? Would we initiate from snapd or the snap to request enabling the capability? The example above implies the latter, that there’s some switch/UI in the snap that a user toggles to enable, which calls snapctl entitlement storage --token. If so, where does the payment flow fit in for paid capabilities? Or do we first attach a device-id to a store account, so we can setup N-device provisioning or metering based billing out-of-band without a user-auth’d session on the device itself.

Will the device need to be online to check the entitlement. Will we cache the status for a while?

I suspect some snaps might be ok with just an offline check, while some might want a frequent online one.

I suppose the offline case is where assertions might play a role at some point.

We might have two mechanisms here:

  1. For long-living statements about additional features that should be enabled in that snap, we can use assertions. These work naturally well offline.

  2. For short-lived statements about access that may be granted in third-parties via authentication tokens, we can use direct communication with the store and short term caching. The offline case is naturally irrelevant here since the access to the third-party would require connectivity anyway.