From 954085cbfbcfc640e02d6b9f8ff8183a5bcce3e9 Mon Sep 17 00:00:00 2001 From: Jeremy Caine Date: Fri, 15 May 2026 17:51:03 +0100 Subject: [PATCH 1/6] Add introduction section --- lws10-core/index.html | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/lws10-core/index.html b/lws10-core/index.html index d3a6fde..b32d64d 100644 --- a/lws10-core/index.html +++ b/lws10-core/index.html @@ -121,14 +121,36 @@

Tactics

Document Conventions

-
+

Introduction

+ This specification defines the Linked Web Storage (LWS) Protocol, which enables client applications to access and manage web resources stored externally, based on the identity and permissions of the user.

+

+ By standardising how a LWS server manages and provides access to a hierarchy of linked resources, the protocol enables users to use different LWS client applications to interact with the same stored data. These linked resources are defined through containers and containment relationships that describe where things are located, and metadata that describes how the resources relate to each other. +

+

+ The protocol defines standard operations on these resources to create, read, update, and delete. Resources, their containment and metadata are managed by the server as a set of JSON-LD documents. Each resource is identified by a URI. A client navigates the resource hierarchy from a root container, discovering contained resources and their relations through links provided in server responses. +

+

+ A user’s identity is confirmed through an identity provider external to the Linked Web Storage server. This separation means the server does not manage credentials directly, it receives and validates a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present their existing identity to any compliant server, without needing a separate account on that server. User authentication is defined in companion specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers. +

+

+ Authorization determines whether a requesting user has permission to access a resource or perform an operation on it. A compliant LWS server designates a resource manager for each resource that determines whether a resource is publicly available, private, or restricted to a defined set of users. The server enforces the access decisions of the resource manager when handling each client request. +

+

This specification is intended to be used by:

+ +

+ Different compliant servers each maintain their own hierarchy of linked resources. A user can navigate across servers using the same identity, with access to each server’s resources determined by the permissions that server’s resource managers have granted them. +

+

Resource Access

@@ -177,7 +199,7 @@

Security and Privacy

Terminology

The terms "authorization server" and "client" are defined by the OAuth 2.0 Authorization Framework [[!RFC6749]]. -

+

The terms "end-user" and "issuer" are defined by OpenID Connect Core 1.0 [[!OPENID-CONNECT-CORE]].

@@ -201,7 +223,7 @@

Terminology

- This specification defines operations on served resources, the resulting change of state, and a response intended to give the requesting agent requested infomation or inform them of the outcome of the operation. + This specification defines operations on served resources, the resulting change of state, and a response intended to give the requesting agent requested information 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:

    @@ -212,7 +234,7 @@

    Terminology

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

  • success - the operation is believed to have completed. This may be accompanied by a resource representation conveying the contents of a served resource. A success response is not defined for the create resource operation. See instead created.
    • From 0a39c3862af87b1b6b54bc553fd660be1488e9a8 Mon Sep 17 00:00:00 2001 From: Jeremy Caine <78078008+jeremycaine@users.noreply.github.com> Date: Thu, 11 Jun 2026 17:10:58 +0100 Subject: [PATCH 2/6] Update lws10-core/index.html relaxing as JSON-LD is not only media type Co-authored-by: Ted Thibodeau Jr --- lws10-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lws10-core/index.html b/lws10-core/index.html index b32d64d..9a527e0 100644 --- a/lws10-core/index.html +++ b/lws10-core/index.html @@ -134,7 +134,7 @@

    Introduction

    By standardising how a LWS server manages and provides access to a hierarchy of linked resources, the protocol enables users to use different LWS client applications to interact with the same stored data. These linked resources are defined through containers and containment relationships that describe where things are located, and metadata that describes how the resources relate to each other.

    - The protocol defines standard operations on these resources to create, read, update, and delete. Resources, their containment and metadata are managed by the server as a set of JSON-LD documents. Each resource is identified by a URI. A client navigates the resource hierarchy from a root container, discovering contained resources and their relations through links provided in server responses. + The protocol defines standard operations on these resources to create, read, update, and delete. Resources, their containment, and their metadata are managed by the server, commonly as a set of JSON-LD documents. Each resource is identified by a URI. A client navigates the resource hierarchy from a root container, discovering contained resources and their relations through links provided in server responses.

    A user’s identity is confirmed through an identity provider external to the Linked Web Storage server. This separation means the server does not manage credentials directly, it receives and validates a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present their existing identity to any compliant server, without needing a separate account on that server. User authentication is defined in companion specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers. From cf9be25aaf4c2e2326071d5ef4ab2578e194e397 Mon Sep 17 00:00:00 2001 From: Jeremy Caine <78078008+jeremycaine@users.noreply.github.com> Date: Thu, 11 Jun 2026 17:16:55 +0100 Subject: [PATCH 3/6] Update lws10-core/index.html elaborate on private, public and restricted Co-authored-by: Ted Thibodeau Jr --- lws10-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lws10-core/index.html b/lws10-core/index.html index 9a527e0..6ae1aba 100644 --- a/lws10-core/index.html +++ b/lws10-core/index.html @@ -140,7 +140,7 @@

    Introduction

    A user’s identity is confirmed through an identity provider external to the Linked Web Storage server. This separation means the server does not manage credentials directly, it receives and validates a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present their existing identity to any compliant server, without needing a separate account on that server. User authentication is defined in companion specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers.

    - Authorization determines whether a requesting user has permission to access a resource or perform an operation on it. A compliant LWS server designates a resource manager for each resource that determines whether a resource is publicly available, private, or restricted to a defined set of users. The server enforces the access decisions of the resource manager when handling each client request. + Authorization determines whether a requesting user has permission to access a resource or perform an operation on it. A compliant LWS server designates a resource manager for each resource that determines whether a resource is private (i.e., available only to its owner), restricted (i.e., available to a defined set of users), or public (i.e., available to any user). The server enforces the access decisions of the resource manager when handling each client request.

    This specification is intended to be used by:

      From 4ada3f216b970f4d334ea79ead3568254a4927ad Mon Sep 17 00:00:00 2001 From: Jeremy Caine <78078008+jeremycaine@users.noreply.github.com> Date: Thu, 11 Jun 2026 17:17:23 +0100 Subject: [PATCH 4/6] Update lws10-core/index.html Co-authored-by: Ted Thibodeau Jr --- lws10-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lws10-core/index.html b/lws10-core/index.html index 6ae1aba..e266708 100644 --- a/lws10-core/index.html +++ b/lws10-core/index.html @@ -144,7 +144,7 @@

      Introduction

      This specification is intended to be used by:

        -
      • Developers building client applications that access a user’s linked web storage resources
        • +
      • Developers building client applications that access a user’s LWS resources
      • Server implementors building compliant LWS servers that mediate access to a user’s external web resources

      From 8f7c76873d21b011ef034403fc7eb8f881f9ead7 Mon Sep 17 00:00:00 2001 From: Jeremy Caine <78078008+jeremycaine@users.noreply.github.com> Date: Thu, 11 Jun 2026 17:18:55 +0100 Subject: [PATCH 5/6] Update lws10-core/index.html point that an LWS account not required; plus CIDs Co-authored-by: Ted Thibodeau Jr --- lws10-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lws10-core/index.html b/lws10-core/index.html index e266708..11bf714 100644 --- a/lws10-core/index.html +++ b/lws10-core/index.html @@ -137,7 +137,7 @@

      Introduction

      The protocol defines standard operations on these resources to create, read, update, and delete. Resources, their containment, and their metadata are managed by the server, commonly as a set of JSON-LD documents. Each resource is identified by a URI. A client navigates the resource hierarchy from a root container, discovering contained resources and their relations through links provided in server responses.

      - A user’s identity is confirmed through an identity provider external to the Linked Web Storage server. This separation means the server does not manage credentials directly, it receives and validates a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present their existing identity to any compliant server, without needing a separate account on that server. User authentication is defined in companion specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers. + A user’s identity is confirmed through an identity provider external to the Linked Web Storage server. This separation means the server does not manage credentials directly; rather, it receives and validates a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present their existing identity to any compliant server, without needing a new or existing separate account on that server. User authentication is defined in companion specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers (CIDs).

      Authorization determines whether a requesting user has permission to access a resource or perform an operation on it. A compliant LWS server designates a resource manager for each resource that determines whether a resource is private (i.e., available only to its owner), restricted (i.e., available to a defined set of users), or public (i.e., available to any user). The server enforces the access decisions of the resource manager when handling each client request. From 25cdda75a035223eba9f362100a84a9ecd5d36e0 Mon Sep 17 00:00:00 2001 From: Jeremy Caine <78078008+jeremycaine@users.noreply.github.com> Date: Thu, 11 Jun 2026 17:19:04 +0100 Subject: [PATCH 6/6] Update lws10-core/index.html Co-authored-by: Ted Thibodeau Jr --- lws10-core/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lws10-core/index.html b/lws10-core/index.html index 11bf714..4e89b1d 100644 --- a/lws10-core/index.html +++ b/lws10-core/index.html @@ -148,7 +148,7 @@

      Introduction

    • Server implementors building compliant LWS servers that mediate access to a user’s external web resources

    - Different compliant servers each maintain their own hierarchy of linked resources. A user can navigate across servers using the same identity, with access to each server’s resources determined by the permissions that server’s resource managers have granted them. + Different compliant servers each maintain their own hierarchy of linked resources. A user can navigate across servers using the same identity, with access to each server’s resources determined by the permissions granted by that server’s resource managers.