[RFC] Labelled Data, Indexing and Token Authorisation

The bits I understand look very nice!

I don’t know if doing this client side precludes using labels in sync with more concrete ‘types’ such as Published, Unpublished, AppendOnly, MutableData, ImmutableData, but if possible I think it would be useful to have those available as labels. For example, to filter a search by SAFE data type and status.

Also, applying the label ‘Published’ could be a useful API to have alongside the lower level call and so on. Labels of this kind could be distinguished using a leading symbol such as an underscore or ‘$’

I’m not sure if extending labels like this is going to confuse the developer and user experience, or make it simpler, but I think it is worth considering. It certainly appeals to me, but well, I’m not typical :crazy_face:

I like the idea of having the user’s labels in a readable form, but when they choose to expose a label to keep the label hidden from any app or third party. E.g. I decide to share all data that has the label ‘BestFriends’ but all the recipient knows is that this is a collection of data, rather than the label I’ve applied to it, though that might be visible if I want - say as a default which I can remove/hide/alter. Is that catered for?

For anyone unfamiliar with macaroons, I think this is the starting point (maybe link to something like this in the OP?):

And there’s a Rust macaroon implementation (also Go).

2 Likes

The idea is any data you put with your account could be labelled.

:+1:

I think the neat thing is, as a dev, you could largely ignore labels for a small app. And just be concerned with your apps data. And that would be fine.

Just other apps may be able to find it too!

Yeh, the shared data setup lets the recipient define what they want to call this data, nothing (thus far) is specced out to say “i call this X”. you could do that in a message if you wanted I guess… (or perhaps an option to share label metadata) .

I’ll place that link atop the OP :+1: thanks for your thoughts @happybeing!

(and just to note, we did look at rust impls, but they fall short for how we valiate requests due to the need to always have the SK to verify macaroons, hence why we’re rolling our own)

1 Like

I’m not sure I was clear enough here. I did realise (expect) labels could be ‘applied’ to any data type. My suggestion was that certain labels be available which correspond to the type. So all MutableData would for example have label ‘$MutableData’ etc. You could then use ‘$MutableData’ as a filter in any UI/API which accepts labels.

Secondly, that by applying the label ‘$Published’ to something that is not yet published, the effect would be to publish that data.

Hope that’s clearer!

3 Likes

Ah right. Sorry, misunderstood. Aye, those are good labels/indexes to be having I think aye! And could be easily applied automatically :+1:

Ah interesting! That’s not in the current RFC. It wouldn’t work how we have data at the moment (published data is another namespace), though there some ideas / data changes being discussed that may make this possible.

1 Like

I think it can work if you don’t implement publishing by adding a label, but do the action of “publishing” when the API to apply a label is asked to apply ‘$Published’.

So applying certain labels is an alternative way of invoking the action ‘publish’ rather than just applying a special label.

Hope that’s clear!

3 Likes

From latest weekly update:

This is a bad example because the network doesn’t manage time. But is this doable at the application level?

An application could complete the chain of system caveats controlled by the network by its own caveats. There could be conventions that applications can follow to manage these supplementary caveats like timeout restrictions, or better a client API that helps managing them.

But these restrictions could be bypassed by forking the application and removing the corresponding controls, or in the case of a timeout, simply by changing the system time of the PC running the application.

So, I would say there is no interest in managing application caveats client side, unless I am missing the big picture, like time managed by the network. A hint for this is:

But I don’t see how we can rely on a timestamp that isn’t a network consensual time.

2 Likes

That’s correct for absolute time, but durations may be possible at a network level for a given account, which would work for this usecase. E.g. I’ll give you access to this file until my clock runs down to zero.

Good Q @tfa. It’s not 100% that it’ll work, but I’m sure we‘ll be able to get this eventually, without requiring consensus on the time exactly.

I don’t think it would be for the reasons you outlined.

There’s been some discussion on time in general, and while the network itself wont (cant) be aware of time, I think it’s possible for some form of this to work at the client side (Authenticator and Validators). It has yet to be proven, but I think it’ll go.

A ClientHandler node, could validate the time as part of its normal checks ( is the token revoked? Does it match the request… etc). These ClientHandlers reach consensus on whether they think the request is valid or not, not specifically the current time. It may be that it falls down if a request is made at the expiration time, and therefore consensus isn’t reached. But we could also allow for approximations here.

I’m not sure if it’ll work 100% (proof will be in the pudding), but for the purpose of asking “is this application still valid” (as opposed to network critical operations), I think it may well be enough for ClientHandlers to be doing this.

If this approach doesn’t work, we’ll probably look at tying duration to parsec blocks (as been suggested elsewhere on the forum), so duration could be approximated there. But I’m hoping we wont need to go there.

2 Likes

What is the use case for this? Once access is given, the document can be copied to local storage. The copier then has perpetual access.

1 Like

It’s not just people, but apps. You might want to give access to an app until, say, you log out, or for a given duration.

You might want to give edit privileges to a person as well though, and then withdraw them. Sure they could copy the file if they had view access, but it’d be a duplicate, not the original with on-going edits. An example being group collaboration on a text file.

1 Like

If that’s the case then you don’t need a concensus time. Just use the time based on the client(s) in charge of assigning privileges. Time by fiat.

No you wouldn’t need a consensus on time, as I mentioned, but you wouldn’t want a connected client to do it either.

I’d like to be able the log-out from all my devices and still have the permissions withdrawn after the duration I’d specified. Accounts don’t need to agree on time for that.

If that’s the use case you want, then a consensus time or trusted time duration is exactly what you are asking for.

I should probably leave this to smarter guys than me, but just so I can understand :slight_smile:… do you really need a consensus on time for this? If I am the permission holder, and can withdraw those permissions at any time I like anyway, it is surely only my view of the duration that should matter? Two accounts do not need to be in sync, or start their clocks at the same time, or agree on what GMT is, for that, right?

1 Like

Based on my understanding…

Not if one leaves at least a single client device logged in. You can then be the time master.

If all your devices are logged out, you need the network to do this for you via some kind of time/duration consensus, ie parsec blocks.

1 Like

NTP still exists and that is typically correct :wink:

1 Like

Which would be the ClientHandler(s).

As long as enough think it’s still within the time period (and otherwise valid), the request would be fulfilled.

The reality is this sort of caveat won’t be offering precise accuracy. Similar to how revoking a token or app’s access isn’t guaranteed to be instantaneous.

ClientHandlers all need to get the relevant data to assess a token’s validity. Their local time could be one facet. Other network data (if the publicKey is still valid, eg,) may be required too.

This should be more than accurate enough for purpose.

2 Likes

Can you elaborate the limitations that prevent usage of standard macaroons?

2 Likes

The validation is built assuming the validator is the issuer. And so requires the secret key used to sign the macaroon. Which would mean any client handler would be able to mint their own macaroons. :frowning:

There’s a paper (away from comp for a few days so don’t have the link, though it’s from the forum…somewhere ) over paper proposing bls macaroons, but they themselves are more complex and don’t permit attenuation (and also there’s no standard impl).

3 Likes

I agree, macaroons cannot be used without this!

Just to be sure I understand correctly:

  • The issuer is the owner of the labels applied to data
  • He cannot validate macaroons, simply because he isn’t always online to validate the chain of caveats

But I am not sure about the latter point: For labels created for data sharing, would it be really unpractical to enable sharing only while the owning user is online?

In this case macaroons show a difficulty because the owner’s daemon would have to be polled via the address of his account in XOR space, but I think they could still be viable:

  • This would make sense security wise, because the chain of caveats is directly verified by the owner, without secret key delegation
  • This could be compared to a web site in clear net that becomes inaccessible when its authorization service is out
  • For labels applied on private data, offline owners wouldn’t create a breach of perpetual web
  • The rules are:
    • public data are always accessible
    • private data have restrictions to be accessible by other users: create labels (or other caveats) and stay online
  • The user himself doesn’t need to remain online, he only needs to have a daemon running somewhere.

A simple use case example with macaroons in these conditions:

  • I create a label L on some data
  • I create a macaroon. The location field is initialized with my account id (needed for communication to my client manager)
  • I create a first caveat to allow reading of L data
  • I don’t find this is restricted enough so I add a second caveat that only allows reading for 2 hours
  • For an even more restricted macaroon, I also create a third caveat that only allows reading by a specific account id
  • I send the final macaroon with the 3 caveats to the user owning this account
  • When this user wants to get one of these data, his client manager must pass this macaroon to my client manager which, in turn, will ask my running daemon to validate the macaroon
  • My client manager will then return the validity response to his client manager. Response will be invalid if 2 hours have elapsed, label of data isn’t L or account id isn’t the right one.

The daemon will be able to do validation using the PC time and a set of input data, in my example:

  • Requested data id (the set of applied label names is derived from it)
  • Requester id (for restriction to a specific user)

I would like your comments on this proposal.

Also, how do you intend to implement such a use case in your proposal? I must confess it isn’t clear to me and a practical example would be welcomed.

1 Like