# Specification: https://solidproject.org/TR/protocol

Requirement: https://solidproject.org/TR/protocol#client-wac
Requirement subjectClient
Requirement levelMUST
StatementClients MUST conform to the Web Access Control specification [WAC].
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-http-11
Requirement subjectServer
Requirement levelMUST
StatementServers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231].
No test cases found.
* Check server can respond with HTTP1.1
* Core HTTP interactions in separate test suite - add comment to test

## Requirement: https://solidproject.org/TR/protocol#server-http-2
Requirement subjectServer
Requirement level
StatementServers SHOULD conform to HTTP/2 [RFC7540].
No test cases found.
* Send HTTP/2 and see if response is HTTP/2

## Requirement: https://solidproject.org/TR/protocol#server-tls-https
Requirement subjectServer
Requirement level
StatementServers SHOULD use TLS connections through the https URI scheme in order to secure the communication with clients.
No test cases found.
* After connection, check the SSL method - is it TLS

## Requirement: https://solidproject.org/TR/protocol#server-tls-https-redirect
Requirement subjectServer
Requirement levelMUST
StatementWhen both http and https URI schemes are supported, the server MUST redirect all http URIs to their https counterparts using a response with a 301 status code and a Location header.
No test cases found.
* Send http request. Either no connection or 301 + Location
* REVIEW REQUIREMENT: e.g. http only, https only OR is http a minimum

## Requirement: https://solidproject.org/TR/protocol#server-conditional-requests
Requirement subjectServer
Requirement levelMUST
StatementServers MUST conform to HTTP/1.1 Conditional Requests [RFC7232].
Test cases
Title Details Implemented
Create: PUT Turtle resources to container with If-None-Match: * headers. [manifest] [source] [requirement]
StatusUnreviewed
✔

## Requirement: https://solidproject.org/TR/protocol#server-caching
Requirement subjectServer
Requirement level
StatementServers SHOULD conform to HTTP/1.1 Caching [RFC7234].
No test cases found.
* Simple test for presence of headers such as cache-control
* What about issues with RDF representations of the same resource?

## Requirement: https://solidproject.org/TR/protocol#server-range-requests
Requirement subjectServer
Requirement level
StatementServers MAY conform to HTTP/1.1 Range Requests [RFC7233].
No test cases found.
* Simple test for range headers

## Requirement: https://solidproject.org/TR/protocol#server-authentication
Requirement subjectServer
Requirement levelMUST
StatementServers MUST conform to HTTP/1.1 Authentication [RFC7235].
Test cases
Title Details Implemented
Test that unauthenticated users get the correct response [manifest] [source] [requirement]
StatusApproved
✔
## Requirement: https://solidproject.org/TR/protocol#server-unauthenticated
Requirement subjectServer
Requirement levelMUST
StatementWhen a client does not provide valid credentials when requesting a resource that requires it (see WebID), servers MUST send a response with a 401 status code (unless 404 is preferred for security reasons).
Test cases
Title Details Implemented
Test that unauthenticated users get the correct response [manifest] [source] [requirement]
StatusApproved
✔
## Requirement: https://solidproject.org/TR/protocol#server-content-type
Requirement subjectServer
Requirement levelMUST
StatementServer MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400.
Test cases
Title Details Implemented
Server MUST reject write requests without Content-Type [manifest] [source] [requirement]
StatusUnreviewed
✔
Requirement: https://solidproject.org/TR/protocol#client-http-11
Requirement subjectClient
Requirement levelMUST
StatementClients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231].
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-http-2
Requirement subjectClient
Requirement level
StatementClients MAY conform to HTTP/2 [RFC7540].
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-conditional-requests
Requirement subjectClient
Requirement level
StatementClients MAY conform to HTTP/1.1 Conditional Requests [RFC7232].
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-caching
Requirement subjectClient
Requirement level
StatementClients MAY conform to HTTP/1.1 Caching [RFC7234].
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-range-requests
Requirement subjectClient
Requirement level
StatementClients MAY conform to HTTP/1.1 Range Requests [RFC7233].
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-authentication
Requirement subjectClient
Requirement levelMUST
StatementClients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID).
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-authentication-different-credentials
Requirement subjectClient
Requirement level
StatementWhen a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-content-type
Requirement subjectClient
Requirement levelMUST
StatementClients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231].
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-uri-trailing-slash-distinct
Requirement subjectServer
Requirement levelMUST NOT
StatementIf two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource.
Test cases
Title Details Implemented
With and without trailing slash cannot co-exist [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-uri-redirect-differing
Requirement subjectServer
Requirement level
StatementInstead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.
Test cases
Title Details Implemented
With and without trailing slash cannot co-exist [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-authorization-redirect
Requirement subjectServer
Requirement levelMUST
StatementServers MUST authorize prior to this optional redirect.
No test cases found.
* If there is a slash redirect on authorized requests, then an unauthorized request with a slash difference should get 403 where authorized gets 301
* REVIEW REQUIREMENT - in light of dependency on previous

## Requirement: https://solidproject.org/TR/protocol#server-storage
Requirement subjectServer
Requirement levelMUST
StatementServers MUST provide one or more storages (pim:Storage) – a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).
No test cases found.
* Create deep resource, walk tree and confirm you find the storage

## Requirement: https://solidproject.org/TR/protocol#server-storage-nonoverlapping
Requirement subjectServer
Requirement levelMUST
StatementWhen a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.
No test cases found.
* Having found the storage, there are no higher level storages
* We cannot prove that a server could not break this requirement
* Can a server respond to a PUT of a container with a pim:Storage link

Experimenting. See also: https://github.com/solid/specification/issues/317

/foo/ is pim:Storage

PUT /bar/
Link: rel=type pim:Storage

Currently:
403.


/foo/ exists

PUT /foo/bar/
Link: rel=type pim:Storage

Currently:
201 Creates container (and ignores Link).
OR
400 or 403 Bad Request

Note in the manifest that the requirement is untestable by a property (spec:untestable) and then add an rdfs:comment to explain it. Then the harness could mark it as untested but covered

## Requirement: https://solidproject.org/TR/protocol#server-link-storage
Requirement subjectServer
Requirement levelMUST
StatementServers exposing the storage resource MUST advertise by including the HTTP Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage when responding to storage’s request URI.
No test cases found.
* Link to #server-storage test

Requirement: https://solidproject.org/TR/protocol#client-link-storage
Requirement subject
Requirement level
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-storage-discovery
Requirement subject
Requirement level
No test cases found.

Requirement: https://solidproject.org/TR/protocol#client-rdf-storage
Requirement subject
Requirement level
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-storage-track-owner
Requirement subjectServer
Requirement levelMUST
StatementServers MUST keep track of at least one owner of a storage in an implementation defined way.
No test cases found.
* Depends on resolving storage description discussion
* Untested for now, manifest notes that.
* Could support different methods and tag the scenarios to allow test to run against different server

## Requirement: https://solidproject.org/TR/protocol#server-storage-link-owner
Requirement subjectServer
Requirement levelMUST
StatementWhen a server wants to advertise the owner of a storage, the server MUST include the Link header with rel="http://www.w3.org/ns/solid/terms#owner" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container.
No test cases found.
* Depends on resolving server/storage description: https://github.com/solid/specification/issues/355
* Untested for now, manifest notes that.
* REVIEW REQUIREMENT: Make it a SHOULD or MAY rather than "When"

## Requirement: https://solidproject.org/TR/protocol#server-basic-container
Requirement subjectServer
Requirement levelMUST
StatementThe representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server.
No test cases found.
* We use ldp:contains and POST for container requires rel type container. Creating foo/ must create a container and the response must be text/turtle (201 or 415...)
* REVIEW REQUIREMENT
* Important to test well
https://www.w3.org/2001/tag/doc/mime-respect#dav-scenario

## Requirement: https://solidproject.org/TR/protocol#server-contained-resource-metadata
Requirement subjectServer
Requirement level
StatementServers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.
No test cases found.
* is there any metadata - mtime etc

Requirement: https://solidproject.org/TR/protocol#client-link-auxiliary-type
Requirement subject
Requirement level
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-description-resource-max
Requirement subjectServer
Requirement levelMUST NOT
StatementServers MUST NOT directly associate more than one description resource to a subject resource.
Test cases
Title Details Implemented
Server may link to one description resource [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-description-resource-authorization
Requirement subjectServer
Requirement levelMUST
StatementWhen an HTTP request targets a description resource, the server MUST apply the authorization rule that is used for the subject resource with which the description resource is associated.
No test cases found.
* `describedBy` is optional so may not be tested yet
* Test should be ok
* Merge [PR 372?](https://github.com/solid/specification/pull/372) .
* PE to add a review to PR372

Requirement: https://solidproject.org/TR/protocol#client-link-describes
Requirement subject
Requirement level
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-method-not-allowed
Requirement subjectServer
Requirement levelMUST
StatementServers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource.
Test cases
Title Details Implemented
Error for unsupported method [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-put-patch-uri-assignment
Requirement subjectServer
Requirement levelMUST
StatementWhen a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.
Test cases
Title Details Implemented
Server assigns URI based on effective request URI [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-post-uri-assignment
Requirement subjectServer
Requirement levelMUST
StatementWhen a successful POST request creates a resource, the server MUST assign a URI to that resource.
Test cases
Title Details Implemented
Assignment of URIs for POST requests [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-slug-uri-assignment
Requirement subjectServer
Requirement level
StatementServers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].
Test cases
Title Details Implemented
Assignment of URIs for POST requests with Slug [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-safe-methods
Requirement subjectServer
Requirement levelMUST
StatementServers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options.
No test cases found.
* At a minimum, these methods must not return 405 but we expect more than that
* https://github.com/solid/specification-tests/pull/62
* GET returns a body
* HEAD returns headers
* OPTIONS returns headers

## Requirement: https://solidproject.org/TR/protocol#server-allow-methods
Requirement subjectServer
Requirement levelMUST
StatementServers MUST indicate their support for HTTP Methods by responding to HTTP GET and HEAD requests for the target resource with the HTTP Method tokens in the HTTP response header Allow.
Test cases
Title Details Implemented
Servers MUST return Allow for GET and HEAD [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-accept-headers
Requirement subjectServer
Requirement levelMUST
StatementServers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests.
No test cases found.
* Simple tests

## Requirement: https://solidproject.org/TR/protocol#server-options-asterisk-accept-headers
Requirement subjectServer
Requirement level
StatementServers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.
No test cases found.
* Simple tests

## Requirement: https://solidproject.org/TR/protocol#server-put-patch-intermediate-containers
Requirement subjectServer
Requirement levelMUST
StatementServers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests.
Test cases
Title Details Implemented
Creating a resource using PUT and PATCH must create intermediate containers [manifest] [source] [requirement]
StatusApproved
✔
## Requirement: https://solidproject.org/TR/protocol#server-post-container
Requirement subjectServer
Requirement levelMUST
StatementServers MUST allow creating new resources with a POST request to URI path ending /.
No test cases found.
* Simple tests for 2xx/301 response

## Requirement: https://solidproject.org/TR/protocol#server-post-container-create-resource
Requirement subjectServer
Requirement levelMUST
StatementServers MUST create a resource with URI path ending /{id} in container /.
No test cases found.
* The spec should explain what {id} means
* POST with and without slug

## Requirement: https://solidproject.org/TR/protocol#server-post-container-create-container
Requirement subjectServer
Requirement levelMUST
StatementServers MUST create a container with URI path ending /{id}/ in container / for requests including the HTTP Link header with rel="type" targeting a valid LDP container type.
No test cases found.
* POST with and without slug and check location has /

## Requirement: https://solidproject.org/TR/protocol#server-post-target-not-found
Requirement subjectServer
Requirement levelMUST
StatementWhen a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code.
Test cases
Title Details Implemented
POST to non-existing resource must result in 404 [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-put-patch-auxiliary-resource
Requirement subjectServer
Requirement levelMUST
StatementWhen a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it.
No test cases found.
**https://github.com/solid/specification-tests/pull/66**

## Requirement: https://solidproject.org/TR/protocol#server-post-slug-auxiliary-resource
Requirement subjectServer
Requirement levelMUST
StatementWhen a POST method request with the Slug header targets an auxiliary resource, the server MUST respond with the 403 status code and response body describing the error.
No test cases found.
* Res = /foo, discover /fooaux
* POST /fooaux Slug=x - 403
* Note POST /fooaux (no slug) is undefined at present

## Requirement: https://solidproject.org/TR/protocol#server-protect-containment
Requirement subjectServer
Requirement levelMUST NOT
StatementServers MUST NOT allow HTTP PUT or PATCH on a container to update its containment triples; if the server receives such a request, it MUST respond with a 409 status code.
No test cases found.
* **https://github.com/solid/specification-tests/pull/66**
[check get-put works, and modify get before put 409]
* REVIEW REQUIREMENT - why not: Servers MUST respond with a 409 code if it receives a HTTP PUT or PATCH request on a container to update its containment triples

## Requirement: https://solidproject.org/TR/protocol#server-protect-contained-resource-metadata
Requirement subjectServer
Requirement levelMUST NOT
StatementServers MUST NOT allow HTTP POST, PUT and PATCH to update a container’s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code.
No test cases found.
* check get-put works, and modify get before put 409]
* REVIEW REQUIREMENT - why not: Servers MUST respond with a 409 code if it receives a HTTP POST, PUT and PATCH request update a container’s resource metadata statements
* REVIEW REQUIREMENT - surely POST does not apply since it creates resources and the payload is the resource not the containment triples

## Requirement: https://solidproject.org/TR/protocol#server-etag
Requirement subjectServer
Requirement level
StatementServers MAY use the HTTP ETag header with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the If-Match header in their requests.
No test cases found.
* Do If-Match with strong validator, meaning it must not be prefixed with w/ - and test with different RDF Accept headers

## Requirement: https://solidproject.org/TR/protocol#server-patch-n3-accept
Requirement subjectServer
Requirement levelMUST
StatementServers MUST accept a PATCH request with an N3 Patch body when the target of the request is an RDF document [RDF11-CONCEPTS].
No test cases found.
* OK but will fail most servers initially - cannot rely on Accept-Patch as proof we can run this in case that test along fails
* Could filter with a tag for implementors to decide if feature it to be tested

## Requirement: https://solidproject.org/TR/protocol#server-patch-n3-advertise
Requirement subjectServer
Requirement levelMUST
StatementServers MUST indicate support of N3 Patch by listing text/n3 as a value of the Accept-Patch header [RFC5789] of relevant responses.
No test cases found.
* See other N3 tests

## Requirement: https://solidproject.org/TR/protocol#server-patch-n3-invalid
Requirement subjectServer
Requirement levelMUST
StatementServers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.
No test cases found.
* See other N3 tests

## Requirement: https://solidproject.org/TR/protocol#server-n3-patch-where
Requirement subjectServer
Requirement levelMUST
StatementWhen ?conditions is non-empty, servers MUST treat the request as a Read operation.
No test cases found.
* See other N3 tests

## Requirement: https://solidproject.org/TR/protocol#server-n3-patch-insert
Requirement subjectServer
Requirement levelMUST
StatementWhen ?insertions is non-empty, servers MUST (also) treat the request as an Append operation.
No test cases found.
* See other N3 tests

## Requirement: https://solidproject.org/TR/protocol#server-n3-patch-delete
Requirement subjectServer
Requirement levelMUST
StatementWhen ?deletions is non-empty, servers MUST treat the request as a Read and Write operation.
No test cases found.
* See other N3 tests

## Requirement: https://solidproject.org/TR/protocol#server-patch-n3-semantics
Requirement subjectServer
Requirement levelMUST
StatementServers MUST process a patch resource against the target document as follows:
No test cases found.
* See other N3 tests

## Requirement: https://solidproject.org/TR/protocol#server-delete-protect-root-container
Requirement subjectServer
Requirement levelMUST
StatementWhen a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code.
No test cases found.
* Simple test but CTH may not have access to the root container to might receive 403 but the intention is for it to be 405 so test is OK
* Merging https://github.com/solid/specification/pull/353 would address the problem of authorization here in the general case

## Requirement: https://solidproject.org/TR/protocol#server-disallow-delete
Requirement subjectServer
Requirement levelMUST
StatementServer MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231].
No test cases found.
* As above

## Requirement: https://solidproject.org/TR/protocol#server-delete-remove-containment
Requirement subjectServer
Requirement levelMUST
StatementWhen a contained resource is deleted, the server MUST also remove the corresponding containment triple.
Test cases
Title Details Implemented
Delete containment triple when resource is deleted [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-delete-remove-auxiliary-resource
Requirement subjectServer
Requirement levelMUST
StatementWhen a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).
No test cases found.
* Simple test

## Requirement: https://solidproject.org/TR/protocol#server-delete-remove-empty-container
Requirement subjectServer
Requirement levelMUST
StatementWhen a DELETE request targets a container, the server MUST delete the container if it contains no resources.
No test cases found.
* Simple test

## Requirement: https://solidproject.org/TR/protocol#server-delete-protect-nonempty-container
Requirement subjectServer
Requirement levelMUST
StatementIf the container contains resources, the server MUST respond with the 409 status code and response body describing the error.
Test cases
Title Details Implemented
Server protects non-empty container [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solidproject.org/TR/protocol#server-representation-turtle-jsonld
Requirement subjectServer
Requirement levelMUST
StatementWhen a server creates a resource on HTTP PUT, POST or PATCH requests such that the request’s representation data encodes an RDF document [RDF11-CONCEPTS] (as determined by the Content-Type header), the server MUST accept GET requests on this resource when the value of the Accept header requests a representation in text/turtle or application/ld+json [Turtle] [JSON-LD11].
Test cases
Title Details Implemented
Requests support content negotiation for Turtle resource [manifest] [source] [requirement]
StatusApproved
✔
Requests support content negotiation for JSON-LD resource [manifest] [source] [requirement]
StatusApproved
✔
## Requirement: https://solidproject.org/TR/protocol#server-representation-write-redirect
Requirement subjectServer
Requirement levelMUST
StatementWhen a PUT, POST, PATCH or DELETE method request targets a representation URL that is different than the resource URL, the server MUST respond with a 307 or 308 status code and Location header specifying the preferred URI reference.
No test cases found.
* Manifest mark spec:untestable. We cannot tell in at the protocol interface whether something is a representation resource, and thus we can't tell whether the test failed or not.
* Even if it was testable, if a server implementation doesn't use representation URLs differing to resource URLs it is also untestable so we would use tags to control running the test

## Requirement: https://solidproject.org/TR/protocol#server-ldn
Requirement subjectServer
Requirement levelMUST
StatementA Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN].
No test cases found.
* Manifest mark spec:untestable. See LDN test suite

Requirement: https://solidproject.org/TR/protocol#client-ldn
Requirement subjectClient
Requirement levelMUST
StatementA Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [LDN].
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-websockets-api
Requirement subjectServer
Requirement level
StatementServers SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].
No test cases found.
* Manifest mark spec:untestable. See Notification panel's test suite

Requirement: https://solidproject.org/TR/protocol#client-websockets-api
Requirement subjectClient
Requirement level
StatementClients SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].
No test cases found.

## Requirement: https://solidproject.org/TR/protocol#server-cors
Requirement subjectServer
Requirement levelMUST
StatementA server MUST implement the CORS protocol [FETCH] such that, to the extent possible, the browser allows Solid apps to send any request and combination of request headers to the server, and the Solid app can read any response and response headers received from the server. If the server wishes to block access to a resource, this MUST NOT happen via CORS but MUST instead be communicated to the Solid app in the browser through HTTP status codes such as 401, 403, or 404 [RFC7231].
No test cases found.
* See https://github.com/solid/specification-tests/pull/72
* Test to confirm essential mechanisms work with all headers plus some evil tests?

## Requirement: https://solidproject.org/TR/protocol#server-cors-access-control-headers
Requirement subjectServer
Requirement levelMUST
Statementwhenever a server receives an HTTP request containing a valid Origin header [RFC6454], the server MUST respond with the appropriate Access-Control-* headers as specified in the CORS protocol [FETCH].
No test cases found.
* See https://github.com/solid/specification-tests/pull/72

## Requirement: https://solidproject.org/TR/protocol#server-cors-acao-vary
Requirement subjectServer
Requirement levelMUST
Statementthe server MUST set the Access-Control-Allow-Origin header to the valid Origin value from the request and list Origin in the Vary header value.
No test cases found.
* See https://github.com/solid/specification-tests/pull/72

## Requirement: https://solidproject.org/TR/protocol#server-cors-aceh
Requirement subjectServer
Requirement levelMUST
StatementThe server MUST make all used response headers readable for the Solid app through Access-Control-Expose-Headers (with the possible exception of the Access-Control-* headers themselves).
No test cases found.
* See https://github.com/solid/specification-tests/pull/72

## Requirement: https://solidproject.org/TR/protocol#server-cors-options
Requirement subjectServer
Requirement levelMUST
StatementA server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.
No test cases found.
* See https://github.com/solid/specification-tests/pull/72

## Requirement: https://solidproject.org/TR/protocol#server-cors-enumerate
Requirement subjectServer
Requirement level
Statementserver SHOULD explicitly enumerate all used response headers under Access-Control-Expose-Headers rather than resorting to *, which does not cover all cases (such as credentials mode set to include).
No test cases found.
* See https://github.com/solid/specification-tests/pull/72
* REVIEW REQUIREMENT - this implies all used headers but spec suggests those which can be used

## Requirement: https://solidproject.org/TR/protocol#server-cors-accept-acah
Requirement subjectServer
Requirement level
StatementServers SHOULD also explicitly list Accept under Access-Control-Allow-Headers
No test cases found.
* See https://github.com/solid/specification-tests/pull/72

## Requirement: https://solidproject.org/TR/protocol#server-wac
Requirement subjectServer
Requirement levelMUST
StatementServers MUST conform to the Web Access Control specification [WAC].
No test cases found.
* Show example and ref other spec tests

# Specification: https://solid.github.io/web-access-control-spec

* For testing different operations as individual requirements, create a shared feature that runs all the tests for a single requirement, then create a scenario for each requirement that passes the correct parameters to that feature to run the tests.

Requirement: https://solid.github.io/web-access-control-spec#client-acl-uri
Requirement subjectClient
Requirement levelMUST NOT
StatementClients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-get-acl-turtle
Requirement subjectServer
Requirement levelMUST
StatementServers MUST accept an HTTP GET and HEAD request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-acl-without-representation
Requirement subjectServer
Requirement levelMUST NOT
StatementServers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT have a representation for the ACL resource that is associated with the resource.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-get-acl-without-representation
Requirement subjectServer
Requirement levelMUST
StatementWhen an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-root-container-acl
Requirement subjectServer
Requirement levelMUST
StatementWhen an authorization HTTP GET or HEAD request targets root container’s ACL resource, the server MUST respond with a representation.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-root-container-acl-authorization-control
Requirement subjectServer
Requirement levelMUST
StatementThe ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege ( access mode).
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-read-operation
Requirement subjectServer
Requirement levelMUST
StatementWhen an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-create-operation
Requirement subjectServer
Requirement levelMUST
StatementWhen 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.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-update-operation
Requirement subjectServer
Requirement levelMUST
StatementWhen 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.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-delete-operation
Requirement subjectServer
Requirement levelMUST
StatementWhen an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-control-operation
Requirement subjectServer
Requirement levelMUST
StatementWhen an operation requests to read and write an ACL resource, the server MUST match an Authorization allowing the acl:Control access privilege on the resource.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-cors-acao-acah
Requirement subjectServer
Requirement levelMUST
StatementWhen a server participates in the CORS protocol [FETCH] and authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-wac-allow
Requirement subjectServer
Requirement levelMUST
StatementServers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.
Test cases
Title Details Implemented
The WAC-Allow header shows user access modes for Bob when given direct access [manifest] [source] [requirement]
StatusApproved
✔
The WAC-Allow header shows user access modes for Bob when given indirect access via a container [manifest] [source] [requirement]
StatusApproved
✔
The WAC-Allow header is advertised [manifest] [source] [requirement]
StatusApproved
✔
The WAC-Allow header shows public access modes for a public agent when given indirect access via a container [manifest] [source] [requirement]
StatusApproved
✔
The WAC-Allow header shows public access modes for a public agent when given direct access [manifest] [source] [requirement]
StatusApproved
✔

Requirement: https://solid.github.io/web-access-control-spec#client-wac-allow
Requirement subjectClient
Requirement levelMUST
StatementClients MUST discover access privileges on a resource by making an HTTP GET or HEAD request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-cors-aceh-wac-allow
Requirement subjectServer
Requirement levelMUST
StatementWhen a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.
No test cases found.

Requirement: https://solid.github.io/web-access-control-spec#client-wac-allow-parsing
Requirement subjectClient
Requirement levelMUST
StatementClient parsing algorithms for WAC-Allow header field-values MUST incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (such as permission groups or access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-link-acl
Requirement subjectServer
Requirement levelMUST
StatementWhen a server wants to enable applications to discover Authorizations associated with a given resource, the server MUST advertise the ACL resource that is associated with a resource by responding to an HTTP request including a Link header with the rel value of acl (acl Link Relation) and the ACL resource as link target [RFC8288].
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#server-resource-acl-max
Requirement subjectServer
Requirement levelMUST NOT
StatementServers MUST NOT directly associate more than one ACL resource to a resource.
No test cases found.

Requirement: https://solid.github.io/web-access-control-spec#client-link-acl
Requirement subjectClient
Requirement levelMUST
StatementClients MUST discover the ACL resource associated with a resource by making an HTTP request on the target URL, and checking the HTTP Link header with the rel parameter.
No test cases found.

## Requirement: https://solid.github.io/web-access-control-spec#access-modes
Requirement subjectServer
Requirement levelMUST
Test cases
Title Details Implemented
Bob cannot read an RDF resource to which he is not granted read access [manifest] [source] [requirement]
StatusApproved
✔
Bob can only read an RDF resource to which he is only granted read access [manifest] [source] [requirement]
StatusApproved
✔
Bob can only read an RDF resource to which he is only granted default read access via the parent [manifest] [source] [requirement]
StatusApproved
✔
Bob cannot read an RDF resource to which he is not granted default read access via the parent [manifest] [source] [requirement]
StatusUnreviewed
✔
## Requirement: https://solid.github.io/web-access-control-spec#access-objects
Requirement subjectServer
Requirement levelMUST
Test cases
Title Details Implemented
Bob can read a container and its children if he is granted both direct and inheritable read access [manifest] [source] [requirement]
StatusApproved
✔
Bob cannot read a container or children if he is not given any access [manifest] [source] [requirement]
StatusApproved
✔
Bob can only read child containers/resources of a container to which he is granted inheritable read access [manifest] [source] [requirement]
StatusUnreviewed
✔
Bob cannot read a container or children if he is not given any access [manifest] [source] [requirement]
StatusApproved
✔
## Requirement: https://solid.github.io/web-access-control-spec#authorization-evaluation-context
Requirement subjectServer
Requirement levelMUST
Test cases
Title Details Implemented
Inheritable ACL controls child resources [manifest] [source] [requirement]
StatusApproved
✔