Solid Specification - Conformance Test Suite Coverage Report

Identifier
ea87fd81-4617-4c67-bcee-1aacffbb52ba

Specifications under test

Test suite

Name
Specification Tests
Description
Solid Specification Conformance Tests
Created
Developer
https://solidproject.org
Homepage
https://github.com/solid-contrib/specification-tests/
Programming Language
KarateDSL
Version
0.0.19

Test coverage by specification requirement

  • Specification: https://solidproject.org/TR/protocol 87
    • Requirement: https://solidproject.org/TR/protocol#server-http-11 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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#server-http-2 0
      Requirement subject
      Server
      Requirement level
      SHOULD
      Statement
      Servers SHOULD conform to HTTP/2 [RFC7540].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-tls-https 0
      Requirement subject
      Server
      Requirement level
      SHOULD
      Statement
      Servers SHOULD use TLS connections through the https URI scheme in order to secure the communication with clients.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-tls-https-redirect 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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.

    • Requirement: https://solidproject.org/TR/protocol#server-conditional-requests 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-caching 0
      Requirement subject
      Server
      Requirement level
      SHOULD
      Statement
      Servers SHOULD conform to HTTP/1.1 Caching [RFC7234].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-range-requests 0
      Requirement subject
      Server
      Requirement level
      MAY
      Statement
      Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-authentication 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST conform to HTTP/1.1 Authentication [RFC7235].
      Test cases
      Title Details Implemented
      Test that unauthenticated users get the correct response [manifest] [source] [requirement]
      Status
      Approved
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-unauthenticated 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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]
      Status
      Approved
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-content-type 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Server 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#client-http-11 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Clients 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 0
      Requirement subject
      Client
      Requirement level
      MAY
      Statement
      Clients MAY conform to HTTP/2 [RFC7540].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-conditional-requests 0
      Requirement subject
      Client
      Requirement level
      MAY
      Statement
      Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-caching 0
      Requirement subject
      Client
      Requirement level
      MAY
      Statement
      Clients MAY conform to HTTP/1.1 Caching [RFC7234].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-range-requests 0
      Requirement subject
      Client
      Requirement level
      MAY
      Statement
      Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-authentication 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Clients 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 0
      Requirement subject
      Client
      Requirement level
      MAY
      Statement
      When 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 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Clients 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 1
      Requirement subject
      Server
      Requirement level
      MUST NOT
      Statement
      If 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-uri-redirect-differing 1
      Requirement subject
      Server
      Requirement level
      MAY
      Statement
      Instead, 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-authorization-redirect 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST authorize prior to this optional redirect.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-storage 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST provide one or more storages. The storage resource (pim:Storage) is the root container for all of its contained resources (see Resource Containment).

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-storage-nonoverlapping 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-storage-discovery 0
      Requirement subject
      Requirement level

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-rdf-storage 0
      Requirement subject
      Requirement level

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-storage-description 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST include the Link header with rel="http://www.w3.org/ns/solid/terms#storageDescription" targeting the URI of the storage description resource in the response of HTTP GET, HEAD and OPTIONS requests targeting a resource in a storage.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-storage-description-resource 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST include statements about the storage as part of the storage description resource.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-storage-track-owner 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST keep track of at least one owner of a storage in an implementation defined way.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-basic-container 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-contained-resource-metadata 0
      Requirement subject
      Server
      Requirement level
      SHOULD
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-auxiliary-resources-management 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST support auxiliary resources defined by this specification and manage the association between a subject resource and auxiliary resources.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-description-resource-max 1
      Requirement subject
      Server
      Requirement level
      MUST NOT
      Statement
      Servers 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-description-resource-authorization 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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.

    • Requirement: https://solidproject.org/TR/protocol#server-method-not-allowed 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-put-patch-uri-assignment 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-post-uri-assignment 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-slug-uri-assignment 1
      Requirement subject
      Server
      Requirement level
      MAY
      Statement
      Servers 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-safe-methods 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options.
      Test cases
      Title Details Implemented
      Servers MUST support GET, HEAD and OPTIONS [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-allow-methods 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST indicate the HTTP methods supported by the target resource by generating an Allow header field in successful responses.
      Test cases
      Title Details Implemented
      Servers MUST return Allow for GET and HEAD [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-accept-headers 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When responding to authorized requests, servers 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, HEAD and OPTIONS requests.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-put-patch-intermediate-containers 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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]
      Status
      Approved
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-post-container 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST allow creating new resources with a POST request to URI path ending /.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-post-container-create-resource 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST create a resource with URI path ending /{id} in container /.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-post-container-create-container 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-post-target-not-found 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-put-patch-auxiliary-resource 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-post-slug-auxiliary-resource 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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.

    • Requirement: https://solidproject.org/TR/protocol#server-protect-containment 0
      Requirement subject
      Server
      Requirement level
      MUST NOT
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-protect-contained-resource-metadata 0
      Requirement subject
      Server
      Requirement level
      MUST NOT
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-etag 0
      Requirement subject
      Server
      Requirement level
      MAY
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-patch-n3-accept 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-patch-n3-advertise 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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.

    • Requirement: https://solidproject.org/TR/protocol#server-patch-n3-invalid 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-n3-patch-where 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When ?conditions is non-empty, servers MUST treat the request as a Read operation.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-n3-patch-insert 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When ?insertions is non-empty, servers MUST (also) treat the request as an Append operation.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-n3-patch-delete 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When ?deletions is non-empty, servers MUST treat the request as a Read and Write operation.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-patch-n3-semantics 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST process a patch resource against the target document as follows:

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-delete-protect-root-container 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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.

    • Requirement: https://solidproject.org/TR/protocol#server-disallow-delete 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-delete-remove-containment 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-delete-remove-auxiliary-resource 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-delete-remove-empty-container 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When a DELETE request targets a container, the server MUST delete the container if it contains no resources.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-delete-protect-nonempty-container 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      If 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]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-representation-turtle-jsonld 3
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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].
      Additional comments
      • Note that there is no requirement to support RDFa in a similar way, though some implementations may choose to.
      Test cases
      Title Details Implemented
      RDF documents containing named graphs can be stored and retrieved [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Requests support content negotiation for JSON-LD resource [manifest] [source] [requirement]
      Status
      Approved
      		✔
      Requests support content negotiation for Turtle resource [manifest] [source] [requirement]
      Status
      Approved
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-representation-write-redirect 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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.

    • Requirement: https://solidproject.org/TR/protocol#server-ldn 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      A 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.

    • Requirement: https://solidproject.org/TR/protocol#client-ldn 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      A 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-notifications-protocol-resource-server 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Resource Server to enable clients to discover subscription resources and notification channels available to a given resource or storage.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-subscription-server 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Subscription Server to process and produce instructions for subscription requests.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-notification-sender 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Notification Sender to produce and send messages to a Notification Receiver.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-notification-receiver 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Notification Receiver to receive and process messages that conform to a notification channel type.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#server-cors 2
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      A 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].
      Test cases
      Title Details Implemented
      Server must implement the CORS protocol for simple requests [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Server must implement the CORS protocol for preflight requests [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-cors-access-control-headers 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      whenever 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].
      Test cases
      Title Details Implemented
      Server must respond to requests sending Origin with the appropriate Access-Control-* headers [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-cors-acao-vary 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      the 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.
      Test cases
      Title Details Implemented
      Server returns correct Access-Control-Allow-Origin and Vary headers [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-cors-aceh 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      The 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.

    • Requirement: https://solidproject.org/TR/protocol#server-cors-options 1
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.
      Test cases
      Title Details Implemented
      Server must support HTTP OPTIONS for CORS preflight requests [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-cors-enumerate 1
      Requirement subject
      Server
      Requirement level
      SHOULD
      Statement
      servers 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).
      Test cases
      Title Details Implemented
      Server should enumerate headers in Access-Control-Expose-Headers [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-cors-accept-acah 1
      Requirement subject
      Server
      Requirement level
      SHOULD
      Statement
      Servers SHOULD also explicitly list Accept under Access-Control-Allow-Headers
      Test cases
      Title Details Implemented
      Server should explicitly list Accept under Access-Control-Allow-Headers [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/protocol#server-wac-acp 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers MUST conform to either or both Web Access Control [WAC] and Access Control Policy [ACP] specifications.

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-wac 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Clients MUST conform to the Web Access Control specification [WAC].

      No test cases found.

    • Requirement: https://solidproject.org/TR/protocol#client-acp 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Clients MUST conform to the Access Control Policy specification [ACP].

      No test cases found.

  • Specification: https://solidproject.org/TR/wac 22
    • Requirement: https://solidproject.org/TR/wac#server-resource-acl-max 0
      Requirement subject
      Server
      Requirement level
      MUST NOT
      Statement
      Servers MUST NOT directly associate more than one ACL resource to a resource.

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#client-acl-uri 0
      Requirement subject
      Client
      Requirement level
      MUST NOT
      Statement
      Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#server-get-acl-turtle 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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://solidproject.org/TR/wac#server-acl-without-representation 0
      Requirement subject
      Server
      Requirement level
      MUST NOT
      Statement
      Servers 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://solidproject.org/TR/wac#server-get-acl-without-representation 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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://solidproject.org/TR/wac#server-root-container-acl 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When an authorized HTTP GET or HEAD request targets root container’s ACL resource, the server MUST respond with a representation.

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#server-root-container-acl-authorization-control 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege ( access mode).

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#server-read-operation 6
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.
      Test cases
      Title Details Implemented
      Public agents can read (and only that) a resource when granted read access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Only authenticated agents can read (and only that) a resource when granted read access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Only Bob can read (and only that) a resource when granted read access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Only Bob can write (and only that) a resource when granted write access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Only authenticated agents can write (and only that) a resource when granted write access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
      Only authenticated agents can write (and only that) a resource when granted write access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/wac#server-create-operation 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      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.

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#server-update-operation 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      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.

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#server-delete-operation 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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://solidproject.org/TR/wac#server-control-operation 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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://solidproject.org/TR/wac#server-cors-acao-acah 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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://solidproject.org/TR/wac#server-wac-allow 5
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      Servers 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 indirect access via a container [manifest] [source] [requirement]
      Status
      Approved
      		✔
      The WAC-Allow header shows public access modes for a public agent when given direct access [manifest] [source] [requirement]
      Status
      Approved
      		✔
      The WAC-Allow header shows public access modes for a public agent when given indirect access via a container [manifest] [source] [requirement]
      Status
      Approved
      		✔
      The WAC-Allow header shows user access modes for Bob when given direct access [manifest] [source] [requirement]
      Status
      Approved
      		✔
      The WAC-Allow header is advertised [manifest] [source] [requirement]
      Status
      Approved
      		✔
    • Requirement: https://solidproject.org/TR/wac#client-wac-allow 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Clients 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://solidproject.org/TR/wac#server-cors-aceh-wac-allow 0
      Requirement subject
      Server
      Requirement level
      MUST
      Statement
      When 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://solidproject.org/TR/wac#client-wac-allow-parsing 0
      Requirement subject
      Client
      Requirement level
      MUST
      Statement
      Client 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://solidproject.org/TR/wac#access-modes 0
      Requirement subject
      Server
      Requirement level
      MUST

      No test cases found.

    • Requirement: https://solidproject.org/TR/wac#access-objects 4
      Requirement subject
      Server
      Requirement level
      MUST
      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]
      Status
      Approved
      		✔
      Bob cannot read a container or children if he is not given any access [manifest] [source] [requirement]
      Status
      Approved
      		✔
      Bob cannot read a container or children if he is not given any access [manifest] [source] [requirement]
      Status
      Approved
      		✔
      Bob can only read child containers/resources of a container to which he is granted inheritable read access [manifest] [source] [requirement]
      Status
      Unreviewed
      		✔
    • Requirement: https://solidproject.org/TR/wac#authorization-evaluation-context 1
      Requirement subject
      Server
      Requirement level
      MUST
      Test cases
      Title Details Implemented
      Inheritable ACL controls child resources [manifest] [source] [requirement]
      Status
      Approved
      		✔