I see what you are imagining now, sounds good, but I’d say that’s just an app to be created and separate from main/core logic, in fact such gateway app can just be authorised by the authenticator once, as any other app, and do all that with macaroon attenuations and so on.
Hi all, happy new year!
Apologies for the slight digression, just got a question about specific use cases rather than technicalities of implementation, but keen to ask it as it affects my immediate next steps!
If I’m following right, this proposal allows Data to be permissioned according to the app that is reading/writing/editing it, rather than the account. Therefore, we have the possibility of communally owned and edited Data objects which can be fairly strictly regulated by the inherent limitations of the permissioned app.
If this is case, I think that particular use case would be hugely useful for a lot of ideas for apps that I’ve had, and it in effect enables a form of decentralised computing.
As an example, without wishing to hijack the thread, referring to the earlier conversation we had about a search app @joshuef, it would potentially enable a single set of search index ADs to be communally owned and updated, which I think would tick all the boxes for both efficiency and decentralisation.
Would this seem to be a correct understanding?
Happy new year @david-beinn!
Right. A label is made per-app. That can be applied at a specific permission level to data.
The permissions on the data don’t have to be tied to an app. You can just make a label
communal-data and apply that to the data you want to share, at the permission level you want to allow. Then share the token/
LabelKeyShare (however that ends up working, that part is most in flux, but definitely possible, however the impl), among those you want to grant access.
I think so yeh!
Thanks Josh, that’s great news. I’ll post an update over on the search app thread later in the week cos I think it makes a lot of useful things possible in that respect. In fact I think this whole labels thing makes a lot of great things possible full stop, and all in one fell swoop!
Just to be clear, I was suggesting that having the permissions tied to an app was actually what I was looking for. If the identity and security of an app can be verified, then we can trust anyone to run that app to write to a piece of data, because the nature of the app will be such that they can’t just add spam, or meddle with the data in a destructive way, or whatever. Therefore we open the door for everyone to contribute to the sum of knowledge etc etc.
Aha. That’s probably getting into tying permissions to versions of data. Which is something that should be possible in certain environments (eg the browser). We just haven’t got anything nailed down there yet
Hmmm. That wasn’t necessarily my first thought as being a problem, but maybe it’s a good example of what I was thinking of.
Say it’s written into the logic of the app that it always writes to the latest version of a piece of data. My worry would be whether it’s easy for someone to somehow circumvent or change that logic, whilst still using the app’s security credentials. Does that make sense? Would the macaroons idea take care of that? Would the potential for malice be easier to control in a web app?
The idea above could tie tokens to an app’s running version eg. But that’s only as secure as the environment it runs in. Generally, you’d want to make your app resilient against bad/corrupt data always, as there’s no guarantee, if folk really want to extract a token from a valid app, it’s probbably going to be possible.
As far as ‘always write to the latest version’, well that would be a form of appendable / sequenced data, which will prevent any writes to earlier versions of data for you. And that is guaranteed.
Yeah, that’s what I was figuring.
I think it should be good enough to proceed for now though along the lines I was thinking of (I mean good enough for the medium term - I’m aware it’s not even built yet!)
Perhaps the time restriction/tokens expiring would also help quite a lot in making the system more difficult to extract tokens from.
Just now I was thinking along the lines of web apps anyway, but would the browser be considered a relatively secure environment (subject to the js running within it being secure?)
Ufff, yes. And no. Nothing stopping someone building it themselves. Secure for a person yeh, if they download an official version. Secure in terms of data put via the browser to the network can be guaranteed… Less.
I think out apps will have to work with the idea of spam at some point. If you’re enabling anyone to write, I’d wager we’ll see some nonsense. Hopefully with there being a cost associated with that, such spam will be minimal…
We’re probably getting reasonably off-topic here, @david-beinn, so perhaps we should make a thread for this?
Yeah, no worries, sorry, just wanted to explore what the labels idea could enable.
Certainly really helpful for me to realise the possibilities and limitations security-wise, and I think you’re confirming what I’d originally guessed that it’s hard to make the sort of thing I had in mind watertight even with labelled data/macaroons, but I didn’t have the knowledge to confirm that.
Thanks for the pointers, really appreciate your taking the time!
Was chatting with @lionel.faber this morning and he pointed out something that’s not specified above:
Apps will still need sign keys to ensure requests are not tampered with en route to CH and to vaults.
Ill add this to OP on my next pass through.
Not in my proposal. Instead apps only have macaroons and requests are signed by the local authenticator daemon (when macaroons pass verification).
But then apps using this gateway app wouldn’t be standard apps! Furthermore this is not a gateway that I imagine but just a validating/signing daemon (to avoid the bottleneck of earlier authenticator mentioned by @joshuef).
All requests (from who knows how many apps) going through one application. That sounds like a bottleneck to me…
If that daemon crashes? Stalls? Is malicious?
@tfa, With the OP RFC, such a bottleneck / all-signing-application is not required. Plus we get all the benefits of macroons with our asymmetric key macaroon-like implementation. I’m not sure why you’re so keen on the pure-macaroon, auth-daemon-signer approach, with the limitations it has? You said above that the RFC flow / my update post wasn’t clear to you, so can you elaborate on what’s unclear/what problems you’re seeing in the RFC? I think it’ll be helpful in getting us in the same page.
Is there a possibility that you put links to info on all required topics in “Assumptions” section?
I’ve updated with a couple of links. A lot is not concrete though, so would be a mix of the safe-primer, and forum reading.
Eg, I dont think we’ve a concrete explanation or RFC for the ‘containers’ idea. But the general background was that there was preiviously a fixed set of mutable data, ‘containers’ (for photos, documents, eg), in the accounts root. And that apps could request permission to store things in these, but otherwise there was no method of sharing/discovering data between apps. Apps also had their own, exclusive, unshareable container too.
Hope that helps @loziniak, any more Qs just shout and I’ll do my best to answer
Thanks very much, @joshuef! Probably a little late, but starting to digest that
@joshuef, you mention
Authenticator in “Assumptions” section, but there is no mention about them in the Primer. What are they, actually? Are these class names from a source code?
DataHandler are modules of a vault when it is an
Authenticator is a service and app in itself.
ClientHandler code validates requests before sending them to nodes to perform those requests. (Ie, we check if the app has permission to do XYZ.
DataHandler has the data (teh client handler cannot see this), and checks final permission on the data itself for a given request, and returns it.
Authenticator is the user-space application which controls the account, provides application’s with credentials to work on the network (currently keys which are checked at CH, the proposal changes that to be bearer-token based)
I’ve updated the OP with the following:
- Added examples of label flow for token issuing / authorization of labels on data.
- Add a second SharedToken idea, so not tied to data controlled by issuer per-se.
- Improved Summary
- Added some thoughts on async token re-issue
I’ll likely separate out a
Token RFC from this, as that’s where we’re starting to focus. And that should make it clearer to understand token logic in general