lws10 core

Linked Web Storage Protocol 1.0 W3C Working Draft 21 August 2026 More details about this document This version: https://www.w3.org/TR/2026/WD-lws10-core-20260821/ Latest published version: https://www.w3.org/TR/lws10-core/ Latest editor's draft: https://w3c.github.io/lws-protocol/lws10-core/ History: https://www.w3.org/standards/history/lws10-core/ Commit history Editors: Jesse Wright ( University of Oxford ) Erich Bremer ( Stony Brook University ) Feedback: GitHub w3c/lws-protocol ( pull requests , new issue , open issues ) Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract The Linked Web Storage Protocol specification aims to provide applications with secure and permissioned access to externally stored data in an interoperable way. Status of This Document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index . This is an unofficial proposal. This document was published by the Linked Web Storage Working Group as a Working Draft using the Recommendation track . Publication as a Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Document Conventions 2. Introduction 2.1 Resource Access 2.2 Security and Privacy 2.3 Conformance 2.4 Scope Diagrams 3. Terminology 4. Authentication 4.1 Authentication Credential Data Model 4.2 Authentication Credential Validation 4.3 Authentication Credential Type Identifiers 5. Authorization 5.1 Roles 5.2 Protocol Flow 5.2.1 Authorization Server Discovery 5.2.2 Authorization Server Metadata 5.2.3 Token Exchange 5.2.3.1 Request 5.2.3.2 Response 5.2.3.3 Example access token 5.2.4 Token Validation by a Storage Server 5.2.4.1 Presentation 5.2.4.2 Validation 6. Discovery 6.1 Storage Description Resource 6.1.1 Data Model 6.1.2 Discovery and Binding 6.1.3 Storage Capabilities 6.1.4 Storage Services 6.1.5 Storage Description Representation 7. Logical Resource Organization 7.1 Container Model 7.2 Containment 7.3 Containment Integrity 7.4 Resource Identification 7.5 Container Membership and Authorization 8. Containers 8.1 Container Representation 8.1.1 Container Properties 8.1.2 Contained Resource Description 8.1.3 Example Container Representation 9. Operations 9.1 Metadata 9.2 Create resource 9.3 Read resource 9.4 Update resource 9.5 Delete resource 9.6 Summary of HTTP Status Mappings 10. Notifications 10.1 Notification Discovery 10.2 Notification Data Model 10.2.1 Envelope Properties 10.2.2 Activity Properties 10.2.3 Activity Types 10.2.4 Batching Notifications 10.3 Subscriptions 10.3.1 Subscription Request 10.3.2 Subscription Scope 10.3.3 Subscription Authorization 10.3.4 Subscription Response 10.3.5 Subscription Type Identifiers 11. Access Requests and Grants 11.1 Discovery 11.2 Data Model 11.2.1 Types 11.2.2 Storage 11.2.3 Inbox 11.2.4 Access 11.3 Access Profile 11.3.1 Types 11.3.2 Actions 11.3.3 Assignee 11.3.4 Targets 11.3.5 Constraints 11.3.5.1 Purpose Constraints 11.3.5.2 Client Constraints 11.3.5.3 Format Constraints 11.3.5.4 Resource Type Constraints 11.3.5.5 Temporal Constraints 11.3.5.6 Combining Constraints 11.4 Serialization 11.4.1 JSON-LD Serialization 11.5 Protocol 11.5.1 Access Request Endpoint 11.5.2 Access Grant Endpoint 11.6 Notifications 11.6.1 Notification Events 12. LWS Media Type 12.1 LWS Media Type 12.1.1 Media Type Equivalence 12.1.2 Pagination 12.1.2.1 Pagination Model 12.1.2.2 Pagination Link Relations 12.1.2.3 Requesting Pages 12.1.2.4 Example: Paginated Container 13. JSON-LD Context 14. Resource Identification 15. Portability Considerations 16. Security Considerations 16.1 Transport Security 16.2 Token Security 16.3 Access Requests and Grants 16.4 Notifications 17. Privacy Considerations 17.1 Access Requests and Grants 17.2 Notifications 18. IANA Considerations 18.1 well-known URI Registry 18.2 OAuth Authorization Server Metadata Registry 18.3 The application/lws+json Media Type 18.4 The application/lws+cid Media Type A. Acknowledgements B. References B.1 Normative references B.2 Informative references 1. Document Conventions This section is non-normative. 2. Introduction This specification defines the Linked Web Storage (LWS) Protocol, which enables client applications to access and manage web resources, based on the identity and permissions of an agent. By standardizing how a resource server manages and provides access to a hierarchy of linked resources, the protocol enables users to use different 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. 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 agent's identity is confirmed through an identity provider that can be external to the Linked Web Storage server. This loose coupling means the server does not necessarily manage credentials directly; rather, it can receive and validate a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present an existing identity to a compliant server, without always needing a new or existing account just for that server. LWS makes use of user authentication as defined in specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers (CIDs), for example. Authorization determines whether a requesting agent 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: Developers building client applications that access LWS resources Developers building compliant servers that mediate access to LWS resources Different LWS server instances each maintain their own hierarchy of linked resources. An agent might use the same identification to navigate across servers, with access to each server's resources determined by the permissions granted by that server's resource managers. It is not guaranteed that every LWS server instance will support every possible agent identifier; any given LWS server instance might require that an agent identify itself via a particular identity provider, to gain access to resources managed by that server instance. 2.1 Resource Access The LWS Protocol defines standard interactions by which 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. 2.2 Security and Privacy A resource manager may keep a served resource private, may make it publicly available to anyone, or may limit 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 . 2.3 Conformance 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 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 9. Operations of this document MUST be respected. An LWS 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 9. Operations of this document MUST be respected. 2.4 Scope Diagrams The following diagrams are platform-independent models to guide implementation. Figure 1 System Context shows the LWS System and its major components. 3. 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 ]. This specification defines the following terms: access grant — a data object created by a storage controller , expressing an ability for an agent to perform specific actions on storage resources within certain defined constraints. access profile — an access profile describes the requirements for expressing a valid access policy. Every access profile is identified with a URI, and a server indicates support for one or more access profiles by referencing them in the conformsTo property of a service object in its storage description resource. access request — a data object submitted by an agent , expressing a request to perform specific actions on storage resources, including the desired scope and constraints. agent — a person, social entity, or software identified by a URI. authentication credential — a security token that asserts claims about an agent or end-user. This token is secured with a cryptographic proof. Examples of authentication credentials include assertions of identity such as OpenID Connect ID Tokens and SAML-based assertions as well as assertions of capability such as ZCAPs. authentication suite — a defined validation mechanism for a concrete serialization of an authentication credential . auxiliary resource — an LWS resource that plays a particular role with respect to a LWS resource , called its primary resource , and whose lifetime is bound to the primary resource. This specification defines linkset resource and metadata resource as types of auxiliary resources, but LWS Servers are free to manage additional kinds of auxiliary resources (e.g. access control resources, notification inboxes). Auxiliary resources are discovered using web links [ RFC8288 ] of a specific type (see Section 9.1 Metadata ). Some auxiliary resources may, in some implementations, be identical to their primary resource. LWS resource — an HTTP resource as defined in HTTP Semantics which supports the read operations defined by the Linked Web Storage Protocol. Following HTTP Semantics , this specification "does not limit the nature of a [LWS] resource; it merely defines an interface that might be used to interact with [LWS] resources." [ RFC9110 ] container — an LWS resource that is able to enumerate a collection of LWS resources , conforming to the conventions described in Section 8. Containers . The ability to create new resources in a container or to delete an existing container follows the requirements outlined in Section 9. Operations . data resource — a data-bearing LWS resource such as a document, image, or structured information whose support for update and delete operations follows the requirements outlined in Section 9. Operations . containment — the relationship between a container and the LWS resources whose lifecycle the container manages. linkset resource — a type of auxiliary resource whose representation conforms to Linkset: Media Types and a Link Relation Type for Link Sets . Update operations for linkset resources follow the requirements outlined in Section 9. Operations . metadata resource — an auxiliary resource , managed by a storage , that describes an LWS resource and conforms to the conventions described in TBD . The lifecycle of a metadata resource is bound to the LWS resource it describes. resource — a resource is, as described by [ WebArch ] and [ RFC3986 ], “whatever might be identified by a URI”. Resources whose essential characteristics can be conveyed in a message (such as web pages, images, structured data objects...) are called information resources [ WebArch ]. storage — a set of hierarchically organized HTTP resources whose lifecycle is managed by the conventions described by the Linked Web Storage Protocol. A storage is described by a storage description resource which references a collection of services that provide affordances over those resources. storage controller — an agent that controls all resources in a storage . storage description — an LWS resource , conforming to the requirements of a W3C Controlled Identifier document [ CID-1.0 ], that describes a storage along with its services and capabilities. storage root — a container at the root of a containment hierarchy of a storage . The storage root is the only LWS resource that does not have a parent in the LWS containment hierarchy nor a primary resource . notification — a message describing an event that has occurred on a resource. subscription — a registration expressing interest in receiving notifications for a given resource or set of resources. subscriber — the agent that creates a subscription and receives the resulting notifications. notification suite — a defined delivery mechanism for a concrete channel through which notifications are sent to a subscriber . (Feature at Risk) Issue : Section may be removed 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 : create resource - read resource - update resource - delete resource - 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 . not permitted unknown requester unknown error - reserved for error conditions that arise that are not anticipated by the specification 4. Authentication This section defines a mechanism for identifying agents and end users that interact with a linked web storage server. This specification does not mandate a particular format for an authentication credential , though it does describe how existing identity systems can be used in conjunction with the linked web storage authorization framework. 4.1 Authentication Credential Data Model The data model described in this section outlines the requirements for any concrete serialization of an authentication credential . An authentication credential MUST include tamper evident claims about a subject, including: subject REQUIRED — an identifier for an end user. This MUST be a URI. issuer REQUIRED — an identifier for the entity that issued the authentication credential . This MUST be a URI. client REQUIRED — an identifier for a client application. This SHOULD be a URI. audience restriction RECOMMENDED — a list of values that SHOULD include an authorization server identifier. 4.2 Authentication Credential Validation Validation of an authentication 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 authentication credential MUST be signed. It is RECOMMENDED that the signature uses asymmetric cryptography. 4.3 Authentication Credential Type Identifiers 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. 5. Authorization Linked Web Storage describes a mechanism for persisting and managing protected data on the Web. Authorization is the mechanism by which agents request and present access tokens in order to access this protected data. This section defines an authorization framework based on OAuth 2.0 [ RFC6749 ] as the baseline mechanism for obtaining and presenting access tokens. A server MAY support additional authorization mechanisms beyond this baseline. 5.1 Roles 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. 5.2 Protocol Flow 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. 5.2.1 Authorization Server Discovery All protected resources managed by a storage server require a valid access token, generated by a trusted authorization server. A client can discover the location of a trusted authorization server by making an unauthorized HTTP request to a protected resource. A storage server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one conforming challenge. A conforming challenge will include the parameters described below: as_uri REQUIRED — The value of this parameter is a URI identifying the authorization server where a client can retrieve an access token. The value of this parameter will be the same as the iss claim of a valid access token. realm REQUIRED — The value of this parameter is a URI indicating the scope of protection. This value will be included in the audience ( aud ) claim of an access token. A client MUST verify that the URI of the originating request is logically contained within the realm presented in this response. Other headers and parameters MAY be included. An example 401 response is included below. Example 1 HTTP / 2 401 Unauthorized Link : <https://storage.example/storage_1> ; rel= "https://www.w3.org/ns/lws#storage" WWW - Authenticate : Bearer as_uri= "https://authorization.example" , realm= "https://storage.example/storage_1" , error= "invalid_token" 5.2.2 Authorization Server Metadata An authorization server MUST provide a metadata resource to allow clients to discover endpoint locations and capabilities as described in [ RFC8414 ]. This metadata resource MUST be available at a URL with the path /.well-known/lws-configuration . An authorization server SHOULD advertise the subject tokens that it supports by including a subject_token_types_supported entry in the server metadata document. This entry is a JSON array containing a list of valid subject_token_type values that can be supplied at the authorization server's token endpoint. An example authorization server metadata resource is included below. Example 2 { "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" ] } 5.2.3 Token Exchange An LWS authorization server is a conforming OAuth 2.0 authorization server, capable of issuing access tokens to a client for use with a storage server. In order to issue an access token, a client must first present a valid subject token, such as an authentication credential , to the authorization server via OAuth 2.0 Token Exchange [ RFC8693 ]. 5.2.3.1 Request The authorization server's token endpoint MUST support the urn:ietf:params:oauth:grant-type:token-exchange grant type, as described in OAuth 2.0 Token Exchange [ RFC8693 ]. When performing the token exchange grant type, the following additional requirements apply: The resource parameter is REQUIRED . The value of this parameter MUST be a URI and will be used to populate the aud (audience) claim in the resulting access token. The supplied value will be the same as the realm parameter response in a WWW-Authenticate challenge. The authorization server MUST reject any request in which the resource parameter identifies an unknown or untrusted storage . The subject_token parameter is REQUIRED . The value of this parameter MUST include a valid subject token, such as an authentication credential . Before returning an access token to the client, the authorization server MUST successfully validate all presented tokens. Non-normative example of a token request (the subject_token parameter has been truncated). Example 3 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 5.2.3.2 Response If the token request is valid and the client is authorized to make the request, the authorization server response MUST conform to Section 5.1 from the OAuth 2.0 Authorization Framework [ RFC6749 ]. The resulting access token MUST conform to the JSON Web Token Profile for OAuth 2.0 Access Tokens [ RFC9068 ]. In addition, the access token must meet the following requirements: sub (subject) — REQUIRED . This claim MUST be a URI identifying the agent performing the operation iss (issuer) — REQUIRED . This claim MUST be the URI of the authorization server client_id (client id) — REQUIRED . This claim MUST be a URI identifying the client. aud (audience) — REQUIRED . This claim MUST include the URI supplied by the client in the resource parameter. This value will be used to restrict the entities for which the access token is valid. This will be the same value as provided by a storage server in the realm parameter of a WWW-Authenticate challenge. exp (expiration) — REQUIRED . Authorization servers SHOULD issue tokens with short lifetimes ( RECOMMENDED : 300 seconds or less) to limit exposure from token theft. iat (issued at) — REQUIRED . jti (JWT ID) — REQUIRED . A non-normative example of a successful token response is included below. Example 4 HTTP/1.1 200 OK Content-Type : application/json { "access_token" : "eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso" , "token_type" : "Bearer" , "expires_in" : 3600 } All invalid or unauthorized requests MUST result in an error response as described in Section 5.2 in the OAuth 2.0 Authorization Framework [ RFC6749 ]. Example 5 HTTP/1.1 400 Bad Request Content-Type : application/json { "error" : "invalid_request" } 5.2.3.3 Example access token This section is non-normative. An example access token issued by an authorization server is included below. Example 6 { "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 5.2.4 Token Validation by a Storage Server Once a client is in possession of an access token, it will present this token to a storage server. The storage server is responsible for verifying this token before performing any operation. 5.2.4.1 Presentation A client MUST present an access token to a storage server using the Authorization header with an authentication scheme as defined in [ RFC6750 ]. Example 7 Authorization : Bearer eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso 5.2.4.2 Validation A storage server MUST validate an access token by performing the following checks, rejecting the request upon any failure: JWT Signature Validation: Verify the JWT signature using the authorization server's public key retrieved from the jwks_uri specified in the authorization server metadata. Storage servers SHOULD cache these keys and MUST support key rotation. Issuer Validation: Verify the iss claim matches the expected authorization server identifier. Audience Validation: Verify the aud claim contains exactly one value and this value is a URI identifying the storage server which logically contains the target resource. Temporal Validation, subject to an allowable clock skew between systems. Verify the current time is before the exp (expiration) claim. Verify the current time is not before the nbf (not before) claim, if present. Verify that the iat (issued at) claim is not in the future. If validation fails, the storage server MUST return 401 Unauthorized with a WWW-Authenticate header containing an appropriate error parameter (e.g., invalid_token, invalid_request, or insufficient_scope). If the token is otherwise valid but an authorization policy does not allow the requested operation, the storage server MUST reject the request. 6. Discovery 6.1 Storage Description Resource A storage description resource provides information a client can use when interacting with a storage , including descriptions of capabilities and service endpoints. 6.1.1 Data Model A storage description resource is a specialization of a W3C Controlled Identifier document [ CID-1.0 ]. It conforms to the data model defined by [ CID-1.0 ], extended with LWS-specific properties. id - the id property is REQUIRED . Its value MUST be the canonical URI of the storage . Per [ CID-1.0 ], this URI is also the canonical URL of the controlled identifier document. type - the type property is REQUIRED . Its value MUST be a string that equals Storage or a set of strings that contains an item equal to Storage (case-sensitive). capability - the capability property is OPTIONAL . Its value MUST be a set of capabilities, where each capability is described by a map containing the following properties. Additional properties MAY be present. id - the id property is OPTIONAL . If present, its value MUST be a URI. type - the type property is REQUIRED . Its value MUST be a string or a set of strings. service - the service property is REQUIRED . Its value MUST be a set of services, where each service is described by a map containing the following properties. Additional properties MAY be present. The set MUST contain a service whose type equals StorageRoot . id - the id property is OPTIONAL . If present, its value MUST be a URI. type - the type property is REQUIRED . Its value MUST be a string or a set of strings. serviceEndpoint - the serviceEndpoint property is REQUIRED . Its value MUST be a URI. Example 8 : Minimum storage description resource { "@context" : [ "https://www.w3.org/ns/cid/v1" , "https://www.w3.org/ns/lws/v1" ] , "id" : "https://storage.example/" , "type" : "Storage" , "service" : [ { "type" : "StorageRoot" , "serviceEndpoint" : "https://storage.example/root/" } ] } 6.1.2 Discovery and Binding All responses to GET and HEAD requests targeting storage resources MUST include a Link header whose target is the canonical URI of the storage , including a relation ( rel ) parameter whose value equals https://www.w3.org/ns/lws#storage . Requests for the storage URI MUST return a document that conforms to the storage description resource data model with a media type of application/lws+cid , unless content negotiation requires a different format. 6.1.3 Storage Capabilities A storage description may contain descriptions of additional capabilities supported by the storage . 6.1.4 Storage Services A storage description resource MUST contain a StorageRoot service whose serviceEndpoint is the URI of the storage root container. Additional services connected to a storage MAY also be present. The API definition of these additional services are outside the scope of this specification. 6.1.5 Storage Description Representation A storage description MUST be serializable with the media type application/lws+cid . The @context property MUST be an array starting with the URIs https://www.w3.org/ns/cid/v1 and https://www.w3.org/ns/lws/v1 . Other representations MAY be available via content negotiation. Example 9 : Storage description resource { "@context" : [ "https://www.w3.org/ns/cid/v1" , "https://www.w3.org/ns/lws/v1" ] , "id" : "https://storage.example/" , "type" : "Storage" , "capability" : [ { "type" : "https://feature.example/PatchSupport" , "format" : { "text/turtle" : [ "application/sparql-update" ] , "application/n-triples" : [ "application/sparql-update" ] , "application/linkset+json" : [ "application/merge-patch+json" , "application/json-patch+json" ] } } , { "type" : "https://feature.example/ResumableUploads" } , { "type" : "https://feature.example/ContentNegotiation" , "source" : "application/ld+json" , "target" : [ "text/turtle" , "application/n-triples" ] } , { "type" : "https://feature.example/ContentNegotiation" , "source" : "image/jpeg" , "target" : [ "image/png" ] } ] , "service" : [ { "type" : "StorageRoot" , "serviceEndpoint" : "https://storage.example/root/" } , { "type" : "NotificationService" , "serviceEndpoint" : "https://storage.example/notification/api" , "subscriptionType" : [ "WebhookSubscription" ] } , { "type" : "TypeIndexService" , "serviceEndpoint" : "https://storage.example/types/index" } , { "type" : "TypeSearchService" , "serviceEndpoint" : "https://storage.example/types/search" } , { "type" : "DataSharingService" , "serviceEndpoint" : "https://storage.example/sharing/api" } ] } 7. Logical Resource Organization 7.1 Container Model Linked Web Storage organizes resources into containers . A container is a specialized resource that holds references to other resources, called its members. Containers serve as organizational units, analogous to directories or collections, enabling clients to group, discover, and navigate resources. 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. The structure of container representations is defined in 8.1 Container Representation ; their media type and pagination requirements are defined in 12. LWS Media Type . Storage MAY function as a root container, enabling direct writes. Every LWS storage has a storage root that serves as the top-level organizational unit. The storage root has no parent and acts as the entry point for the storage hierarchy. Resources in LWS are classified as either: Container — a resource that contains other resources. Data resource — a data-bearing resource (e.g., a document, image, or structured data file). 7.2 Containment The containment relationship between a resource and its parent container is expressed via the rel="up" link relation. Servers MUST include a Link header with rel="up" pointing to the parent container in responses to GET and HEAD requests on any non-root resource. Link : < /alice/ notes/>; rel= "up" A container 's members are listed in its representation using the items property. The server manages this list; clients cannot modify it directly. Membership changes occur as a side effect of resource creation and deletion. 7.3 Containment Integrity The server MUST maintain containment integrity at all times: Creation : When a new resource is created in a container , the server MUST atomically add the resource to the container 's items list. Deletion : When a resource is deleted, the server MUST atomically remove it from its parent container 's items list. Deleting a container requires the container to be empty, unless recursive deletion is explicitly requested. No orphans : Every non-root resource MUST be reachable from the storage root through the containment hierarchy. No cycles : A container MUST NOT directly or indirectly contain itself. 7.4 Resource Identification Resources are identified by URIs. The URI of a resource is independent of its position in the containment hierarchy. Servers assign URIs during resource creation and MAY incorporate client hints, but clients SHOULD NOT assume that URI structure reflects containment. Containment relationships are expressed through metadata ( rel="up" links and the items property in container representations), not through URI path structure. This separation allows servers flexibility in URI assignment while maintaining a well-defined organizational model. 7.5 Container Membership and Authorization If a client has read access to a container , the container representation MUST include the identifiers for all resources contained in that container to which the client has access. It MAY also contain the identifiers for resources contained in that container to which the client does not have access. A client's ability to read a container listing does not imply access to the contained resources themselves, and vice versa. 8. Containers 8.1 Container Representation When a client retrieves a container , the server returns a structured container representation describing the container and its contents. This section defines the required and optional properties of a container representation. 8.1.1 Container Properties A container representation MUST include the following properties: id : The URI of the container . type : The value "Container" . totalItems : An integer indicating the total number of resources contained in the container which can be disclosed to the client. This count SHOULD be accurate but MAY be approximate. items : An array of contained resource descriptions (see below). If the container is empty, this MUST be an empty array. When the container listing is paginated, items contains only the current page of resources; see Pagination for details. 8.1.2 Contained Resource Description Each entry in the items array describes a resource contained in the container . A contained resource description MUST include: id : The URI of the contained resource. type : The type of the resource. MUST be "DataResource" or "Container" , or an array containing at least one of these two strings. Servers MAY include additional user-defined types as URIs (e.g., ["DataResource", "http://example.org/customType"] ). A contained resource description SHOULD include: format : The media type of the resource (e.g., "text/plain" , "image/jpeg" ). MUST be present for DataResources. size : The size of the resource in bytes, expressed as an integer. modified : The date and time the resource was last modified, expressed as an ISO 8601 date-time string. 8.1.3 Example Container Representation The following example shows a container at /alice/notes/ containing two resources: { "@context" : "https://www.w3.org/ns/lws/v1" , "id" : "/alice/notes/" , "type" : "Container" , "totalItems" : 2 , "items" : [ { "type" : "DataResource" , "id" : "/alice/notes/shoppinglist.txt" , "format" : "text/plain" , "size" : 47 , "modified" : "2025-11-24T12:00:00Z" } , { "type" : [ "DataResource" , "http://example.org/customType" ] , "id" : "/alice/notes/todo.json" , "format" : "application/json" , "size" : 2048 , "modified" : "2025-11-24T13:00:00Z" } ] } 9. Operations This section defines the four core operations that a Linked Web Storage (LWS) server MUST support. These operations manipulate resources and containers in a transport-independent manner, focusing on semantics rather than implementation details. Each operation specifies inputs, expected behaviors, and possible responses. Responses include success indicators, resource representations (where applicable), and error conditions. Implementations MUST handle these operations atomically and consistently, meaning each operation either succeeds completely or fails without partial side effects. In case of errors, responses SHOULD provide enough detail for agents to understand the issue without leaking sensitive information. For each core operation (create, read, update, delete), we describe the HTTP method(s) to use, required headers or special considerations (including concurrency controls via ETags, content negotiation, and pagination for container listings), and what the server should do and return. Standard HTTP status codes are used to indicate outcomes with additional mappings for scenarios such as quota exceeded (507 Insufficient Storage) or precondition failures (412 Precondition Failed). The binding tries to adhere to HTTP/1.1 and relevant RFCs (such as [ RFC7231 ] for HTTP semantics, [ RFC7233 ] for range requests, [ RFC5789 ] for PATCH, [ RFC8288 ] for Web Linking, and [ RFC9264 ] for Link Sets) so that it integrates naturally with web standards. Discoverability is emphasized through mechanisms like Link headers and WWW-Authenticate headers on 401 responses, avoiding hardcoded URI locations. Metadata integration is required across operations, ensuring atomicity and use of Link Sets for server-managed and user-managed properties. Note: As all examples in this specifications, examples given in this section (HTTP request and response snippets) are non-normative , meant to illustrate typical usage. The actual requirements are stated in the descriptive text and tables. Also, while this binding covers HTTP (as the initial target protocol), the LWS operations could in principle be bound to other protocols in the future. Media type requirements for container representations are defined in 12. LWS Media Type . 9.1 Metadata 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, and container hierarchies. 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 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 data resources , metadata includes representations, each with format and optional sizeInBytes. For containers and data resources , we consider the link to its parent container resource to be part of the metadata of the resource. 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: Servers MUST include a Link header with rel="https://www.w3.org/ns/lws#storage" on relevant responses. Containment : Servers MUST include a Link header with rel="up" pointing to the parent container for any non-root resource. 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 Category Description System Managed Maintained by the server; Read-Only. Includes linkset , type , format , size , modified . Core Metadata Managed by the client (subject to server restrictions). Includes up , items , title , creator . User-Defined Custom vocabularies and indexes created by the user. Modifiability Considerations Core metadata MAY be modified by clients. To ensure interoperability, servers MUST use standard HTTP headers to advertise their capabilities: Method Discovery: Servers MUST advertise support for GET and PATCH operations on the linkset resource via the Allow header. Patch Format Discovery: Servers MUST advertise support for JSON Merge Patch [ RFC7386 ] via the Accept-Patch header: Accept-Patch: application/merge-patch+json . 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 resource URI. Servers MUST support concurrency controls for updates. Partial Updates (PATCH): This 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 up or items ) to maintain system integrity. Lifecycle: Metadata lifecycles are tied to the described resource; deleting a resource MUST result in the automatic removal of its associated linkset resource metadata. 9.2 Create resource The create resource operation adds a new served resource to an existing container . This operation handles both the creation of data resources 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. New resources are created using POST to a target container URI, with the server assigning the final identifier. 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, the server MUST return the 201 status code with the new URI in the Location header. The server MUST include Link headers for key server-managed metadata, including a link to the parent container ( rel="up" ), and a link to the created resource's dedicated linkset resource ( rel="linkset"; type="application/linkset+json" ). Additional links SHOULD include rel="type" (indicating https://www.w3.org/ns/lws#Container or https://www.w3.org/ns/lws#DataResource ). 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 the identifier for the resource. Clients indicate the type of resource to create as follows: To create a Container , the client MUST include a Link header with rel="type" pointing to the Container type: Link: <https://www.w3.org/ns/lws#Container>; rel="type" . To create a Data resource , the client includes the resource content in the request body with the appropriate Content-Type header. Example (POST to create a new data resource): POST /alice/notes/ HTTP/1.1 Host : example.com Authorization : Bearer <token> Content-Type : text/plain Content-Length : 47

milk eggs bread butter apples orange juice In this example, the client is posting to the container /alice/notes/ . It provides text/plain content (a grocery list) and suggests the name shoppinglist.txt for the new resource. If /alice/notes/ exists and the client is authorized, the server will create a new data resource and add it to the container 's membership. Example (Response to POST — Data Resource): HTTP/1.1 201 Created Location : /alice/notes/shoppinglist.txt Content-Type : text/plain; charset=UTF-8 Link : </alice/notes/shoppinglist.txt.meta>; rel="linkset"; type="application/linkset+json" Link : </alice/notes/>; rel="up" 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. 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 , a client uses POST to an existing parent container with a Link header indicating the Container type. For example: POST /alice/ HTTP/1.1 Host : example.com Authorization : Bearer <token> Content-Length : 0 Link : <https://www.w3.org/ns/lws#Container>; rel="type" Example (Response to POST — container): HTTP/1.1 201 Created Location : /alice/notes/ Link : </alice/notes/.meta>; rel="linkset"; type="application/linkset+json" Link : </alice/>; rel="up" Link : <https://www.w3.org/ns/lws#Container>; rel="type" Content-Length : 0 This creates 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. 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="https://www.w3.org/ns/lws#storage" on 401 responses to guide clients without hardcoded URIs. Managing and Retrieving Metadata (Related to Creation): While metadata is primarily retrieved via read operations, it is generated during creation. Clients can immediately retrieve it post-creation using GET or HEAD on the new resource URI. Clients can use the Prefer header to request inclusion of specific metadata links (via relation types) and attributes. 9.3 Read resource 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 which MAY be filtered based on authorization . Listings must include core metadata for each member. Outcome : The requested representation or a notification of failure. 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 ( data resource ). Servers MUST distinguish resource types via metadata. All responses MUST integrate with metadata as defined in Section 8.1, including Link headers for key relations such as rel="linkset" , rel="up" , 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.1 Authorization : Bearer <token> Accept : text/plain This 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 OK Content-Type : text/plain; charset=UTF-8 Content-Length : 34 ETag : "abc123456" Link : </alice/notes/shoppinglist.txt.meta>; rel="linkset"; type="application/linkset+json" Link : </alice/notes/>; rel="up" Link : <https://www.w3.org/ns/lws#DataResource>; rel="type"

milk cheese bread guacamole soda chocolate bars hash eggs 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 up 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 returns a listing of the container 's members. The response body is a container representation as defined in the Container Representation section, using the LWS container media type. The listing includes metadata for each member: resource identifiers ( MUST ), types ( MUST ), media types ( MUST for DataResources), sizes ( SHOULD ), and modification timestamps ( SHOULD ). Example (GET a container): GET /alice/notes/ HTTP/1.1 Authorization : Bearer <token> Accept : application/lws+json Assuming the container exists and the client has access: HTTP/1.1 200 OK Content-Type : application/lws+json ETag : "container-etag-789" Link : </alice/notes/.meta>; rel="linkset"; type="application/linkset+json" Link : </alice/>; rel="up" Link : <https://www.w3.org/ns/lws#Container>; rel="type" { "@context" : "https://www.w3.org/ns/lws/v1" , "id" : "/alice/notes/" , "type" : "Container" , "totalItems" : 2 , "items" : [ { "type" : "DataResource" , "id" : "/alice/notes/shoppinglist.txt" , "format" : "text/plain" , "size" : 47 , "modified" : "2025-11-24T12:00:00Z" } , { "type" : [ "DataResource" , "http://example.org/customType" ] , "id" : "/alice/notes/todo.json" , "format" : "application/json" , "size" : 2048 , "modified" : "2025-11-24T13:00:00Z" } ] } In this example, /alice/notes/ is a container . The response uses JSON-LD with the LWS context, listing members with required metadata. Each item includes its type , id , format , size , and modified timestamp as flat properties. 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" and rel="up" . 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. 9.4 Update resource Modifies the state of an existing [served resource] via full replacement or a 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 has been modified since it was last read by the requester. Outcome : Confirmation of the update or a notification of conflict. 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 resource . 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 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 Content ETag : "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 server MUST minimally support JSON Merge Patch (application/merge-patch+json) as defined in [ RFC7386 ]. 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 resource URI with a complete linkset document in the body replaces all metadata for the resource. Partial Update (PATCH): A PATCH request to the linkset resource 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 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 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 Content ETag : "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. 9.5 Delete resource 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. The delete resource operation is implemented using the HTTP DELETE method, as defined in the abstract operation above. This section specifies the HTTP bindings for inputs, behaviors, and responses. The 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. Deletion and Containment : When a resource is deleted, the server MUST atomically remove it from its parent container 's items list. The parent container's totalItems count SHOULD be updated accordingly, and its ETag MUST be updated to reflect the change. For non-container resources, the server removes the resource content, its associated metadata ( linkset resource ), and the containment reference in the parent container . For container resources, the server defaults to non-recursive deletion. If the container is not empty and recursion is not requested, the server MUST reject the request with 409 Conflict. Servers MAY support recursive deletion of all contained resources within the container that is being deleted. Clients MUST use the Depth: infinity header to request for a recursive delete, as defined in [ RFC4918 ]. On success, the server MUST respond with 204 No Content. Servers SHOULD support conditional requests, as defined in [ RFC9110 ]. 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.1 Authorization : Bearer <token> If-Match : "abc123456" Assuming the ETag matches and the client is authorized, the server deletes the resource, its metadata, and removes it from the parent container /alice/notes/ atomically: HTTP/1.1 204 No Content Example (DELETE a non-empty container without recursion): DELETE /alice/notes/ HTTP/1.1 Authorization : Bearer <token> Assuming /alice/notes/ contains resources, the server refuses the deletion: HTTP/1.1 409 Conflict Content-Type : text/plain Cannot delete container /alice/notes/ - container is not empty. Example (DELETE a container with recursion, if supported): DELETE /alice/notes/ HTTP/1.1 Authorization : 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 9.6 Summary of HTTP Status Mappings This table maps generic LWS responses (from Section 8) to HTTP status codes and payloads for consistency, incorporating specific scenarios such as pagination, concurrency controls, quota constraints, and metadata integration: LWS response HTTP status code HTTP payload Success (read or update, returning data) 200 OK Resource representation in the response body (for GET or if PUT/PATCH returns content), along with relevant headers (Content-Type, ETag, Link for metadata such as rel="linkset", rel="up"). For container listings, include JSON-LD with normative context and member metadata (IDs, types, sizes, timestamps). Created (new resource) 201 Created Typically no response body (or a minimal representation of the new resource). The Location header is set to the new resource’s URI. Headers like ETag MUST be included for concurrency; Link headers for server-managed metadata. Deleted (no content to return) 204 No Content No response body. Indicates the resource was deleted or the request succeeded and there’s nothing else to say. Servers MAY use 410 Gone for permanent deletions. Bad Request (invalid input or constraints) 400 Bad Request Error details explaining what was wrong. Servers SHOULD use the standard format defined in [ RFC9457 ] for structured error responses, such as a JSON object with fields like "type", "title", "status", "detail", and "instance". 10. Notifications This section defines a mechanism for clients to receive timely updates about changes to resources managed by a linked web storage server. This specification defines a common notification data model and a subscription mechanism; specific delivery channels are described in separate notification suite specifications. 10.1 Notification Discovery A storage MAY support notifications. A storage that supports notifications MUST advertise a service object in the service array of its storage description resource with type equal to NotificationService . The service object MUST include a serviceEndpoint property whose value is the URI of the subscription endpoint. The service object MUST include a subscriptionType property whose value is an array of strings, each identifying a supported subscription type. Additional properties MAY be present on the service object. Example 10 : Storage description with notification service { "@context" : [ "https://www.w3.org/ns/lws/v1" ] , "id" : "https://storage.example/" , "type" : "Storage" , "service" : [ { "type" : "NotificationService" , "serviceEndpoint" : "https://notification.example/subscriptions" , "subscriptionType" : [ "WebhookSubscription" ] } ] } Note A server is not required to support all subscription types. The subscriptionType array advertises exactly which types are available. 10.2 Notification Data Model A notification is represented as a JSON-LD document with a Notification type. The envelope carries metadata about the delivery context and wraps an Activity Streams 2.0 [ ACTIVITYSTREAMS-CORE ] [ ACTIVITYSTREAMS-VOCABULARY ] activity describing the event. 10.2.1 Envelope Properties A notification envelope has the following properties: type — REQUIRED . The value MUST be the string Notification . storage — REQUIRED . A URI identifying the LWS storage with which the notification is associated. activity — REQUIRED . A JSON object or an array of JSON objects, each conforming to the Activity Streams 2.0 data model, describing the event or events that occurred. See 10.2.2 Activity Properties . Example 11 : Notification envelope { "@context" : [ "https://www.w3.org/ns/lws/v1" , "https://www.w3.org/ns/activitystreams" ] , "type" : "Notification" , "storage" : "https://storage.example/" , "activity" : { "id" : "ec4dcc48-6581-4232-81c9-584525a98693" , "type" : [ "Delete" ] , "object" : { "id" : "https://storage.example/alice/notes/shopping.txt" , "type" : [ "DataResource" ] } , "origin" : "https://storage.example/alice/notes/" , "published" : "2026-03-26T10:30:00Z" } } 10.2.2 Activity Properties Each activity object within the activity property MUST conform to the Activity Streams 2.0 data model and MUST include the following properties: id — REQUIRED . A string uniquely identifying the activity. type — REQUIRED . An array of strings containing at least one Activity Streams 2.0 activity type. object — REQUIRED . A JSON object identifying the resource that the notification is about. The object MUST include the following properties: id — REQUIRED . The URI of the resource. type — REQUIRED . An array of strings containing at least one resource type. Values defined by this specification include Container and DataResource . Additional type values MAY be included. published — REQUIRED . A datetime value conforming to [ RFC3339 ] indicating when the activity occurred. The following properties are OPTIONAL : actor — a URI identifying the agent that performed the action. target — a URI identifying the container into which the resource was added. Used with Create activities. origin — a URI identifying the container from which the resource was removed. Used with Delete activities. 10.2.3 Activity Types A server MUST support the following Activity Streams 2.0 activity types to indicate LWS resource changes: Create — a new resource was created in a container. The target field indicates the container to which the resource was added. Update — an existing resource's content or metadata was modified. Delete — a resource was removed. The origin field indicates the container from which the resource was removed. Other activity types MAY also be supported. 10.2.4 Batching Notifications A server MAY combine multiple activities into a single notification envelope by providing an array of activity objects as the value of the activity property. Example 12 : Batched notification { "@context" : [ "https://www.w3.org/ns/lws/v1" , "https://www.w3.org/ns/activitystreams" ] , "type" : "Notification" , "storage" : "https://storage.example/" , "activity" : [ { "id" : "a1b2c3d4-5678-9abc-def0-1234567890ab" , "type" : [ "Create" ] , "object" : { "id" : "https://storage.example/alice/notes/meeting.txt" , "type" : [ "DataResource" ] } , "target" : "https://storage.example/alice/notes/" , "published" : "2026-03-26T10:30:00Z" } , { "id" : "b2c3d4e5-6789-abcd-ef01-234567890abc" , "type" : [ "Update" ] , "object" : { "id" : "https://storage.example/alice/profile" , "type" : [ "DataResource" ] } , "published" : "2026-03-26T10:30:01Z" } ] } 10.3 Subscriptions To receive notifications, a subscriber creates a subscription by sending an authenticated POST request to the serviceEndpoint of the NotificationService . The request body MUST conform to the application/lws+json media type. 10.3.1 Subscription Request A subscription request MUST contain the following fields: type — REQUIRED . A string identifying the subscription type. The value MUST be one of the types listed in the subscriptionType array of the NotificationService . topic — REQUIRED . An array of URIs identifying the resources included in the subscription. A subscription request MAY contain additional fields as required by the specific subscription type. Example 13 : Subscription request POST /subscriptions HTTP/2 Host : notification.example Authorization : Bearer <access-token> Content-Type : application/lws+json { "@context" : [ "https://www.w3.org/ns/lws/v1" ] , "type" : "WebhookSubscription" , "topic" : [ "https://storage.example/alice/notes/" , "https://storage.example/alice/profile" ] , "inbox" : "https://receiver.example/hooks/lws" } 10.3.2 Subscription Scope A subscription to a container is recursive: the subscriber receives notifications for the container itself and for all resources transitively contained in that container. A subscription to a data resource applies only to that individual resource. 10.3.3 Subscription Authorization A server MUST enforce resource authorization when creating a subscription . If a subscriber does not have the equivalent of read access to all resources listed in the topic array, the server MUST reject the subscription request. Authorization MUST also be enforced at notification delivery time. A server MUST NOT deliver a notification about a resource that the subscriber is not authorized to read at the time the event occurs. This applies to all resources within the scope of a subscription , including resources in subcontainers. If the subscriber 's access to a resource or container within the scope of a subscription is revoked after the subscription is created, the server MUST stop delivering notifications for the affected resources. The server SHOULD NOT terminate the entire subscription unless the subscriber has lost access to all resources in the topic array. Note Subscription-time authorization verifies that a subscriber has a legitimate basis for receiving notifications. Delivery-time authorization ensures that notifications remain consistent with the subscriber 's current permissions, accounting for authorization changes that may occur after the subscription was created. 10.3.4 Subscription Response The response to a successful subscription creation request MUST conform to the application/lws+json media type and MUST contain the following fields: type — REQUIRED . A string equal to the subscription type from the request. subscription — REQUIRED . A URL representing the subscription. 10.3.5 Subscription Type Identifiers Each notification suite MUST be associated with a subscription type string. The subscription type string is used in the subscriptionType array of a NotificationService and in the type field of a subscription request. 11. Access Requests and Grants Access Requests and Grants provide a mechanism for an agent to request access to resources and for a storage controller to grant access with defined constraints. The endpoints for requesting and granting access act as a type of specialized inbox. An agent does not present an access grant to a server as an authorization token. Rather, the access grant serves as a record of what was authorized, to whom, and under what constraints. When an access grant is created or revoked (deleted), it is the responsibility of the server to adjust any underlying access policy to account for the change. The interaction between an access grant endpoint and a particular policy enforcement layer is out of scope for this specification. The access profile defined in this section is based on concepts from the Open Digital Rights Language (ODRL), including actions, constraints, and assignees. Other profiles could use a different conceptual framework. 11.1 Discovery A storage MAY advertise support for access requests and access grants in its storage description resource . When such support is advertised, a service object describing an endpoint for access requests MUST have a type equal to the string AccessRequestService , and a service object describing an endpoint for access grants MUST have a type equal to the string AccessGrantService . A service object SHOULD include a conformsTo property whose value is a collection of one or more URIs identifying the access profiles supported at that endpoint. Additional properties MAY be included: Example 14 : Storage Description with access request and grant services { "@context" : [ "https://www.w3.org/ns/cid/v1" , "https://www.w3.org/ns/lws/v1" ] , "id" : "https://storage.example/" , "type" : "Storage" , "service" : [ { "type" : "StorageRoot" , "serviceEndpoint" : "https://storage.example/root/" } , { "type" : "AccessRequestService" , "serviceEndpoint" : "https://access.example/request/" , "conformsTo" : [ "https://www.w3.org/ns/lws#AccessProfile" ] } , { "type" : "AccessGrantService" , "serviceEndpoint" : "https://access.example/grant/" , "conformsTo" : [ "https://www.w3.org/ns/lws#AccessProfile" ] } ] } 11.2 Data Model An access request or access grant is a data object that expresses properties for identity and routing, as well as an access object that describes the requested or permitted operations. A profile that describes access requests using ODRL concepts is described in 11.3 Access Profile . The following example illustrates an access request . The example is shown using the JSON-LD serialization defined in 11.4.1 JSON-LD Serialization . Example 15 : Access Request { "@context" : [ "https://www.w3.org/ns/lws/v1" ] , "type" : [ "AccessRequest" ] , "inbox" : "https://id.example/agent/inbox/" , "storage" : "https://storage.example/" , "access" : [ { "type" : [ "AccessPolicy" ] , "action" : [ "read" , "create" ] , "assignee" : "https://id.example/agent" , "target" : { "type" : "StorageResource" , "value" : [ "https://storage.example/root/projects/" ] } , "constraint" : [ { "leftOperand" : "purpose" , "operator" : "eq" , "rightOperand" : "https://purpose.example/collaboration" } , { "leftOperand" : "dateTime" , "operator" : "lteq" , "rightOperand" : "2026-06-09T10:00:00Z" } ] } ] } The following example illustrates an access grant . The example is shown using the JSON-LD serialization defined in 11.4.1 JSON-LD Serialization . Example 16 : Access Grant { "@context" : [ "https://www.w3.org/ns/lws/v1" ] , "type" : [ "AccessGrant" ] , "storage" : "https://storage.example/" , "access" : [ { "type" : [ "AccessPolicy" ] , "action" : [ "read" ] , "assignee" : "https://id.example/agent" , "target" : { "type" : "StorageResource" , "value" : [ "https://storage.example/root/projects/" ] } , "constraint" : [ { "leftOperand" : "purpose" , "operator" : "eq" , "rightOperand" : "https://purpose.example/collaboration" } , { "leftOperand" : "dateTime" , "operator" : "lteq" , "rightOperand" : "2026-06-09T10:00:00Z" } ] } ] } Other properties MAY be present on access requests and access grants . 11.2.1 Types The type property expresses the type of the document. The value of the type property MUST be one or more terms and absolute URL strings . For an access request , the value MUST include the term AccessRequest . For an access grant , the value MUST include the term AccessGrant . Additional type values MAY be included. This property is REQUIRED . This document defines the following type values for access requests and access grants : AccessRequest — a request by an agent for access to resources. AccessGrant — an authorization by a storage controller granting access to resources. Example 17 : type property { "type" : [ "AccessGrant" ] } 11.2.2 Storage The storage property identifies the LWS storage to which the access request or access grant is scoped. The value of the storage property MUST be a URI. This property is REQUIRED . Example 18 : storage property { "storage" : "https://storage.example/" } 11.2.3 Inbox The inbox property specifies a URI for receiving notifications related to the access request or access grant (see 11.6 Notifications ). The value of the inbox property MUST be a URI. This property is OPTIONAL . Example 19 : inbox property { "inbox" : "https://id.example/agent/inbox/" } 11.2.4 Access The access property describes the characteristics of one or more access profiles , based on the profiles supported by a server. A profile based on the ODRL Information Model is described in 11.3 Access Profile . The value of the access property MUST be a collection of one or more objects. This property is REQUIRED . 11.3 Access Profile This specification defines an Access Profile based on the ODRL Information Model and ODRL Vocabulary , identified with the URL: https://www.w3.org/ns/lws#AccessProfile . 11.3.1 Types The type property expresses the type of access policy. The value of the type property MUST be one or more terms and absolute URL strings , and MUST include the term AccessPolicy . Additional type values MAY be included. The property is REQUIRED . Example 20 : Access policy type { "access" : [ { "type" : [ "AccessPolicy" ] } ] } 11.3.2 Actions The action property describes the operations that the agent wishes to perform (in the case of a request) or is authorized to perform (in the case of a grant). The value of the action property MUST be a collection of one or more strings. Each value MUST correspond to an operation recognized by the server. The following values MUST be supported: read , modify , create , and delete . The read , modify , and delete values are defined by the ODRL Vocabulary . The create value is defined by this specification. These action values correspond to LWS operations as follows: read — retrieve a resource or its metadata (HTTP GET, HEAD) modify — modify an existing resource (HTTP PUT, PATCH) create — create a new resource within a container (HTTP POST) delete — remove an existing resource (HTTP DELETE) This property is REQUIRED . Example 21 : action property { "access" : [ { "action" : [ "read" , "create" ] } ] } 11.3.3 Assignee The assignee property identifies the party that is requesting access (in the case of a request) or that is being granted access (in the case of a grant). The value of the assignee property MUST be a URI. Public access MAY be assigned using the Agent class from the FOAF vocabulary , identified by the URI http://xmlns.com/foaf/0.1/Agent . This property is REQUIRED . Example 22 : assignee property { "access" : [ { "assignee" : "https://id.example/agent" } ] } 11.3.4 Targets The target property identifies the resources to which the access request or access grant applies. The target property MUST be an object containing the following properties: type — a term or absolute URL string identifying the type of target matcher. value — a collection of one or more strings used to identify the target resources. This specification defines the following type values for use with target objects: https://www.w3.org/ns/lws#DataResource — matches resources of type lws:DataResource . https://www.w3.org/ns/lws#Container — matches resources of type lws:Container . https://www.w3.org/ns/lws#StorageResource — matches any resource managed by a storage . A server MAY support additional type values. This property is OPTIONAL . Example 23 : target property with Resource type { "access" : [ { "target" : { "type" : "StorageResource" , "value" : [ "https://storage.example/root/2025" , "https://storage.example/root/2026" ] } } ] } 11.3.5 Constraints The constraint property defines conditions that limit or qualify the access being requested or granted. This property uses the ODRL Constraint model. The value of the constraint property, if present, MUST be a collection of constraint objects. Each constraint object MUST include the following properties: leftOperand — a string identifying the operand being constrained. operator — a string identifying the comparison operator. rightOperand — the value to compare against. The type depends on the leftOperand . When multiple constraint objects are present, all of them MUST be satisfied. A server advertising support for this profile MUST support the following leftOperand values: client — representing the client identifier for an HTTP request format — representing the media type of the target HTTP resource type — representing the type URL expressed in a resource's link headers purpose — representing the intended use of the access being requested or granted dateTime — representing the current date time This property is OPTIONAL . The following examples illustrate the use of these constraints: 11.3.5.1 Purpose Constraints The following example uses a leftOperand value of purpose to describe the intended use of the access being requested or granted. When the eq operator is used, the rightOperand value is a URI identifying a purpose. When the isAnyOf operator is used, the rightOperand value is an array of purpose URIs, and the constraint is satisfied if the stated purpose matches any of the listed values: Example 24 : Purpose constraint { "access" : [ { "constraint" : [ { "leftOperand" : "purpose" , "operator" : "isAnyOf" , "rightOperand" : [ "https://purpose.example/collaboration" , "https://purpose.example/research" ] } ] } ] } 11.3.5.2 Client Constraints The following example uses a leftOperand value of client to restrict access to a specific client application. When the eq operator is used, the rightOperand value is a URI identifying the client: Example 25 : Client constraint { "access" : [ { "constraint" : [ { "leftOperand" : "client" , "operator" : "eq" , "rightOperand" : "https://app.example/client-id" } ] } ] } 11.3.5.3 Format Constraints The following example uses a leftOperand value of format to restrict access to resources with specific media types. When the eq operator is used, the rightOperand value is a string identifying an IANA media type . When the isAnyOf operator is used, the rightOperand value is an array of media type strings, and access is permitted if the resource's media type matches any of the listed values: Example 26 : Format constraint { "access" : [ { "constraint" : [ { "leftOperand" : "format" , "operator" : "isAnyOf" , "rightOperand" : [ "image/jpeg" , "image/png" ] } ] } ] } 11.3.5.4 Resource Type Constraints All LWS resources will include link headers indicating type values: Example 27 : Link headers with type values Link : <https://www.w3.org/ns/lws#DataResource>; rel="type" Link : <https://type.example/Playlist>; rel="type" The following example uses a leftOperand value of type to restrict access based on the resource types advertised in HTTP Link headers. When the eq operator is used, the rightOperand value is a URI identifying a resource type. When the isAnyOf operator is used, the rightOperand value is an array of type URIs, and access is permitted if the resource's type matches any of the listed values: Example 28 : Resource type constraint { "access" : [ { "constraint" : [ { "leftOperand" : "type" , "operator" : "isAnyOf" , "rightOperand" : [ "https://type.example/Playlist" , "https://type.example/Song" ] } ] } ] } 11.3.5.5 Temporal Constraints The following example uses a leftOperand value of dateTime to limit access to a specific time window. The gteq operator defines the start of the window and the lteq operator defines the end. The rightOperand value for temporal constraints is an XML Schema dateTime string: Example 29 : Temporal constraint { "access" : [ { "constraint" : [ { "leftOperand" : "dateTime" , "operator" : "gteq" , "rightOperand" : "2026-03-09T12:00:00Z" } , { "leftOperand" : "dateTime" , "operator" : "lteq" , "rightOperand" : "2026-06-09T10:00:00Z" } ] } ] } 11.3.5.6 Combining Constraints When multiple constraint objects are present, all of them MUST be satisfied for access to be permitted. The following example restricts access to a specific client application before a specific date: Example 30 : Combined constraints { "access" : [ { "action" : [ "read" ] , "assignee" : "https://id.example/agent" , "target" : { "type" : "StorageResource" , "value" : [ "https://storage.example/root/projects/" ] } , "constraint" : [ { "leftOperand" : "dateTime" , "operator" : "lteq" , "rightOperand" : "2026-06-09T10:00:00Z" } , { "leftOperand" : "client" , "operator" : "eq" , "rightOperand" : "https://app.example/client-id" } ] } ] } 11.4 Serialization The data model defined in this section is independent of any particular serialization. 11.4.1 JSON-LD Serialization This specification defines a JSON-LD serialization for access requests and access grants . Documents using this serialization MUST include an @context property whose value is an ordered set that includes https://www.w3.org/ns/lws/v1 . Additional context entries MAY be included to define extension terms. The media type associated with this serialization is application/lws+json . Example 31 : JSON-LD @context { "@context" : [ "https://www.w3.org/ns/lws/v1" ] } 11.5 Protocol The access request and access grant endpoints are LWS containers and MUST conform to the rules defined in this specification. These endpoints minimally require support for GET and POST operations. The DELETE operation is RECOMMENDED . Other operations MAY be supported. These endpoints MUST support the JSON-LD serialization defined in 11.4.1 JSON-LD Serialization for both request and response payloads. Servers MAY support additional serializations. An agent creates an access request by submitting a POST request to the access request endpoint. A storage controller creates an access grant by submitting a POST request to the access grant endpoint. A successful POST operation MUST respond with a Location header set to the URL of the new resource. 11.5.1 Access Request Endpoint POST / — Create an access request. GET / — Retrieve a list of access requests. GET /:id — Retrieve a specific access request. DELETE /:id — Cancel an access request. 11.5.2 Access Grant Endpoint POST / — Create an access grant. GET / — Retrieve a list of access grants. GET /:id — Retrieve a specific access grant. DELETE /:id — Revoke an access grant. 11.6 Notifications Issue 103 : LWS Notifications Feature work-item This section needs to align with the yet-to-be-defined notification section of LWS. Notifications provide a mechanism for informing agents and storage controllers about changes to access requests and access grants . When an inbox property is present on an access request or access grant , the server SHOULD deliver notifications to that endpoint, informing an assignee of the event. The serialization of notifications MUST conform to the requirements of the LWS notification data model. Notifications delivered to an inbox endpoint MUST conform to the requirements defined in the LWS protocol for notification delivery. Note The notification mechanism described in this section is comparable to the Linked Data Notifications pattern, in which notifications are discovered via an inbox property and delivered by sending a POST request to that inbox. 11.6.1 Notification Events A server SHOULD send notifications in response to the following events: Access Request creation : When a new access request is submitted, the storage controller SHOULD be notified. Access Grant creation : When a new access grant is created, the requesting agent SHOULD be notified at the inbox specified in the associated access request . A server MAY send notifications in response to other events. 12. LWS Media Type 12.1 LWS Media Type An LWS storage description MUST be serializable with the media type application/lws+cid . The application/lws+cid media type identifies a document that is a specialization of a W3C Controlled Identifier document [ CID-1.0 ], extended with the LWS vocabulary. An LWS container representation MUST support the media type application/lws+json . While LWS container representations use JSON-LD conventions, the constraints and requirements for LWS justify the use of a specific media type. Because LWS containers can be considered a restricted profile of JSON-LD, implementations SHOULD consider the application/ld+json; profile="https://www.w3.org/ns/lws/v1" media type as equivalent to application/lws+json . 12.1.1 Media Type Equivalence For container representations , the media types application/lws+json , application/ld+json , and application/json are equivalent: the response body is the same JSON-LD document conforming to the container representation structure defined in 8.1 Container Representation , and only the Content-Type response header varies. Servers MUST honor a request for any of these media types and MUST set the Content-Type response header to the requested media type. Because the Content-Type of a container response depends on the request's Accept header, these responses SHOULD include a Vary: Accept header [ RFC9110 ]. Note (non-normative): This equivalence applies only to the three media types above. As with any HTTP resource, a server can offer additional representations of a container (for example, text/turtle ) through standard content negotiation [ RFC9110 ]; this specification neither requires nor precludes such support. 12.1.2 Pagination Certain composite resources, like containers , may hold a large number of resources. To allow clients to retrieve listings incrementally, servers SHOULD support pagination for containers whose membership exceeds a server-determined threshold. 12.1.2.1 Pagination Model Pagination is link-based: the server provides pagination URIs via HTTP Link headers [ RFC8288 ], allowing clients to navigate the full listing without relying on numeric offsets. When a listing is paginated, the response body contains only the current page of items. The composite resource's id , type , and totalItems properties reflect the full membership, while items contains only the resources on the current page. 12.1.2.2 Pagination Link Relations Pagination URIs are conveyed in Link headers using the following standard link relations: rel="first" : The URI of the first page of results. MUST be present on paginated responses. rel="last" : The URI of the last page of results. MAY be present on paginated responses. rel="next" : The URI of the next page of results. MUST be present when there are subsequent pages. MUST be omitted on the last page. rel="prev" : The URI of the previous page of results. MAY be present when there are preceding pages. MUST be omitted on the first page. All pagination URIs are opaque to the client. Clients SHOULD NOT construct or modify pagination URIs; they SHOULD use the URIs provided by the server. 12.1.2.3 Requesting Pages A client requests the composite resource's URI to obtain the first page. The response includes pagination Link headers that the client follows to retrieve subsequent pages. Servers MAY also support direct access to specific pages via the pagination URIs obtained during a previous scan. When a paginated response is returned, the server MUST respond with 200 OK. The totalItems property in the response body SHOULD reflect the total number of items across all pages, not just the current page. 12.1.2.4 Example: Paginated Container Request: GET /alice/photos/ HTTP/1.1 Authorization : Bearer <token> Accept : application/lws+json Response (first page): HTTP/1.1 200 OK Content-Type : application/lws+json ETag : "photos-page1-etag" Link : </alice/photos/.meta>; rel="linkset"; type="application/linkset+json" Link : </alice/>; rel="up" Link : <https://www.w3.org/ns/lws#Container>; rel="type" Link : </alice/photos/?page=1>; rel="first" Link : </alice/photos/?page=3>; rel="last" Link : </alice/photos/?page=2>; rel="next" { "@context" : "https://www.w3.org/ns/lws/v1" , "id" : "/alice/photos/" , "type" : "Container" , "totalItems" : 150 , "items" : [ { "type" : "DataResource" , "id" : "/alice/photos/vacation.jpg" , "format" : "image/jpeg" , "size" : 248392 , "modified" : "2025-11-20T10:30:00Z" } , { "type" : "DataResource" , "id" : "/alice/photos/portrait.png" , "format" : "image/png" , "size" : 102400 , "modified" : "2025-11-21T14:15:00Z" } ] } Request (next page): GET /alice/photos/?page=2 HTTP/1.1 Authorization : Bearer <token> Accept : application/lws+json Response (middle page): HTTP/1.1 200 OK Content-Type : application/lws+json ETag : "photos-page2-etag" Link : </alice/photos/.meta>; rel="linkset"; type="application/linkset+json" Link : </alice/>; rel="up" Link : <https://www.w3.org/ns/lws#Container>; rel="type" Link : </alice/photos/?page=1>; rel="first" Link : </alice/photos/?page=1>; rel="prev" Link : </alice/photos/?page=3>; rel="next" Link : </alice/photos/?page=3>; rel="last" { "@context" : "https://www.w3.org/ns/lws/v1" , "id" : "/alice/photos/" , "type" : "Container" , "totalItems" : 150 , "items" : [ { "type" : "DataResource" , "id" : "/alice/photos/sunset.jpg" , "format" : "image/jpeg" , "size" : 315000 , "modified" : "2025-11-22T09:00:00Z" } ] } 13. JSON-LD Context The LWS JSON-LD context is identified by the URL https://www.w3.org/ns/lws/v1 . The SHA2-256 digest of the document resolved from that URL is included in the table below: Context URL and Hash URL: https://www.w3.org/ns/lws/v1 SHA2-256 Digest: TODO: include the JSON-LD context digest once the context document is finalized The digest can be verified with a command such as: curl -sL -H "Accept: application/ld+json" https://www.w3.org/ns/lws/v1 | openssl dgst -sha256 Note Production systems are advised not to fetch remote JSON-LD context documents at runtime. Bundling or caching contexts locally eliminates a runtime dependency on external infrastructure, reduces latency, and prevents context manipulation attacks. 14. 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 this left intentionally blank 15. 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 this left intentionally blank 16. Security Considerations This section is non-normative. Formal security considerations section covering threat models, security requirements, and implementation guidance for secure LWS deployments. The recommendations described in Best Current Practice for OAuth 2.0 Security [ RFC9700 ] apply to this specification. 16.1 Transport Security This section is non-normative. Transport Layer Security (TLS) is an important mechanism to prevent against tampering, spoofing, and information disclosure. TLS-protected communication can be verified according to [ RFC6125 ]. Implementation security considerations can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [ RFC9325 ]. 16.2 Token Security This section is non-normative. Bearer tokens and digital credentials are vulnerable to theft and replay. Mitigations include using a reasonably short lifetime, binding tokens to a particular audience, and storing tokens securely. Short Lifetimes: Authorization servers that assign lifetimes of 300 seconds (5 minutes) or less to access tokens can limit the potential exposure of an exfiltrated credential. Audience Binding: Access tokens that are bound to a specific destination server, by means such as the aud claim, can rely on that binding to protect against token replay. Applications that handle credentials with an unrestricted audience need to be careful when sending these credentials to other entities, especially untrusted authorization servers. If a credential issuer is unable to restrict the audience of a token, clients can use a mechanism such as OAuth 2.0 Token Exchange [ RFC8693 ] to create audience-constrained credentials before interacting with an authorization server in a different security domain. Secure Storage: Applications that persist credentials need to ensure that these objects are stored safely. Any time an unencrypted token is stored in a browser's localStorage , in URLs, or in logs, that token is more susceptible to an exfiltration attack. 16.3 Access Requests and Grants This section is non-normative. Servers are strongly encouraged to apply authorization rules to both the access request and access grant endpoints. Write access to the access grant endpoint, in particular, should be restricted to authorized storage controllers and specific clients. When an agent creates an access request , the server is encouraged to verify that the assignee value in the request is associated with the authenticated identity of the requesting agent. Because the access request endpoint accepts content from external agents, servers are encouraged to implement measures to prevent abuse, such as rate limiting, payload size restrictions, or requiring authentication before accepting submissions. Without such protections, the endpoint may be vulnerable to spam, resource exhaustion, or other forms of unwanted content. 16.4 Notifications This section is non-normative. Information Disclosure : Notifications may reveal the existence or modification patterns of resources. Access control on subscriptions and on individual notification delivery MUST be consistent with access control on the underlying resources. Subscription Abuse : Rate limiting and endpoint verification are suggested to prevent abuse of the subscription mechanism. 17. Privacy Considerations This section is non-normative. Privacy implications of the LWS Protocol, including data minimization, user consent, and privacy-preserving implementation patterns. Credentials carry information about users and agents . While digital signatures can protect against tampering, it is possible for clients or third parties to read the values inside an unencrypted credential. As a result, credential issuers are encouraged to create tokens that contain only the information necessary for authentication or authorization, and to avoid including sensitive attributes unless required. In general, it is an anti-pattern to write unencrypted credential data to a log. In cases where this is necessary, implementations can truncate or hash a credential to preserve the privacy of the credential subject. When using pseudonymous identifiers in JWTs, a storage server may still be able to correlate requests from the same agent over time. To preserve user privacy in this case, a client application can request a batch issuance of JWTs where each JWT is used only one time. 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 will need to be careful not to issue the same identifier more than once. 17.1 Access Requests and Grants This section is non-normative. An access request or access grant can reveal sensitive information about the resources, agents, and purposes involved. Servers are encouraged to limit the visibility of these resources to authorized parties, such as the storage controller and the assignee identified in the document. For example, a storage controller might have the ability to read and delete all resources, while other agents would only have access to the resources for which they are the assignee. When an access grant includes a client constraint, it is advisable for a server to filter that grant from responses to requests made by other clients. For example, if an agent is granted access to a resource only when using a specific client, that grant would not be visible when the agent uses a different client. 17.2 Notifications This section is non-normative. Activity Tracking : Notifications inherently reveal when resources change. Subscribers SHOULD only receive notifications for resources they are authorized to access. Actor Disclosure : Including the actor property in notifications reveals who made changes. This may be inappropriate in some contexts. The actor property SHOULD be omitted by default. Servers MAY make its inclusion configurable. Timing Analysis : The timing of notifications can reveal usage patterns even when content is not disclosed. 18. IANA Considerations This section is non-normative. 18.1 well-known URI Registry This specification adds the following value to the "Well-Known URIs" registry established by RFC 5785 [ RFC5785 ]. URI suffix: lws-configuration Change controller: W3C Specification document: Section 5 of LWS-Auth Related information: (none) 18.2 OAuth Authorization Server Metadata Registry This specification adds the following value to the "OAuth Authorization Server Metadata" registry established by [ RFC8414 ]. Metadata Name: subject_token_types_supported Metadata Description: JSON array containing a list of the OAuth 2.0 "subject_token_type" values that this authorization server supports Change Controller: W3C Specification Document(s): Section 5 of LWS-Auth 18.3 The application/lws+json Media Type This specification registers the application/lws+json media type specifically for identifying documents conforming to the Linked Web Storage container format. Type name: application Subtype name: lws+json Required parameters: None Encoding considerations: Resources that use the application/lws+json media type are required to conform to all of the requirements for the application/json media type and are therefore subject to the same encoding considerations specified in Section 11 of [ RFC8259 ]. Security considerations: As defined in this specification. Contact: W3C Linked Web Storage Working Group <[email protected]> Note that while the Linked Web Storage format uses JSON-LD conventions, there are a number of constraints and additional requirements for LWS implementations that justify the use of a specific media type. Because LWS containers can be considered a restricted profile of JSON-LD, implementations SHOULD consider the application/ld+json; profile="https://www.w3.org/ns/lws/v1" media type as equivalent to application/lws+json . 18.4 The application/lws+cid Media Type This specification registers the application/lws+cid media type for identifying storage description documents conforming to the Linked Web Storage protocol as a specialization of the W3C Controlled Identifiers 1.0 document format. Type name: application Subtype name: lws+cid Required parameters: None Encoding considerations: Resources that use the application/lws+cid media type are required to conform to all of the requirements for the application/json media type and are therefore subject to the same encoding considerations specified in Section 11 of [ RFC8259 ]. Security considerations: As defined in this specification Contact: W3C Linked Web Storage Working Group <[email protected]> A. Acknowledgements This section is non-normative. This specification draws heavily from the Solid Protocol [ Solid-Protocol ], which was edited, over time, by Sarven Capadisli, Tim Berners-Lee, Kjetil Kjernsmo, Ruben Verborgh, Justin Bingham, Dmitri Zagidulin. B. References B.1 Normative references [ACTIVITYSTREAMS-CORE] Activity Streams 2.0 . James Snell; Evan Prodromou. W3C. 23 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/activitystreams-core/ [ACTIVITYSTREAMS-VOCABULARY] Activity Vocabulary . James Snell; Evan Prodromou. W3C. 23 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/activitystreams-vocabulary/ [CID-1.0] Controlled Identifiers v1.0 . Michael Jones; Manu Sporny. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/cid-1.0/ [FOAF] FOAF Vocabulary Specification 0.99 (Paddington Edition) . Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec/ [JSON-LD11] JSON-LD 1.1 . Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/ [ODRL-MODEL] ODRL Information Model 2.2 . Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/ [ODRL-VOCAB] ODRL Vocabulary & Expression 2.2 . Renato Iannella; Michael Steidl; Stuart Myles; Víctor Rodríguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/ [OPENID-CONNECT-CORE] OpenID Connect Core 1.0 incorporating errata set 2 . N. Sakimura; J. Bradley; M. Jones; B. de Medeiros; C. Mortimore. OpenID Foundation. 15 December 2023. Final. URL: https://openid.net/specs/openid-connect-core-1_0.html [RFC2119] Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/ [RFC3339] Date and Time on the Internet: Timestamps . G. Klyne; C. Newman. IETF. July 2002. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc3339/ [RFC3986] Uniform Resource Identifier (URI): Generic Syntax . T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/info/rfc3986/ [RFC4918] HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) . L. Dusseault, Ed. IETF. June 2007. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc4918/ [RFC5789] PATCH Method for HTTP . L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html [RFC6585] Additional HTTP Status Codes . M. Nottingham; R. Fielding. IETF. April 2012. Proposed Standard. URL: https://httpwg.org/specs/rfc6585.html [RFC6749] The OAuth 2.0 Authorization Framework . D. Hardt, Ed. IETF. October 2012. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc6749/ [RFC6750] The OAuth 2.0 Authorization Framework: Bearer Token Usage . M. Jones; D. Hardt. IETF. October 2012. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc6750/ [RFC7231] Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content . R. Fielding, Ed.; J. Reschke, Ed. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html [RFC7232] Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests . R. Fielding, Ed.; J. Reschke, Ed. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html [RFC7233] Hypertext Transfer Protocol (HTTP/1.1): Range Requests . R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html [RFC7240] Prefer Header for HTTP . J. Snell. IETF. June 2014. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7240/ [RFC7386] JSON Merge Patch . P. Hoffman; J. Snell. IETF. October 2014. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7386/ [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/ [RFC8288] Web Linking . M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html [RFC8414] OAuth 2.0 Authorization Server Metadata . M. Jones; N. Sakimura; J. Bradley. IETF. June 2018. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc8414/ [RFC8693] OAuth 2.0 Token Exchange . M. Jones; A. Nadalin; B. Campbell, Ed.; J. Bradley; C. Mortimore. IETF. January 2020. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc8693/ [RFC9068] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens . V. Bertocci. IETF. October 2021. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc9068/ [RFC9110] HTTP Semantics . R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html [rfc9112] HTTP/1.1 . R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9112.html [RFC9264] Linkset: Media Types and a Link Relation Type for Link Sets . E. Wilde; H. Van de Sompel. IETF. July 2022. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc9264/ [RFC9457] Problem Details for HTTP APIs . M. Nottingham; E. Wilde; S. Dalal. IETF. July 2023. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc9457/ [URL] URL Standard . Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/ [WebArch] Architecture of the World Wide Web, Volume One . Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/ [XMLSCHEMA11-2] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes . David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/ B.2 Informative references [LDN] Linked Data Notifications . Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/ [RFC5785] Defining Well-Known Uniform Resource Identifiers (URIs) . M. Nottingham; E. Hammer-Lahav. IETF. April 2010. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc5785/ [RFC6125] Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) . P. Saint-Andre; J. Hodges. IETF. March 2011. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc6125/ [RFC8259] The JavaScript Object Notation (JSON) Data Interchange Format . T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/info/rfc8259/ [RFC9325] Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) . Y. Sheffer; P. Saint-Andre; T. Fossati. IETF. November 2022. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc9325/ [RFC9700] Best Current Practice for OAuth 2.0 Security . T. Lodderstedt; J. Bradley; A. Labunets; D. Fett. IETF. January 2025. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc9700/ [Solid-Protocol] Solid Protocol . Sarven Capadisli; Tim Berners-Lee; Kjetil Kjernsmo. Solid Community Group. 12 May 2024. Draft Community Group Report. URL: https://solidproject.org/TR/protocol ↑ Permalink Referenced in: § 2.2 Security and Privacy (2) § 3. Terminology (2) (3) § 9.2 Create resource § 9.4 Update resource Permalink Referenced in: § 2.2 Security and Privacy § 3. Terminology Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2.2 Security and Privacy Permalink Referenced in: § 3. Terminology Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 11. Access Requests and Grants (2) (3) (4) § 11.1 Discovery (2) § 11.2 Data Model (2) (3) § 11.2.1 Types (2) § 11.2.2 Storage § 11.2.3 Inbox § 11.3.4 Targets § 11.4.1 JSON-LD Serialization § 11.5 Protocol (2) (3) § 11.6 Notifications (2) § 11.6.1 Notification Events § 16.3 Access Requests and Grants (2) § 17.1 Access Requests and Grants (2) Permalink Referenced in: § 11. Access Requests and Grants § 11.1 Discovery § 11.2.4 Access Permalink Referenced in: § 11.1 Discovery (2) § 11.2 Data Model (2) (3) (4) § 11.2.1 Types (2) § 11.2.2 Storage § 11.2.3 Inbox § 11.3.4 Targets § 11.4.1 JSON-LD Serialization § 11.5 Protocol (2) (3) § 11.6 Notifications (2) § 11.6.1 Notification Events (2) § 16.3 Access Requests and Grants (2) (3) § 17.1 Access Requests and Grants Permalink Referenced in: § 2.1 Resource Access § 2.2 Security and Privacy (2) (3) § 3. Terminology (2) (3) (4) (5) § 4. Authentication § 5. Authorization § 5.2.3.2 Response § 9. Operations § 11. Access Requests and Grants (2) § 11.2.1 Types § 11.3.2 Actions § 11.5 Protocol § 11.6 Notifications § 11.6.1 Notification Events § 17. Privacy Considerations (2) Permalink Referenced in: § 3. Terminology § 4. Authentication § 4.1 Authentication Credential Data Model (2) (3) § 4.2 Authentication Credential Validation (2) § 5.2.3 Token Exchange § 5.2.3.1 Request Permalink Referenced in: § 4.2 Authentication Credential Validation § 4.3 Authentication Credential Type Identifiers (2) Permalink Referenced in: § 3. Terminology (2) Permalink Referenced in: § 3. Terminology Permalink Referenced in: § 3. Terminology (2) (3) (4) (5) (6) (7) (8) (9) (10) § 9.1 Metadata Permalink Referenced in: § 3. Terminology (2) (3) § 7.1 Container Model (2) (3) (4) § 7.2 Containment (2) § 7.3 Containment Integrity (2) (3) (4) (5) (6) § 7.4 Resource Identification § 7.5 Container Membership and Authorization (2) (3) (4) § 8.1 Container Representation (2) § 8.1.1 Container Properties (2) (3) (4) § 8.1.2 Contained Resource Description § 8.1.3 Example Container Representation § 9. Operations § 9.1 Metadata (2) (3) (4) § 9.2 Create resource (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) § 9.3 Read resource (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § 9.5 Delete resource (2) (3) (4) (5) (6) (7) (8) (9) (10) § 12.1.2 Pagination (2) Permalink Referenced in: § 7.1 Container Model § 9.1 Metadata (2) § 9.2 Create resource (2) (3) § 9.3 Read resource Permalink Referenced in: § 3. Terminology (2) § 7.2 Containment § 7.3 Containment Integrity (2) § 7.4 Resource Identification (2) § 9.1 Metadata § 9.5 Delete resource (2) Permalink Referenced in: § 3. Terminology § 9.1 Metadata (2) (3) (4) (5) § 9.2 Create resource (2) § 9.4 Update resource (2) (3) (4) (5) (6) (7) (8) § 9.5 Delete resource Permalink Referenced in: § 3. Terminology § 9.2 Create resource Permalink Referenced in: § 3. Terminology (2) (3) (4) (5) § 5.2.3.1 Request § 6.1 Storage Description Resource § 6.1.1 Data Model § 6.1.2 Discovery and Binding (2) (3) § 6.1.3 Storage Capabilities § 6.1.4 Storage Services § 7.1 Container Model (2) (3) § 9.1 Metadata § 11.3.4 Targets Permalink Referenced in: § 3. Terminology § 11. Access Requests and Grants § 11.2.1 Types § 11.5 Protocol § 11.6 Notifications § 11.6.1 Notification Events Permalink Referenced in: § 3. Terminology (2) § 6.1 Storage Description Resource § 6.1.1 Data Model § 6.1.2 Discovery and Binding § 6.1.3 Storage Capabilities § 6.1.4 Storage Services § 6.1.5 Storage Description Representation § 10.1 Notification Discovery § 11.1 Discovery § 12.1 LWS Media Type Permalink Referenced in: § 6.1.4 Storage Services § 7.1 Container Model (2) § 7.3 Containment Integrity Permalink Referenced in: § 10.2 Notification Data Model § 10.3.3 Subscription Authorization § 10.3.5 Subscription Type Identifiers Permalink Referenced in: § 3. Terminology § 10.1 Notification Discovery § 10.3 Subscriptions § 10.3.2 Subscription Scope (2) § 10.3.3 Subscription Authorization (2) (3) (4) (5) (6) Permalink Referenced in: § 3. Terminology § 10.3 Subscriptions § 10.3.2 Subscription Scope § 10.3.3 Subscription Authorization (2) (3) (4) (5) (6) § 17.2 Notifications Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2.2 Security and Privacy § 3. Terminology (2) § 11.3.2 Actions Permalink Referenced in: § 3. Terminology Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § Tactics § 9.4 Update resource Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 3. Terminology § 9.6 Summary of HTTP Status Mappings Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 3. Terminology § 9.6 Summary of HTTP Status Mappings Permalink Referenced in: § 9.6 Summary of HTTP Status Mappings Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 7.1 Container Model § 7.5 Container Membership and Authorization § 9.3 Read resource § 12.1 LWS Media Type § 12.1.1 Media Type Equivalence (2)

Related documents

• latn gap#649807
• grek gap#649808
• mong gap#649809
• nkoo gap#649810
• osge osa gap#649811