Is WAC-Allow part of the solid spec?

[Otto-AA]

I've seen that the node-solid-server implemented a WAC-Allow header for identifying which access is granted for the requested resource. Is this also part of the solid api spec, or just a feature of this specific implementation?

Related issue in NSS: nodeSolidServer/node-solid-server#246

[csarven]

It will be briefly picked up by the Solid Ecosystem: https://github.com/solid/specification and probably in/through App Authorization Panel: https://github.com/solid/app-authorization-panel/

In the meantime, I'd suggest further implementation experience (based off servers and apps built by different parties), as well as UCs.

I suggest following up in those repos/groups for ongoing work.

If this answer is satisfactory, please feel free to close this issue.

[RubenVerborgh]

It is in the current draft spec at https://github.com/solid/solid-spec/blob/103b1e027356bd525e4cad0138e8288f4881df39/api-rest.md#wac-allow-headers

As @csarven says, will be discussed in https://github.com/solid/specification. Some people (like myself, even though I wrote it) are not in favor of this header.

[csarven]

dokieli may be partly to blame on having an application detect what's "writable" before performing a write operation (use cases: dokieli/dokieli#96 , dokieli/dokieli#137 and bugging @dmitrizagidulin endlessly), but not necessarily the exact implementation of it :)

I don't particularly like a one-off header for this either.. or parsing the header value like in WAC-Allow. Should be simpler and easily extensible right?

[Otto-AA]

Has there been an update on this? I didn't find the discussion on solid/specification.

[csarven]

Thanks @Otto-AA for the reminder. Moving this issue to solid/specification for further consideration. I think we acknowledge at least one case where applications can be more efficient. Whether the solution lies on WAC-Allow and exactly how is something we can also review in context of other affordances.

[RubenVerborgh]

Let's also have an issue for the problem; as this is just one possible solution. Other solutions include the Link header.

[csarven]

Transferred #171 as the original problem.

[csarven]

Proposal/requirements merged via PR #210 . See further details/discussion on concerns of this header, as well as use cases for different permission groups. Implementation feedback is always useful/welcome. Please follow up with new issues/proposals.