6 ms·

Thanks for the input! I'm still hoping the tech catches up somehow and then there's probably going to be more people interested in a standardized way to define

Thanks for the input! I'm still hoping the tech catches up somehow and then there's probably going to be more people interested in a standardized way to define a caveat. When I was toying with Macaroons some time ago, I thought that I could use JSON to format the caveat and toyed with the idea of defining a set of useful caveats, but never got too far.

evancordell 9y ago
It seems that most people have those thoughts when they play around with Macaroons :) Check out the google group for some discussions: https://groups.google.com/forum/#!forum/macaroons https://groups.google.com/forum/#!forum/macaroons If it wouldn't doom them to obscurity, I'd personally like to see a set of vocabularies that macaroon users can use (a la semantic web). This is probably as simple as namespacing caveats with globally unique identifiers to indicate the vocabulary.
- saganus 9y ago
  Yes, exactly! I actually did read the whole forum when I found out about them, and that's where I got the idea actually. Not that I went much further than what was discussed, but it definitely planted a seed on my mind... Re: Vocabulary Something like that sounds reasonable. I would just maybe add some sort of SET operations logic that you could use to build more complex stuff. Thus I would be able to delegate to someone a Macaroon that has admin access to all of Project P EXCEPT (or MINUS) access to Project P's children in list L. Or maybe delegate with access to any object in List (L1 AND L2). Sort of like a SQL query (to an extent). At least that was the use case I needed back then, i.e. How to secure an API in a hierarchical way, such that certain user roles can access only certain children of a certain parent node.