Add protocol update action

[diehuxx]

The update action allows an actor to update an existing record. This contrasts with the write action which allows only the creator of a record to update it. In other words:

1. write allows a DID to create a record and update the record they have created
2. update allows a DID to update a record, regardless of initial author

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[alanhkarp]

Is this distinction necessary? Can't you just use capabilities for this?

Say that Alice creates some record. As I understand it, the DWN node can't create a capability to return to her, but it does know she is the owner. That means Alice can create a "write" capability that she can use. She can also delegate that capability to someone else.

The upshot is that you only need one "write" method at the expense of the owner having to create a root capability. An added advantage is that Alice won't be vulnerable to a confused deputy attack as she would be if she used her ambient authority.

[thehenrytsai]

LGTM and test coverage is super thorough!! Just a few superficial comment.

[diehuxx]

#569 (comment)

@csuwildcat Any thoughts?

[codecov-commenter]

Codecov Report

Merging #569 (59c674f) into main (e5a1a31) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #569   +/-   ##
=======================================
  Coverage   97.70%   97.70%           
=======================================
  Files          66       66           
  Lines        7757     7769   +12     
  Branches     1129     1132    +3     
=======================================
+ Hits         7579     7591   +12     
  Misses        170      170           
  Partials        8        8           

Files	Coverage Δ
src/core/protocol-authorization.ts	98.45% <100.00%> (-0.02%)	⬇️
src/interfaces/records-write.ts	100.00% <100.00%> (ø)

[LiranCohen]

@alanhkarp

That means Alice can create a "write" capability that she can use. She can also delegate that capability to someone else.

Yes, you could technically build the same type of behavior with delegation for other aspects of the protocol rules, but it would be difficult to enforce these as a 'protocol' with other implementations.

Say you have a protocol with the following rules:

1. anyone can create a post.
2. anyone can add a post/tag to existing posts.
3. the did who created the post can edit any post/tag relating to the post they created.

Instead of each implementation of this social protocol front-end app explicitly delegating the write capability of the post/tag they created to the author of the post, the protocol rules handle this.

[LiranCohen]

LGTM!

[alanhkarp]

@LiranCohen

@alanhkarp

That means Alice can create a "write" capability that she can use. She can also delegate that capability to someone else.

Yes, you could technically build the same type of behavior with delegation for other aspects of the protocol rules, but it would be difficult to enforce these as a 'protocol' with other implementations.

Say you have a protocol with the following rules:

1. anyone can create a post.
2. anyone can add a post/tag to existing posts.

In that case, allow the creator of the post to specify that no capability is needed to add a post/tag to the post.

3. the did who created the post can edit any post/tag relating to the post they created.

Using the did of the creator of the post is effectively using an access control list. (The same goes for using Roles as I pointed out in another issue.) It's not as bad a a pure ACL system, since Alice can create a capability when she wants to delegate some of her rights. The risk, though, is a confused deputy vulnerability.

[csuwildcat]

@diehuxx looks good to me