Feedback wanted on new flatpak purchases support

[Alexander Larsson]

Today I released flatpak 1.5.1 which has some initial work around
purchases and other form of protected content in flatpak. It is still
early work and not considered stable yet, but I want to try to have
some support for this in the Flatpak 1.6 release at the end of the
year. Thus I'm sending this mail out to the list and to some people
who I'd like to get feedback from.

At the most basic level, the way protected content work is that the
repo http server refuses serving certain refs unless the client
presents a token that the server can validate[1]. Exactly which refs
are protected is up to each repo maintainer, but protected and
non-protected refs can be mixed in a repo. In order for flatpak to
know when a ref needs a token there is a new "token-type" property in
the commit, and whenever this is set to a non-zero value flatpak will
try to use a token when downloading it.

To figure out what token to use for each ref there is the concept of
an Authenticator. An authenticator is a (dbus) service to which
flatpak offloads the work of figuring out what token to use (and if
its needed). The flatpak config then contains information on what
authenticator to use for that remote.

The idea is that authenticators can come in different forms for
different repositories. For example, they can come pre-configured with
the distribution if they interact with some pre-existing system like
for instance enterprise distribution entitlement systems. Or they can
be associated with some web-based authentication system. For the later
the goal is to allow automatic installation of the authenticator from
the flatpak repo, but that is not yet implemented.

The authenticator might need to do some kind of interaction with the
user. For example to to log in to some service or to enter credit card
details. This can be done in two ways, either the service can directly
show a native UI (similar to how portals work), or they can use a
web-based workflow. The web flow works by the authenticator telling
the flatpak client to show a webpage (rather than directly starting a
browser), which allows frontends like kde discover or gnome software
to integrate the webview better with its UI.

To make it easy to try this out I wrote a sample authenticator and
corresponding API server and set up a demo server where you can try
them. Instructions for testing are here:

  https://github.com/flatpak/flatpak/wiki/TestingPurchases

I'm interested in feedback on the overal approach here, as well as
APIs and how well it covers what people need for flatpak.

The authenticator dbus APIs are documented here:

  https://github.com/flatpak/flatpak/blob/master/data/org.freedesktop.Flatpak.Authenticator.xml

The libflatpak APIs for frontend integration, are documented here:

 https://flatpak.readthedocs.io/en/latest/libflatpak-api-reference.html#FlatpakTransaction

The sample authenticator uses a REST API which is documented here:

  https://github.com/flatpak/flatpak-sample-authenticator

The sample API server implementation is here:

  https://github.com/alexlarsson/flat-auth

In particular, new in the libflatpak API is the webflow-start/done
signals and the abort_webflow/set_parent_window methods. (The later
unfortunately don't seem to be in the docs yet...)

Does this all make sense? Does it seem comprehensive enough for what
you want to do with flatpak? Does the API work for your frontends?

I'd like to mention that this is a pretty minimal initial
implementation. There was an early design document[2] that has a lot
more features. In particular it describes APIs to let the client know
ahead of time what will happen if you try to install something
(i.e. that some app is a "purchase" or "donate" rather than "install"
operation, as well as possibly details like prices, etc).

I think we still want that, but it will require more consideration to
get the API for that right. In particular describing things like
pricing structures can easily be tied to implementation details of the
backends, so need a lot of care.


[1] https://tools.ietf.org/html/rfc6750
[2] https://docs.google.com/document/d/1zE_QbB6mtdhjH5bsFdf9kPrYvjKAMBRl4uSRYDt-BqQ

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com