Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for "structural" caveats? #13

Open
clementd-fretlink opened this issue Nov 2, 2018 · 0 comments
Open

Improve support for "structural" caveats? #13

clementd-fretlink opened this issue Nov 2, 2018 · 0 comments

Comments

@clementd-fretlink
Copy link
Collaborator

These caveats make assumptions about the whole structure of the macaroon (eg they assert the presence of other caveats).

A verifier for these caveats needs access (in addition to the current caveat) to the whole caveats list.
This is already possible to have this kind of caveats by making the verifier close over the caveats list extracted from the macaroon:

mkVerifier :: Monad m => [Caveat] -> Caveat -> m VerifierResult
mkVerifier = 

checkMacaroon :: Monad m => Secret -> Macaroon -> m (Either Macaroon ValidationResult)
checkMacaroon secret macaroon = 
  let cs = caveats macaroon
       structuralVerifier = mkVerifier cs
       allVerifiers = structuralVerifier : otherVerifiers
   in verify secret allVerifiers macaroon

@jtanguy has proposed a solution to avoid this separation between regular and structural verifiers by always providing the full list of caveats to verifiers, eg with a zipper (actually, we'd need a non empty zipper, since we need at least the current caveat.

Pros of the non empty zipper approach :

  • no need to manually close over the caveats list for structural verifiers
  • less clunky way to exploit the caveats order (it's significant) than with the whole list and the current caveat

Cons of the non empty zipper approach :

  • added complexity
  • structural verifiers are an advanced topic with macaroons, and a verifier verifying several caveats
    at the same time is usually a bad idea, so I fear it would encourage people to depart from common macaroon idioms without realizing it.
@clementd-fretlink clementd-fretlink changed the title Improve support "structural caveats"? Improve support for "structural" caveats? Nov 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant