Append no container for resources creation not reflected in current text

[RubenVerborgh]

The consensus in https://github.com/solid/specification/issues/14#issuecomment-683480525 seems to be that at least Append on the container C is necessary (and Write on the resource R) when creating C/R.

However, this is not reflected in the current text, which states:

When an operation requests to create a resource as a member of a container resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege (as needed by the operation) on the resource to be created.

I might have introduced that problem myself in #95 in an attempt to clarify the original language, which stated:

[…] acl:Append or acl:Write access privilege on the container for new members.

Perhaps the correct clarification of "on the container for new members" was "on the container" (instead of "on the resource to be created"), which would be consistent with https://github.com/solid/specification/issues/14#issuecomment-683480525

Then, however, the next sentence:

When an operation requests to update a resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the resource.

might need to use "write" instead of "update", to cover the needed permissions on the resource itself. However, this leaves the case of POST, where you only need permissions on the container.

In any case, the language differs from the delete statement, where two authorizations are clearly requested. Perhaps we want to align the language there.

---

(Separately to this, I do think this particular sentence is problematic because of #97.)

[elf-pavlik]

However, this leaves the case of POST, where you only need permissions on the container.

Solid Application Interoperability makes minimal use of LDN inbox, used as access inbox. It is only used before agents establish reciprocal Social Agent Registrations and create Solid Notifications subscriptions (switching to an 'outbox' approach).

I don't see how the access should be set on the Container used as the Access Inbox, we have the following expectations:

LDN Sender is any acl:AuthenticatedAgent

• LDN Sender CAN only create a new resource in the container
• LDN Sender CAN NOT modify description of the container, so no statements added by the LDN Sender
• LDN Sender CAN NOT modify any of created resources, including those created by them

While statement with ldp:contains is added to the description of the container, they are not added by the client and the client is not the party modifying the container description.

In other words

• an authenticated POST request from LDN Sender to https://alice.spamshield.example/accessInbox/ should be allowed
• an authenticated PATCH request from LDN Sender to https://alice.spamshield.example/accessInbox/ should NOT be allowed, even if it only includes INSERT (DATA) (sparql-update) or ?patch solid:inserts ?insertions. (n3-patch)