Flatpak paid apps and private repos design document

[Alexander Larsson]

On Thu, Aug 1, 2019 at 4:51 PM Owen Taylor <otaylor at redhat.com> wrote:
>
> I'm looking at this from the perspective of the "OCI" codepaths in
> Flatpak - the idea of this is that we can package up a Flatpak as a
> OCI (or docker) container and install it from a container registry.
> From that perspective, some things here seem over-specified - specific
> to the classic ostree codepaths, or perhaps even to flat-manager.
>
> Authentication/authorization is still interesting, but probably for
> different cases:
>   - The entire repository is private and you need to provide
> credentials to get the index (summary equivalent)
>   - The repository index is public, but you need to provide
> credentials for a "subscribed account" to download some or all content
>
> In addition, we are generally interested in leveraging existing
> container repositories - so there isn't much ability to change how the
> repository works - so while authorization might still be by bearer
> token, specifying the exact details of what is in the bearer token
> isn't going to work.

So, I see two issues here:
 1) The document lists tokens as JWT, which might not be what an OCI
registry uses. However, I don't really see why we have to require JWT,
as long as whatever token we use is handled correctly on the server
(and i commented re that in the doc). The only case where we would
need to verify the token elsewhere is in the p2p case, and we could
easily document that p2p only works with JWT tokens.

2) Some OCI registries will require a bearer token for the index (i.e.
summary file), and the current API doesn't consider that. I think we
could add a separate request for that though, could we not? I.e.
something you call before RequestRefTokens as you download the summary
file. RequestSummaryToken() or suchlike.

Other than that everything here is hidden behind the authenticator API
and could be easily made to work for OCI repos, no?