using (var appSignPkH = await _session.Crypto.AppPubSignKeyAsync())
await _session.MDataPermissions.InsertAsync(permissionsHandle, appSignPkH, GetFullPermissions());
Can we keep adding to the permissions handle? I.e. adding, appSignPkH_0, appSignPkH_1 and appSignPkH_n with different permission sets?
If I want to give the access to some other user, do I need to get the _session.Crypto.AppPubSignKeyAsync() from that user? I.e. that user calls _session.Crypto.AppPubSignKeyAsync(), then passes it to _session.Crypto.SignPubKeyGetAsync(pubSignKey) to get the raw bytes, and sends it to me?
This, to me seems to imply that the permission to a specific mutable data instance, is given per App-User basis. So if User_A creates a SafeApp.Session through App_0, that gives appSignPk_A0, and if same user creates a session through App_1, that is a distinct key, i.e. appSignPk_A1?
Is there a way to give permission to a user through any app?
I deleted previous post to keep the questions more focused.
So, follow up questions to OT:
If I use _session.MDataInfoActions.EncryptEntryKeyAsync and equivalent for EntryValue, I assume any user with Read permission added to the MD, is able to read it? (Is there one encrypted copy of the entry key/value per user then?).
Yes, as long as permissions handle is not freed(garbage collected).
If I want to give the access to some other user, do I need to get the _session.Crypto.AppPubSignKeyAsync() from that user? I.e. that user calls _session.Crypto.AppPubSignKeyAsync() , then passes it to _session.Crypto.SignPubKeyGetAsync(pubSignKey) to get the raw bytes, and sends it to me?
Yes. This will add the permission for that particular application (for which key was used) for the user (from whom you got the key).
This, to me seems to imply that the permission to a specific mutable data instance, is given per App-User basis. So if User_A creates a SafeApp.Session through App_0 , that gives appSignPk_A0 , and if same user creates a session through App_1 , that is a distinct key, i.e. appSignPk_A1 ?
Yes. Permissions are based on the app-user basis. Every app has a separate AppPublicSignKey.
Is there a way to give permission to a user through any app?
The keys used to encrypt/decrypt are not stored on the network. The keys are a part of MdInfo object so as long as anybody has the mdinfo for a mutable data, they will be able to read the data.
Also, there are not multiple copies with different encryption keys. All the copies are encrypted using the same key pair.
Yes, if you add permissions for any other user to read the data then you need to share the keys, location and typetag (mdinfo) otherwise they will not be able to make sense of the data(as they can access but can’t decrypt).
And also other way around; they can have the keys, but not the permissions to read.
This one is tricky, because if you have mdinfo(containing XORName, TypeTag and Keys) then you’ll be able to read the data irrespective of whether you have the read permission or not.
With capability based access control, permissions wouldn’t need to be stored on the network at all and delegation (to apps or to other users) would also be solved.
Giving access would be done on the client-side. It’s just putting together a certificate and then giving it to the app or sending it to another user. They can be restricted to a certain operation, to a certain holder, by time, or other requirements that can be implemented as they become needed. These are bearer credentials, kinda like your passport in real life, so they don’t need to be stored next to the object(s) they are referring to because they are expected to be presented together with the request.
Verifying access would be done on the nodes. It would be as a simple answer to the question: “Is this request consistent with the permissions the attached certificate provides?”
Simpler code, more flexibility. Here’s a video from the 2017 Rust Bay Area Meetup about “Macaroons”, a really good implementation of capability based security:
Slides for the talk:
Disclaimer: I’ve been spamming the other forum about this for a while (see for example SAFE Network Dev Update - March 28, 2019 - #55 by JoeSmithJr - Updates - Autonomi Forum (Safe)) because I believe well thought-out access control is crucial to something that has security and privacy in its core. I’m fully convinced rolling with ACLs just because they became the historic de-facto standard is not the right decision. After all, ACLs were chosen by people who had to implement security even though they had no idea about how to implement security…
Sorry, I didn’t think it was confusing, but now I see it can be.
There would be no metadata about access control stored with the network objects.
The certificates or credentials would be stored as regular data, just a part of the user’s other stuff.
Please note there’s no “Catch 22” because the primary account’s private key is derived from the login credentials (if I’m correct) and a private key is the ultimate credential, all others being restricted versions thereof.
Hi @JoeSmithJr, I was reading about macaroons, they do sound very interesting, and I’m trying to understand and/or confirm something, don’t they need the secret to be shared in order to be able to verify a macaroon that was included in a request?
I’m a bit confused since that’s what I’m reading, and if that’s correct, we wouldn’t be able to have the vaults/nodes/personas to verify the macaroon since they don’t have the secret. Can you help me understand what I’m missing?
Yes, exactly. They are based on public key cryptography so the signatures can be verified using the id (which I think is the public key) without knowing the secret private key.
The coolest thing is that they do away with access related metadata stored with the objects. Also, at least in the simple case when we’re not using 3rd-party caveats (and this covers all that’s been covered by the already existing access control), a decision about a request can be decided just by looking at a) the ownership of the object and b) the credentials attached to the request (that is, without cross-referencing anything else).
