Just an idea that popped while i was reading https://github.com/solid/solid-architecture/blob/master/server/request-flow.md.

https://tools.ietf.org/html/rfc7807 is pretty neat to standardize/structure error messages returned to clients and make it easier for them to interpret/handle the error details.

In a recent project, we integrated it and we found it really beneficial. You can find some docs and examples here (we've gone a bit further than what the RFC initially covered):

• https://github.com/NationalBankBelgium/REST-API-Design-Guide/wiki/Error-handling-Error-details
• example: https://github.com/NationalBankBelgium/REST-API-Design-Guide/wiki/Error-handling-Example-with-multiple-errors
• other related docs: https://github.com/NationalBankBelgium/REST-API-Design-Guide/wiki/Error-handling-About

If im completely honest, this architectural design is one step forward and two steps backwards.

The main reason is that it makes the mistake, that has been almost ubiquitous, of coupling together the concept of identity and authentication, namely, verification of that identity.

Without a doubt, this has been done many times before, and we inherit from that. For example in a TLS cert the identity (subject alternative name) is coupled to the validation of that certificate.

This is horrible architecture, horrible design, and does not occur in the slightest in any of the mass communication systems that humans have used throughout the ages.

@RubenVerborgh has challenged me to come up with use cases to realize this idea. And and I will try to do so. At this point in time however, this architecture for me, is a step backwards, or perhaps sideways. ie bikeshedding

Everything else about the design I am a massive fan of. I can see many new APIs added through this scheme. ie extensibility will be incredible!

I look forward to making compelling user stories that illustrate this idea. It may take some time. Enjoying the debate!

Hi!

https://github.com/solid/solid-architecture/blob/master/server/request-flow.md#step-2-parse-the-request-to-the-personal-data-store mentions required permissions are Read, Write, Append, and/or Delete, based on method, and in case of PATCH, body. I'm guessing that means GET, HEAD need Read, OPTIONS needs nothing (?), POST and PUT need Append+Write, PATCH needs Append or Append+Write, and DELETE needs Delete.

But https://github.com/solid/web-access-control-spec#modes-of-access mentions Read, Write, Append, Control.

How do these relate? I'm guessing Delete translates to Write?
And shouldn't there also be http requests for which the required permissions are acl:Control?
Also, when PUT or POST cause the creation of a new resource, WAC describes that as Append, and not Append+Write.

Is there a document (or should we start one) specifying in more detail how the required permissons (in terms of exact WAC modes) for a http request can be determined?