[RFC] Labelled Data, Indexing and Token Authorisation

Development RFCs
34

The issuer most likely will be the Authenticator. For us, this likely means SNAPP, or the safe cli

The ideal is that they do not need to be online to validate the macaroons. But yes, if using the actual macaroon libs, the issuing authority will need to validate them and be communicable.

It’s possible to do. It may provide a bad user experience and is most definitely sub-optimal IMHO.

Something to remember here is that this isn’t only about sharing data, but all access to data. Your applications can be given permissions based on labels. Or other users.

Requiring the need the need to check in with an Authenticator a) creates more networks messages for each and every request and b) creates a bottleneck around that authenticator (to a point where we move back towards having the Authenticator as the gatekeeper of the network, which has previously proven to be problematic due to bottlenecks.

Macaroons are neat because they are tokens that can be attenuated. But they require centralized validation. Which is find for that use case as you’re, in the end, always asking returning the token to the same place.

For us, our token will be given to apps who will be talking directly to the network (to avoid the Authenticator bottleneck), which can check validity only if it has the secret key for macaroons.

For this reason we’re looking at asymmetric keypairs. With the Authenticator minting the token, with a SecretKey, to be stored for reuse. But which can be validated by the network using the PublicKey.

This gets us very close to decentralized macaroons. (And once we have fleshed out some attentuation ideas, there).

Good Q. I’ll try and flesh this out here, and update OP once this seems clear enough :+1:

Something we touched upon above, but which needs to be expanded on is the use of BLS Key-Shares. These allow each label to have a keypair, and a key-share to be delegated to apps for part of the validation against label PKs stores on data,

First, in general:

  • An app X wants to create label L and apply to some data.
  • App requests Authenticator for permission.
  • Label L doesn’t exist, so a keypair is created for it in the account.
  • KeyShares are provided to app X once permission is granted.
  • Auth permission is granted, within a timelimit and a Token is minted via a BLS key-pair sign. The token sez “He who bears this, can manage label L, for two hours from < now >”
  • Token is returned to app X
  • PublicKey is stored in the account AccessContainer for retrieval later.
  • SecretKey is stored by Authenticator

When X wants to access data, it must:

  • Make a GET request, and pass along the token.
  • ClientHandlers validates that the token matches the request type (ie has PUT permission if a PUT requests`
  • ClientHandlers validates that the token with a PublicKey which has been stored in the AccessContainer.
  • ClientHandlers validates that things are still within the specified timeframe
  • ClientHandlers agree the request is valid and send to DataHandler
  • DataHandler checks the token’s labels against those on the data. If a PublicKey stored in the data’s Permissions array validates the KeyShare stored in the token, the request is valid and the GET is done :+1:

Sharing data

The OP proposal has a flaw in that the suggested Shared Token only allows you to access data where the original owner minted the token. It does not give flexibility for delegating responsibility to another account eg.

As such, our fallback system which is used for label key management, is generating of BLS Key-Shares.

Eg: Each label will have a master key-pair, used to generate a key-share for each app, this key share can then provided to the data handler for validation against the permission’s PublicKey set. This is touched on ion the OP, but will need to be expanded.

So we can provide another user with a keyshare for our label, and that account can then create / manage it’s own tokens, which will provide key-shares to apps for signing requests.

ClientHandlers will treat these tokens as above. Just instead of the account/authenticator having access to the original KeyPair for a given label, it was provided by another account.

Hope that answers some of your Qs, @tfa ? Let me know if that raises more, thougH! Good to be thrashing this out, especially after a good few days away from the idea :slight_smile:

4 Likes