[@@ from charter]

The Linked Web Storage Protocol specification aims to provide applications with secure and permissioned access to externally stored data in an interoperable way.

The Linked Web Storage Protocol does/does not include protocol details for integration with identity layers and mechanisms; access management and data integrity; notifications about resource changes; and authorization mechanisms.

This is an unofficial proposal.

For Editors

List of TODOs and ideas in flux to enable editors to communicate asynchronously.

Resources

Tactics

Document Conventions

Introduction

Resource Access

The LWS Protocol defines standard interactions by which a some party can make some resources available to some agents.

Security and Privacy

A resource manager may keep a served resource private, may make it publicly available to anyone, or may limited its visibility to a constrained set of requesting agents.

A LWS REST Server is an HTTP server [[!rfc9112]] that complies with all of the relevant "MUST" statements in this specification. Specifically, the relevant normative "MUST" statements in Sections 999 REST Binding of this document MUST be respected.

A LWS REST Client is an HTTP client [[!rfc9112]] that complies with all of the relevant "MUST" statements in this specification. Specifically, the relevant normative "MUST" statements in Sections 999 REST Binding of this document MUST be respected.

Terminology

This specification defines operations on served resources, the resulting change of state, and a response indended to give the requesting agent requested infomation or inform them of the outcome of the operation. An operation is any of the following actions that can be performed on a served resource:

The folowing section will describe the semantics and responses of these operations but the following core responses apply to any operation:

Authentication

For any access control that requires establishing the identity of a requesting agent, that identiy is established using strawman-authn:

        {
          "@context": ["https://strawman-authn"],
          "client_id": "https://app.example/id",
          "client_name": "Solid Application Name",
          "redirect_uris": ["https://app.example/callback"],
          "post_logout_redirect_uris": ["https://app.example/logout"],
          "client_uri": "https://app.example/",
          "logo_uri" : "https://app.example/logo.png",
          "tos_uri" : "https://app.example/tos.html",
          "scope" : "openid profile offline_access webid",
          "grant_types" : ["refresh_token","authorization_code"],
          "response_types" : ["code"],
          "default_max_age" : 3600,
          "require_auth_time" : true
        }
    

Authorization

A resource manager dicates the requesting agents, eiher directly, by listing them in a strawman-ACLs document:

[]
  a straw:AccessControlResource ;
  straw:resource ex:myServedResource ;
  straw:accessControl [
    a straw:AccessControl ;
    straw:apply [
      a straw:Policy ;
      straw:allow acl:Read ;
      straw:anyOf [
        a straw:Matcher ;
        straw:agent ex:RequestingAgent1, ex:RequestingAgent2 ;
      ]
    ]
  ] .

Or by deferring to a trusted authorization server as in this strawman-ACLs document:

[]
  a straw:AccessControlResource ;
  straw:resource ex:myServedResource ;
  straw:accessControl [
    a straw:AccessControl ;
    straw:apply [
      a straw:Policy ;
      straw:allow acl:Read ;
      straw:anyOf [
        a straw:Matcher ;
        straw:authorizer ex:AutorServer3 ;
      ]
    ]
  ] .

Discovery

Define how requesting agents discover served resources and their capabilities.

Operations

create resource

Create resource

In addition to the core responses, a create operation may produce any of:

read resource

The read resource operation requests a resource representation. Draw from Solid Protocol - Reading Resources.

update resource

The update resource modifies the contents of a served resource. Draw from Solid Protocol - Reading Resources.

delete resource

Delete resource

Logical Resource Organization

Define the data model for logical resource organization within LWS, including how containers are structured, hierarchical relationships between resources, container semantics, containment rules, and the mechanisms for organizing and navigating collections of related resources. This should cover container creation, membership management, and the relationship between containers and the resources they contain.

REST Binding

This strawman mapping of the operations and responses defined above allows LWS REST Servers and LWS REST Clients to communicate over HTTP using REST conventions.

The following table maps LWS response to an HTTP status code and payload:

LWS responseHTTP status codeHTTP payload
success200resource representation
not permitted...
unknown requester...
unknown error...
created201

Resource Identification

Define how resources are identified and addressed within the LWS Protocol, including URI schemes, resource naming conventions, and resolution mechanisms. This section may be moved within another section; e.g. Resource Access

Unstable Features

The features described in this section are being drafted to ground discussions and may be removed if there is:

Profile Negotiation on Resources

Define mechanisms for content negotiation based on profiles, allowing clients to request specific representations or views of resources (e.g., JSON-LD contexts, different RDF serializations, or application-specific profiles).

Notifications

Define notification mechanisms that allow clients to be informed of changes to resources, including subscription models, event formats, and delivery mechanisms.

Inbox

Define inbox resources with specific semantics within LWS, including message posting, retrieval, and management capabilities for asynchronous communication patterns.

Portability Considerations

Describe considerations for ensuring LWS implementations can work across different platforms, environments, and storage backends while maintaining interoperability - and provide affordances to enable change in storage providers

Security Considerations

Formal security considerations section covering threat models, security requirements, and implementation guidance for secure LWS deployments.

Privacy Considerations

Privacy implications of the LWS Protocol, including data minimization, user consent, and privacy-preserving implementation patterns.