Proof of Concept: Macaroons

[dstufft]

No description provided.

[dstufft]

We would need to implement our verifiers here. We can add arguments to this function like the resource we're operating on or what permission this request is trying to use to pass in values from the outside world, in order to implement something that depends on the current request.

[dstufft]

Here's a dump of my NOTES.txt file from when I was working on this proof of concept:

New permission structure, permissions that limit the ability to upload, or to
restrict uploads that create new projects, releases, or files. This particular
permission acts as a tree, where upload grants all, upload:project is similiar,
upload:release can create new releases and files, but not projects, and
upload:file can only upload new files.

upload
  - upload:project
  - upload:release
  - upload:file



Caveat: Permissions = ["upload", "upload:project", "upload:release", "upload:file"]
Caveat: Resources = [Project(foo), Release(1.0), File(foo-1.0.tar.gz, hash=sha256:...)]
Caveat: NotBefore = XXX
Caveat: NotAfter = XXX


- Need to actually make sure we're not relying soley on authentication anywhere,
  and that we're actually checking authentication AND authorization everywhere.


- Identifier Syntax: v:1 user:... id:...


- We probably need to run the verification returns on the given macaroon instead
  of just blindly listening to the inside?

[dimaqq]

I'd expect to see Authorization: Bearer ABCD and another layer dispatch on the format of the token.
Is there a spec for new credential type?

[dimaqq]

What is the rationale of storing root caveats explicitly?
IIRC:

• root macaroon == f(key, caveats)
• key must be stored (somewhere) to allow validation
• id is needed to find the key and to invalidate macaroon tree

Thus, (id, key, root macaroon (bytes) ) is all the information needed, right?
Is the idea to recompute root macaroon on demand?
Can root caveats be edited?
What's validates, caveats in request macaroon or in this table?

[dstufft]

The only reason to store the caveats in the database is to make it possible for the UI to show what the maximum scope of this token is. Of course given the way macaroons function we can't tell them what derived macaroons they've made from that initial token and what those are scoped to, but we can tell them what the max scope their token is good for.

We would never use what's in the database here for the validation, it'd just be there for informational purposes.