LWS Protocol

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

• served resource - ( available resource? published resource? ) ( not defined in UCS ) A network-accessible entity exposed by a service for interaction, retrieval, or manipulation using the protocol defined in this document.
• requesting agent - ( entity in UCS ) An entity (e.g., client, user, or process) that initiates a request to interact with a servable resource.

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 .

• authentication - the process of verifying the identity of an agent executing a request.
• authorization - the process of determining whether an agent has permission to access a specific resource or perform one of a set of operations .
• resource manager - ( controller in UCS) An agent that has permission to control access to a served resource .

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY , MUST , MUST NOT , OPTIONAL , RECOMMENDED , REQUIRED , SHOULD , and SHOULD NOT in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.

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.

The data model described in this section outlines the requirements for any concrete serialization of an end-user credential.

An end-user credential MUST include tamper evident claims about a subject, including:

• subject REQUIRED — an identifier for an end user. This MUST be an absolute URI.
• issuer REQUIRED — an identifier for the entity that issued the end-user credential. This MUST be an absolute URI.
• client REQUIRED — an identifier for a client application. This SHOULD be an absolute URI.
• audience restriction RECOMMENDED — a list of values that SHOULD include an authorization server identifier.

Validation of an end-user credential requires a trust relationship between the verifier and issuer of the credential. This trust relationship MAY be established through an out-of-band mechanism. Any additional mechanisms for establishing trust between a verifier and an issuer are outlined in specific authentication suites.

An end-user credential MUST be signed. It is RECOMMENDED that the signature uses asymmetric cryptography.

Each authentication suite MUST be associated with a token type URI. An authentication suite SHOULD use a URI defined in the IANA "OAuth URI" registry.

The roles in LWS authorization are the same as those defined by OAuth 2.0 Section 1.1 [ RFC6749 ]: resource owner , resource server , client (called in this specification authorization client to avoid ambiguity), and authorization server . A storage server is a type of resource server that also conforms to the LWS storage specification.

This specification describes the interaction between a client and an authorization server as well as the interaction between a client and a conforming storage server.

The interaction between the authorization server and the storage server is out of scope of this specification. The authorization server may be the same server as the storage server or it may be a separate entity.

HTTP/2 401 Unauthorized
Link: ; rel="storageDescription"
WWW-Authenticate: Bearer as_uri="https://authorization.example",
                realm="https://storage.example/storage_1",
                error="invalid_token"

{
    "issuer": "https://authorization.example",
    "grant_types_supported": [
        "urn:ietf:params:oauth:grant-type:token-exchange"],
    "token_endpoint": "https://authorization.example/token",
    "jwks_uri": "https://authorization.example/jwks",
    "claims_supported": [
        "sub",
        "iss",
        "client_id",
        "aud"],
    "response_types_supported": [
        "token"],
    "subject_token_types_supported": [
        "urn:ietf:params:oauth:token-type:jwt",
        "urn:ietf:params:oauth:token-type:id-token"]

}

POST /token HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fstorage.example%2Fstorage_1
&subject_token=eyJ0eXAiOiJhcytqd3QiLCJhbGciO...fiK51VwhsxJ-siBMR-YFiA
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token

HTTP/1.1 200 OK
Content-Type: application/json
{
    "access_token":"eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso",
    "token_type":"Bearer",
    "expires_in":3600

}

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "error":"invalid_request"

}

{
  "kid": "ec51c6b2",
  "kty": "EC",
  "alg": "ES256",
  "crv": "P-256",
  "typ": "at+jwt"
}
.
{
  "sub": "https://id.example/agent",
  "iss": "https://authorization.example",
  "client_id": "https://app.example/id",
  "aud": "https://storage.example",
  "exp": 1735686300,
  "iat": 1735686000,
  "jti": "550e8400-e29b-41d4-a716-446655440000"
}
.
signature

Authorization

:

Bearer
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...

This section delineates the abstract data model governing the organization of resources within the Linked Web Storage (LWS) system. It encompasses the structuring of containers and resources, their hierarchical interrelations, the functional semantics of containers as organizational units, rules pertaining to containment, and mechanisms for clients to organize and navigate resource collections. This model establishes the logical namespace of the storage, delineating inter-resource relationships therein, without presupposing any specific identifier structure or semantic implications derived from identifier composition. Logical organization MUST prioritize discoverability and self-descriptive APIs, avoiding hardcoded locations. Containment is represented as metadata to enable multiple containers per resource without URL changes, supporting sharing use cases. All entities MUST have associated metadata resources using Link Sets (RFC 9264), distinguishing server-managed and user-managed data.

Create In LWS, a resource constitutes the fundamental unit of storage and access. Each resource possesses a unique identifier within the system. A resource may encompass data, such as content or structured information, alongside associated metadata, including attributes like type or modification timestamps. Resources MUST be classified as 'DataResource', 'Container', or 'MetadataResource' via metadata types. DataResources MAY have multiple representations; servers MUST track original media types and support reification in metadata using the 'representation' property, which includes 'mediaType' and optional 'sizeInBytes'.

A container represents a specialized resource type capable of encompassing other resources as members. Containers function as organizational constructs, facilitating the grouping of resources in a manner akin to collections or directories. A container maintains references to its member resources, which may comprise both non-container resources and additional container resources, thereby enabling hierarchical formations. Typically, a container holds minimal intrinsic content beyond metadata or enumerations of its members; its principal role is to aggregate and structure subordinate resources. The storage system's root is designated as a container, serving as the apex organizational unit devoid of a superior parent. Containers MUST support pagination for membership listings using 'ContainerPage' types, with properties such as 'first', 'next', 'prev', and 'last'. Representations MUST use JSON-LD with a specific frame and normative context, optionally advertising content negotiation via 'Vary: Accept' headers. Storage MAY function as a root container, enabling direct writes.

In addition With the exception of the root container, every resource is affiliated with precisely one parent container. This affiliation engenders a strict hierarchical structure, manifesting as a tree with a singular root container at its pinnacle. Upon creation within a designated container, a new resource becomes a member of that container, appearing within its membership enumeration. Cycles or multiple parent affiliations are prohibited within this model; a resource cannot concurrently belong to multiple containers without duplication or alternative referencing mechanisms external to the core responses , a create operation may produce any of: containment framework. This constraint enhances model simplicity and aligns with conventional organizational paradigms. Containment MUST be modeled as metadata links using 'contains' (from container to member) and 'partOf' (from member to container), allowing transitive queries and multiple hierarchies without slash semantics. Servers MAY support hierarchy arrays for ancestors.

Operations involving the creation, deletion, or relocation of resources influence container memberships as follows:

• created - . Upon creation, a new resource is associated with a specified parent container. This association integrates the resource into the parent's membership.
more? worthy
• Deletion of a list? resource entails its removal from the parent container's membership. Should this render the container devoid of members, it assumes an empty state, potentially permitting its subsequent deletion if warranted. Container deletion typically necessitates an empty state or invokes recursive removal of members.
• The core operations (create, read, update, delete) do not incorporate an explicit relocation or renaming function. To reassign a resource to an alternative container, a client may replicate or recreate the resource in the target location followed by deletion of the original. Implementations may optionally extend non-core operations for relocation or renaming, achievable logically through combined creation and deletion. Membership is managed via create/delete operations; direct updates to membership listings are server-managed and not client-writable to avoid concurrency issues.

Container instantiation occurs via the standard resource creation operation (Section 7.1), differentiated by an indicator specifying the intent to establish a container rather than a non-container resource. This process yields an empty container amenable to subsequent population with members, including sub-containers to extend the hierarchy. Servers MUST assign identifiers, and empty containers MUST be supported.

The Clients navigate the hierarchy through read operations on containers, which yield enumerations of member identifiers. A container's representation furnishes a listing of its members, enabling traversal and discovery of subordinate resources. Listings MUST include metadata for each member, such as resource IDs ( MUST ), types (array of system and user-defined), representations ( MUST for DataResources, including mediaType and optional sizeInBytes), and modified timestamps ( SHOULD ).

The create resource operation adds a new served resource representation . Draw from Solid Protocol - Reading Resources to an existing container . This operation handles both the creation of data resources (files) and sub-containers.

Inputs:

• Target container: The identifier of the container where the new resource will be created.
• Identity hint: An optional suggestion for the new resource's identifier. The server may use this hint but is not required to.
• Content: The initial content and type for the new resource.

Behavior:

• Identity generation: The server determines the final identifier (URI) for the new resource. If an identity hint was provided, the server attempts to incorporate it while ensuring uniqueness and validity within the container. If no hint is provided, the server generates a unique identifier.
• Container membership update: The server atomically adds the new resource to the membership listing of the target container.
• Metadata initialization: The server initializes system metadata for the new resource. If the resource has an associated metadata resource it is also initialized.

Possible Responses:

• Created: The operation succeeded. The server returns the final identifier of the newly created resource.
• Target Not Found: The specified target container does not exist.
• Not Permitted: The client's identity is known, but they do not have permission to create resources in this container.
• Unknown Requester: The server does not recognize the client's identity and requires authentication.
• Conflict: A resource with the generated identifier already exists, or there is another state conflict.
• Unknown Error: An unexpected internal error occurred.

Retrieves the representation of an existing resource or the listing of a container.

• Inputs : Target identifier and optional parameters.
• Behavior :
  • For non-container resources, the server returns the resource content.
  • For containers, the server returns a listing of member resources. Listings must include core metadata for each member and must be filtered based on the requester's permissions.
• Outcome : The requested representation or a notification of failure.

Modifies the contents state of an existing [served resource] via full replacement or a served partial patch.

• Inputs : Target identifier, new content, and optional concurrency constraints.
• Behavior : The server applies the changes atomically. If concurrency constraints are provided, the update is rejected if the resource . Draw from Solid Protocol - Reading Resources . has been modified since it was last read by the requester.
• Outcome : Confirmation of the update or a notification of conflict.

Delete Permanently removes a resource and its associated metadata.

• Inputs : Target identifier, an optional recursive flag (for containers), and optional concurrency constraints.
• Behavior :
  • For non-container resources, the server removes the content, metadata, and updates the parent container's membership.
  • For containers, the server typically requires the container to be empty unless a recursive delete is explicitly requested and supported.
• Outcome : Confirmation of removal or a notification of failure.

This section defines the model for associating metadata with LWS resources. The LWS metadata system is based on the principles of Web Linking [ RFC8288 ], which allows servers to describe the relationships between resources using typed links. Metadata enhances discoverability, supports self-descriptive APIs, and aligns with resource operations, container hierarchies, and REST bindings as outlined in sections 7 and 8.

Metadata Model All metadata in LWS is expressed as a set of typed links originating from a resource (the link context). Each link consists of:

• A link target: A URI identifying the related resources. resource.
• A relation type: A string that defines the nature of the relationship.
• Optional target attributes: Additional key-value pairs that further describe the link or the target resource.

Metadata distinguishes between resources and their representations, allowing for multiple media types where applicable. For containers, metadata includes membership details and supports pagination to handle large sets efficiently. For DataResources, metadata includes representations, each with mediaType and optional sizeInBytes.

The Linkset Resource For each resource in storage, a server MUST make metadata links available as a standalone resource according to [ RFC9264 ].

• Discovery: A resource's linkset is discoverable via a Link header with the relation rel="linkset".
• Media Type: A linkset resource MUST be available as application/linkset+json.
• Integrity: The 'linkset' link MUST point to a server-managed resource. Updates to the linkset MUST be atomic with associated resource operations to maintain consistency.

Discovering Metadata Clients discover metadata primarily through Link headers in response to GET or HEAD requests.

• Storage Description: Servers MUST support a Link header with rel="storageDescription" on relevant responses.
• Preferences: Clients MAY use the Prefer header [ RFC7240 ] with the URI https://www.w3.org/ns/lws#PreferLinkRelations to include or omit specific relations.

Metadata Types

Modifiability Considerations Core metadata MAY be modified by clients. To ensure interoperability, servers MUST use standard HTTP headers to advertise their capabilities:

1. Method Discovery: Servers MUST advertise support for GET and PATCH operations on the linkset resource via the Allow header.

2. Patch Format Discovery: Servers MUST advertise support for JSON Merge Patch [ RFC7386 ] via the Accept-Patch header: Accept-Patch: application/merge-patch+json.

3. Optional Methods: Servers MAY support PUT or alternative patch formats; if supported, these MUST be included in the Allow and Accept-Patch headers respectively.

[!IMPORTANT] Clients SHOULD NOT assume support for PUT or specific patch formats unless they are advertised in the resource headers and MUST handle 405 Method Not Allowed or 415 Unsupported Media Type responses gracefully.

Managing Metadata Metadata is managed by interacting with the resource's associated linkset URI. Servers MUST support concurrency controls (e.g., ETags) for updates.

• Partial Updates (PATCH): This should cover is the primary mechanism for metadata management. Servers MUST support PATCH using application/merge-patch+json.

• Replacement (PUT): If advertised in the Allow header, a client MAY replace the entire linkset. If the server does not support PUT, it MUST reject the request with 405 Method Not Allowed.

• Restrictions: Servers MAY restrict modifications to specific links (like partOf or contains) to maintain system integrity (e.g., preventing resource "moves" that break slash-based semantics). If a server restricts partOf modifications, it MUST document this in its conformance statement.

• Lifecycle: Metadata lifecycles are tied to the described resource; deleting a resource MUST result in the automatic removal of its associated linkset metadata.

New resources are created using POST to a target container creation, membership management, URI, with the server assigning the final identifier. Clients MAY suggest a name via the Slug header. Clients MAY provide initial user-managed metadata for the new resource by including one or more Link headers in the POST request, following the syntax of Web Linking in [ RFC8288 ]. Server-managed metadata MUST be generated automatically by the server upon creation and MUST NOT be overridden by client-provided links. On success, return the relationship 201 status code with the new URI in the Location header. The server MUST include Link headers for key server-managed metadata, such as a link to the parent container (rel="partOf"), a link to the ACL resource (rel="acl"), and a link to its dedicated linkset resource (rel="linkset"; type="application/linkset+json"). Additional links SHOULD include rel="type" (indicating Container or DataResource) and rel="mediaType" if applicable. The body MAY be empty or include a minimal representation of the resource. All metadata creation and linking MUST be atomic with the resource creation to maintain consistency.

POST (to a container URI) – Create with server-assigned name: Use POST to add a new resource inside an existing container. The server assigns an identifier to the resource, optionally suggested via the Slug header. The server MAY honor the Slug header if it does not conflict with naming rules or existing resources. Clients MUST include a Content-Type header in the request to indicate the media type of the new resource, enabling the server to distinguish between resource types. Specifically, servers MUST interpret the Content-Type as follows: if it matches the LWS-defined media type for containers (application/lws+json), the server creates a Container; otherwise, it creates a DataResource with the specified media type.

Example (POST to create a new data resource):

POST /alice/notes/ HTTP/1.1Host: example.comAuthorization: Bearer <token>Content-Type: text/plainContent-Length: 47Slug: shoppinglist.txtmilkeggsbreadbutterapplesorange juice

In this example, the client is posting to the container /alice/notes/ . It provides text/plain content (a grocery list) and suggests the resources they contain. name shoppinglist.txt for the new resource. If /alice/notes/ exists and the client is authorized, the server will create a new DataResource (based on the Content-Type), generate associated metadata, and link it via the linkset.

Example (Response to POST):

HTTP/1.1 201 CreatedLocation: /alice/notes/shoppinglist.txtContent-Type: text/plain; charset=UTF-8ETag: "def789012"Link: </alice/notes/shoppinglist.txt.meta>; rel="linkset"; type="application/linkset+json"Link: </alice/notes/>; rel="partOf"Link: </alice/notes/shoppinglist.txt.acl>; rel="acl"Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"Content-Length: 0

On success, return 201 Created with the new URI in the Location header. The body may be empty or a minimal representation. Include relevant headers such as Content-Type matching the created resource; Content-Length: 0 indicates no body. Server responses MUST use entity tags for responses that contain resource representations or successful responses to HEAD requests, enabling concurrency control in subsequent operations. If the target container /alice/notes/ does not exist, the server MUST return a 404 error status unless another status code is more appropriate.

Creating Containers: To create a new container via the REST API, a client uses POST to an existing parent container, with the Content-Type header set to the LWS-defined media type application/lws+json to indicate container creation. The body MAY be empty. Servers MUST support creation of containers using this media type. For example:

POST /alice/ HTTP/1.1Host: example.comAuthorization: Bearer <token>Content-Type: application/lws+jsonContent-Length: 0Slug: notes

This would create a new container at /alice/notes/ , with server-generated metadata including rel="type" as https://www.w3.org/ns/lws#Container .

Additional notes on Create (HTTP binding):

• POST is not idempotent. Repeating it may create duplicates; clients SHOULD avoid unintentional retries or use unique identifiers/checks to prevent this.
• Servers MUST distinguish between DataResource and Container types in metadata upon creation, based on the Content-Type header in the request.
• Metadata updates are atomic; servers MUST ensure the linkset resource is created and populated with mandatory server-managed fields before returning success.
• For discoverability, servers SHOULD include a Link header with rel="storageDescription" on 401 responses to guide clients without hardcoded URIs.

Managing and Retrieving Metadata (Related to Creation): While metadata is primarily retrieved via read operations (Section 9.3), it is generated during creation. Clients can immediately retrieve it post-creation using GET or HEAD on the new resource URI. As described in Section 9.1, clients can use the Prefer header to request inclusion of specific metadata links (via relation types) and attributes.

The read resource operation requests a resource representation with HTTP GET requests (and HEAD for header-only requests). The behavior differs depending on whether the target URL is a container or a non-container resource (DataResource). Servers MUST distinguish resource types via metadata. All responses MUST integrate with metadata as defined in Section 9.1, including Link headers for key relations such as rel="linkset", rel="acl", rel="partOf", and rel="type". Servers MUST ensure atomicity between the resource state and its metadata during reads.

GET (non-container resource) – Retrieve a resource’s content: Send GET to the resource URI for full content (if authorized). Respond with 200 OK, body containing the data, and Content-Type matching the stored media type. Servers MUST support range requests per [ RFC7233 ] for partial retrieval. Responses MUST include an ETag header for concurrency control and caching.

Example (GET a file):

GET /alice/notes/shoppinglist.txt HTTP/1.1Authorization: Bearer <token>Accept: text/plain

This strawman requests the content of /alice/notes/shoppinglist.txt , indicating that the client wants it in text form. Assuming the resource exists, is text, and the client has access:

HTTP/1.1 200 OKContent-Type: text/plain; charset=UTF-8Content-Length: 34ETag: "abc123456"Link: </alice/notes/shoppinglist.txt.meta>; rel="linkset"; type="application/linkset+json"Link: </alice/notes/>; rel="partOf"Link: </alice/notes/shoppinglist.txt.acl>; rel="acl"Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
milk
cheese
bread
guacamole
soda
chocolate bars
hash
eggs


mapping

The server returned the text content (34 bytes in total, as indicated by Content-Length ). The content is exactly the stored data in the file. The ETag: "abc123456" is a version identifier for caching or concurrency purposes. The response includes Link headers for metadata discoverability, with mandatory fields such as partOf, acl, and type.

GET (container resource) – List a container’s contents: When the target URI corresponds to a container (determined via metadata type), a GET request will return a listing of the operations container’s members rather than raw content. Servers MUST support pagination for large memberships, using query parameters or headers to return partial listings with links to subsequent pages, responding with 206 Partial Content for paginated responses. Listings MUST include metadata for each member: resource IDs ( MUST ), types as an array of system and user-defined ( MUST ), representations with mediaType and optional sizeInBytes ( MUST for DataResources), modified timestamps ( SHOULD ).

Example (GET a container with JSON-LD):

GET /alice/notes/ HTTP/1.1Authorization: Bearer <token>Accept: application/ld+json

Assuming the container exists and the client has access:

HTTP/1.1 200 OKContent-Type: application/ld+json; profile="https://www.w3.org/ns/lws/v1"ETag: "container-etag-789"Link: </alice/notes/.meta>; rel="linkset"; type="application/linkset+json"Link: </alice/>; rel="partOf"Link: </alice/notes/.acl>; rel="acl"Link: <https://www.w3.org/ns/lws#Container>; rel="type"
{
  "@context": "https://www.w3.org/ns/lws/context/v1.jsonld",  "@id": "/alice/notes/",  "@type": "Container",  "totalItems": 2,  "first": {    "@type": "ContainerPage",    "@id": "/alice/notes/?page=1",    "partOf": "/alice/notes/",    "contains": [
      {
        "@id": "/alice/notes/1.txt",        "@type": ["DataResource", "http://example.org/customType"],        "representation": [
          {
            "mediaType": "text/plain",            "sizeInBytes": 1024
          }
        ],
        "modified": "2025-11-24T12:00:00Z"
      },
      {
        "@id": "/alice/notes/2.txt",        "@type": "DataResource",        "representation": [
          {
            "mediaType": "text/plain",            "sizeInBytes": 2048
          }
        ],
        "modified": "2025-11-24T13:00:00Z"
      }
    ]
  }
}

In this example, /alice/notes/ is a container. The response uses JSON-LD with a normative context, listing members with required metadata. For large containers, the response might include a "next" property and use 206 Partial Content. In all cases, the server MUST include the following metadata in the response headers: an ETag (representing the listing version, which changes on membership modifications), and Link headers with rel="type" indicating it is a container, rel="linkset", rel="partOf", and rel="acl".

HEAD (any resource or container) – Headers/metadata only: The LWS server MUST support HEAD [ RFC9110 ] for both containers and non-containers, returning the same headers as GET (including ETag, Content-Type, Link for metadata) but without a body. This enables metadata retrieval without transferring content.

Caching and Conditional Requests: LWS leverages HTTP caching semantics. Servers MUST support conditional requests via If-None-Match (with ETags) or If-Modified-Since headers. If the resource or container listing has not changed, respond with 304 Not Modified to avoid redundant transfers. ETags MUST be provided in all GET/HEAD responses for concurrency and caching support.

Discoverability and Authorization: For enhanced discoverability, servers SHOULD include WWW-Authenticate headers on 401 Unauthorized responses with parameters to guide clients without hardcoded URIs. Metadata links SHOULD be included where applicable.

The update resource modifies the contents of an existing served resource by a PUT request (to replace the entire resource) or a PATCH request (to apply a partial modification). The client must have write access to the resource’s URL to perform these operations. Note: This section describes updating a resource's primary content. To update its metadata, see Section 9.3.2. LWS servers MUST handle PUT and PATCH requests on resource URIs as modifications to the resource content only, with no default impact on the associated linkset. To optionally update both content and metadata in a single atomic operation, clients MAY include Link headers in the PUT/PATCH request to the resource URI and specify the preference 'Prefer: set-linkset' (as defined above in RFC 7240). In this case, the server MUST interpret the provided Link headers as a replacement (for PUT) or partial update (for PATCH) to the linkset, in addition to applying the content changes. This behavior is OPTIONAL for servers but, if supported, MUST be invoked explicitly via the Prefer header to prevent unintentional metadata overwrites. Servers that do not support combined updates MUST ignore the preference or respond with 501 Not Implemented.

PUT (replace full resource) – Send PUT to the resource URI with new full content in the body and matching Content-Type (generally consistent with existing type). PUT is idempotent for existing resources. For safety, include If-Match with current ETag (per Section 7.3 concurrency); mismatch yields 412 Precondition Failed or 409 Conflict. Without checks, updates are unconditional but risk overwriting concurrent changes. If a server supports Etags for a resource, it MUST reject unconditional PUT requests that lack an If-Match header with a 428 Precondition Required response.

Example (PUT to update a resource):

PUT /alice/personalinfo.json HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json
If-Match: "abc123456"
{
"name": "Alice",
"age": 30,"city": "New London","state": "Connecticut"
}

In this example, the client is updating an existing JSON resource at /alice/personalinfo.json. It includes an If-Match header with the ETag "abc123456" that it got from an earlier GET or HEAD request. The server will compare that to the current ETag; if they match, it proceeds to replace the content with the JSON provided. If they don’t match, the server rejects the update (because the resource was changed by someone else in the meantime). Successful response: If the update succeeds, the server can respond with 200 OK and possibly include the updated representation or some confirmation (like the new content or a part of it). Alternatively, the server may respond with 204 No Content to indicate success with no body (especially common if no further info needs to be conveyed). In either case, the server SHOULD include a new ETag to signify the new version, and maybe a Content-Type if a body is returned. For example:

HTTP/1.1 204 No ContentETag: "def789012"

This tells the client the update went through and provides the new ETag . If the server chose to return the updated content, it might use 200 OK and include the JSON in the body, along with headers.

• Error responses: If the If-Match did not match (concurrent modification), the server could return 412 Precondition Failed (meaning the precondition header failed) or 409 Conflict – our earlier abstract description used Conflict for concurrency issues, and 409 is a natural mapping for that scenario. If the resource did not exist, a PUT meant as an update will result in 404 Not Found (unless the intent was to create, but typically clients use PUT for create only when they are sure of what they’re doing, or they use it as upsert without If-Match). If the client is not authorized, 403 Forbidden (or 401 Unauthorized if no valid credentials were provided). If the request payload is not valid, 400 Bad Request .

PATCH (partial update) – The HTTP PATCH method [ RFC5789 ] allows a client to specify partial modifications to a resource, rather than sending the whole new content. This is useful for large resources where sending the entire content would be inefficient if only a small part changed, or for concurrent editing where you want to apply specific changes. LWS REST Servers server MUST minimally support JSON Merge Patch (application/merge-patch+json) as defined in [ RFC7386 and ].

Update Resource Metadata (HTTP PUT / PATCH on Linkset) A resource's metadata is updated by modifying its corresponding linkset resource, discovered via the Link header with rel="linkset". Full Replacement (PUT): A PUT request to the linkset URI with a complete linkset document in the body replaces all metadata for the resource. Partial Update (PATCH): A PATCH request to the linkset URI adds, removes, or modifies specific links.

Concurrency Control for Metadata Because a resource's metadata can be modified by multiple actors, preventing concurrent overwrites is critical. To ensure data integrity, LWS REST Clients servers and clients MUST implement optimistic concurrency control using conditional requests [ RFC7232 ] for all PUT and PATCH operations on a linkset resource. Server Responsibilities: A server MUST include an Etag header in its responses to communicate over HTTP GET and HEAD requests for a linkset resource. Upon a successful PUT or PATCH on the linkset, the server MUST generate a new, unique Etag value for the modified linkset and return it in the Etag header of the response. Client Responsibilities: When modifying a linkset resource, a client MUST include an If-Match header containing the most recent Etag it received for that resource. Processing Rules: If the If-Match header value does not match the linkset's current Etag, the server MUST reject the request with a 412 Precondition Failed status code. If the If-Match header is missing from a PUT or PATCH request to a linkset URI, the server MUST reject the request with a 428 Precondition Required status code [ RFC6585 ]. Example (PUT to replace a linkset): A client first fetches the linkset and receives its ETag.

GET /alice/personalinfo.json.meta HTTP/1.1
Authorization: Bearer <token>
Accept: application/linkset+json
HTTP/1.1 200 OK
Content-Type: application/linkset+json
ETag: "meta-v1"
{
  "linkset": [
    {
      "anchor": "/alice/personalinfo.json",
      "describedby": [ { "href": "/schemas/personal-info.json" } ]
    }
  ]
}

The client now wants to add a license. It constructs a new, complete linkset document and sends a PUT request with the If-Match header.

PUT /alice/personalinfo.json.meta HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/linkset+json
If-Match: "meta-v1"
{
  "linkset": [
    {
      "anchor": "/alice/personalinfo.json",
      "describedby": [ { "href": "/schemas/personal-info.json" } ],
      "license": [ { "href": "https://creativecommons.org/licenses/by/4.0/" } ]
    }
  ]
}

If successful, the server responds with success and the new ETag.

HTTP/1.1 204 No ContentETag: "meta-v2"

Summary of Update Rules If you want to change only the content of a resource → PUT/PATCH the resource itself. If you want to change only the links (metadata) of a resource → PUT/PATCH the resource’s associated linkset resource. If you want to change both content and links → PUT/PATCH the resource itself, including the appropriate Link headers AND 'Prefer: set-linkset'. Setting both is off by default.

The delete resource operation is implemented using REST conventions. the HTTP DELETE method, as defined in the abstract operation above. This section specifies the HTTP bindings for inputs, behaviors, and responses.

The following DELETE request targets the URI of the resource or container to remove. Clients MAY include an If-Match header with an ETag for concurrency checks, as described in the abstract operation.

For non-container resources, the server processes the deletion as specified in the abstract behavior.

For container resources, the server defaults to non-recursive deletion. If recursion is desired and supported, clients MUST use the Depth: infinity header, as defined in [ RFC4918 ]. Servers that do not support recursion MUST reject such requests with 501 Not Implemented.

On success, the server MUST respond with 204 No Content. Servers SHOULD support concurrency checks via If-Match with ETags; mismatches MUST yield 412 Precondition Failed.

If the client lacks authorization, the server MUST return 403 Forbidden (if the client's identity is known but permissions are insufficient) or 401 Unauthorized (if no valid authentication is provided). In cases where revealing resource existence poses a security risk, the server MAY return 404 Not Found instead.

Example (DELETE a non-container resource):

DELETE /alice/notes/shoppinglist.txt HTTP/1.1Authorization: Bearer <token>If-Match: "abc123456"

Assuming the ETag matches and the client is authorized, the server deletes the resource, its metadata, and updates the containing container /alice/notes/ atomically:

HTTP/1.1 204 No Content

Example (DELETE a non-empty container without recursion):

DELETE /alice/notes/ HTTP/1.1Authorization: Bearer <token>

Assuming /alice/notes/ contains resources, the server refuses the deletion:

HTTP/1.1 409 ConflictContent-Type: text/plainCannot delete container /alice/notes/ - container is not empty.

Example (DELETE a container with recursion, if supported):

DELETE /alice/notes/ HTTP/1.1Authorization: Bearer <token>Depth: infinity

Assuming the server supports recursion and the client has permissions for all contents, the server deletes the container and its descendants atomically:

HTTP/1.1 204 No Content

This table maps generic LWS response responses (from Section 8) to an HTTP status code codes and payload: payloads for consistency, incorporating specific scenarios such as pagination, concurrency controls, quota constraints, and metadata integration:

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).

this left intentionally blank

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

this left intentionally blank

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

this left intentionally blank

All communications related to requesting, retrieving and presenting end-user credentials between clients and servers must use TLS-protected connections.

End-user credentials are vulnerable to theft and replay. Tokens should have a reasonably short lifetime, such as 3600 seconds (1 hour).

Clients that persist end-user credentials must take great care to store these tokens securely. Tokens should never be stored unencrypted in a browser's localStorage, in URLs or in logs.

The recommendations described in Best Current Practice for OAuth 2.0 Security [ RFC9700 ] apply to this specification.

End-user credentials carry information about users. While digital signatures can protect end-user credentials against tampering, it is possible for clients or other third parties to read the values inside an unencrypted credential.

As a result, issuers should create end-user credentials that contain only the information necessary for authentication. Avoid including sensitive attributes unless required.

Implementations should not log the full contents of an end-user credential. If logging is necessary, tokens should be truncated or hashed.

Minimal Disclosure: Authorization servers should issue tokens containing only information necessary for authorization. Avoid including sensitive subject attributes unless required.

Logging: Implementations should not log full token contents. If logging is necessary, tokens should be truncated or hashed.

When using pseudonymous identifiers in JWTs, client applications should request a batch issuance of JWTs and each JWT should be used only one time against the storage server. This makes it harder for a storage server to use pseudonymous identifiers to correlate requests. This does not prevent the storage server from using other information such as similarities in JWT content or originating IP address to correlate requests. When using pseudonymous identifiers, the authorization server should not issue the same pseudonymous identifier more than once.