MarkM's solution for DWN won't work

11 views
Skip to first unread message

Alan Karp

unread,
Dec 10, 2022, 6:49:36 PM12/10/22
to <friam@googlegroups.com>
because I was wrong in my description of the system.  I had said that a node receiving an update signs it and sends it to the other hosts.  That is wrong; it merely forwards the request as received.  Nodes do not need public keys and can't sign anything.  That leaves the problem, which I'll repeat for those who weren't there.  

A DWN (Distributed Web Node) is a cluster of a small number of nodes, say 4.  Access control is by signed certificates as capabilities.  A request received by one node is forwarded to the others.  Each node decides independently whether the included capability is valid for the request being made.

Now for the problem.  Say that Alice gives Bob a capability granting him authority to create records in one of Alice's directories.  How does Bob get a capability to edit/delete a record he creates?  MarkM's suggestion was for the node to create a capability that will only be valid if enough other nodes sign it.  If the hosts merely forward requests, they don't need the ability to sign anything.   That means there's no way they can create and sign a capability.

--------------
Alan Karp

Rob Meijer

unread,
Dec 11, 2022, 4:31:51 AM12/11/22
to Design
Maybe consider simply considering Allice's directory like a node in a rumpletree style DAG. 

Have a look at the POC ruplebox stuff in pyrumpletree.


The nodes will need to share a secret for capability decomposition if you use it like that. Attenuation is done client side.

Hope this is useful.




--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CANpA1Z37hm3DP%2BRwJ884sUkr5JmGf6_hNCiBfdyed8UW1kwVcA%40mail.gmail.com.

Alan Karp

unread,
Dec 18, 2022, 12:25:59 AM12/18/22
to fr...@googlegroups.com
I spent a little time looking at your link, but I don't see how it applies to this problem.

Part of the issue is that I don't fully understand the constraints the DWN design puts on the storage hosts.  I clearly have more to learn.

--------------
Alan Karp


Ben Laurie

unread,
Dec 18, 2022, 5:59:35 AM12/18/22
to fr...@googlegroups.com
On Sun, 18 Dec 2022 at 05:26, Alan Karp <alan...@gmail.com> wrote:
I spent a little time looking at your link, but I don't see how it applies to this problem.

Part of the issue is that I don't fully understand the constraints the DWN design puts on the storage hosts.  I clearly have more to learn.

Is there a description of this design somewhere?
 

Alan Karp

unread,
Dec 18, 2022, 1:50:34 PM12/18/22
to fr...@googlegroups.com

Rob Meijer

unread,
Dec 20, 2022, 4:03:50 AM12/20/22
to fr...@googlegroups.com
If the problem is 

"Say that Alice gives Bob a capability granting him authority to create records in one of Alice's directories.  How does Bob get a capability to edit/delete a record he creates?"

Then if the capability given by allice to bob includes a designating rumpeltree r+w sparse-cap, a node can derive a  designating rumpeltree r+w sparse-cap for each of the records using a secret shared between the nodes.
When Bob asks a node to create a record, the result will be the sparse-cap part of the capability.  The provenance part of the caps would still be a different issue though. 

Hope this makes sense.

Alan Karp

unread,
Dec 20, 2022, 2:12:47 PM12/20/22
to fr...@googlegroups.com
That's close to what I was thinking.  I thought perhaps the node could return something akin to a sturdy ref to Bob.  Bob then could then send it to Alice and ask her to give him a capability for the new record.  However, the nodes are purposely kept very simple, so I need to learn if they are capable of such a thing.

--------------
Alan Karp


Baldur Jóhannsson

unread,
Dec 23, 2022, 1:54:46 PM12/23/22
to fr...@googlegroups.com
After perusing https://identity.foundation/decentralized-web-node/spec/
a bit I think I have an inkling on how this works.

Alice and Bob use their public nodes as incomming message store and
forward inboxes. And as a simple repositories.

What it looks like with Collections is that Bobs message to create a
record in one of Alices Collections contains an certificate granting
Bob (identified by a DID and that points to a public key of Bobs) the
ability to create records in that collection.

That record creation message is signed by one of Bobs public keys,
refered from Bobs DID.

Now Bob can refer to this record creation message, via the message id,
as the faunt of the authority to change or delete the record, or even
grant that authority to other principals identified by DIDs.

The messages changing or deleting must be signed by a private key of
Bobs, and refer to the record creation message as the faunt of that
authority. If Bob granted or delegated to someone or something else,
they must refer to that granting/delegation message as their faunt of
authority in their record change or deletion messages.

Anyone that gets these messages (or can optain copies) can follow
along, verify the sigintures and that the ‘actions’ in these messages
are actually permitted. Including the aforesaid nodes, and they can
then decide to either propagate the messages or not.

Sounds like something I could build with ActiveCapCerts and specified
semantics like these folks are doing.

One note though, this system of theirs leaks metadata like water through sieve.

Alan Karp

unread,
Dec 23, 2022, 9:03:25 PM12/23/22
to fr...@googlegroups.com
Close, but I don't think it quite works.  Bob requests that a new record be created.  He clearly doesn't have a designation for a record that doesn't exist yet.  How can his request be used as a capability?

--------------
Alan Karp


Reply all
Reply to author
Forward
0 new messages