Linked Web Storageプロトコル 1.0

LWSプロトコルは、ある主体が何らかのリソースを何らかのエージェントに利用可能にできる標準的なやり取りを定義する。

• 提供リソース - (利用可能なリソース？公開済み リソース？) (UCSでは 定義されていない) 本書で定義されるプロトコルを使用して、対話、取得、または操作のためにサービスによって公開される、ネットワークからアクセス可能なエンティティ。
• 要求元エージェント - (エンティティ in UCS) 要求を開始するエンティティ （例えば、クライアント、ユーザー、またはプロセス）であり、提供可能なリソースと対話するための要求を開始するもの。

リソース管理者は、提供リソースを 非公開に保つことも、誰にでも公開することも、その可視性を制約された一群の 要求エージェントに限定することもできる。

• 認証 - 要求を実行するエージェント の身元を確認するプロセス。
• 認可 - エージェント が特定のリソースへのアクセス、または一連の操作のいずれかを実行する権限を有するかどうかを判断するプロセス。
• リソース マネージャー - (コントローラー における UCS) あるエージェントであり、提供リソースへのアクセスを制御する権限を有する。

非規範的と明示された節に加え、この仕様におけるすべての作成ガイドライン、図、例、および注記は 非規範的である。この仕様のそれ以外のすべては規範的である。

この文書におけるキーワードMAY、MUST、MUST NOT、OPTIONAL、RECOMMENDED、REQUIRED、SHOULD、およびSHOULD NOTは、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されるとおりに解釈される。

LWSサーバーは、この仕様における関連するすべての「MUST」 文に適合するHTTPサーバー[rfc9112]である。具体的には、 この文書の9. 操作における関連する規範的な「MUST」文を尊重MUSTする。

LWS クライアント は、 HTTP クライアント [rfc9112] であり、本仕様書における関連するすべての「MUST」記述に準拠するものです。具体的には、本書の9. 操作における関連する規範的な「MUST」記述を 遵守しなければなりません。

次の図は、実装の指針となる プラットフォーム非依存のモデルである。

このセクションで説明するデータモデルは、認証資格情報の任意の 具体的なシリアライゼーションに対する要件を概説します。

認証資格情報には、対象に関する改ざんを検知可能なクレームを MUST 含めなければなりません。これには以下が含まれます:

• 対象 REQUIRED — エンドユーザーの識別子。これはMUST URIでなければなりません。
• 発行者 REQUIRED — 認証資格情報を発行したエンティティの識別子。これはMUST URIでなければなりません。
• クライアント REQUIRED — クライアントアプリケーションの識別子。これは SHOULD URIであるべきです。
• オーディエンス 制限 RECOMMENDED — 値のリストであり、 SHOULD 認可サーバーの識別子を含むべきです。

認証資格情報の検証には、検証者と資格情報の発行者との間の信頼 関係が必要である。この信頼関係は、アウトオブバンドのメカニズムを通じて確立されてもMAYよい。 検証者と発行者との間の信頼を確立するための追加メカニズムは、特定の認証スイートで概説される。

認証資格情報は署名されなければMUSTならない。署名には非対称暗号を用いることがRECOMMENDEDされる。

各認証スイートは、トークン型URIに関連付けられなければMUSTならない。 認証スイートは、IANA「OAuth URI」レジストリで定義されたURIを使用すべきSHOULDである。

LWS認可における役割は、OAuth 2.0の1.1節[RFC6749]で定義されているものと同じである： リソース所有者、 リソースサーバー、 クライアント（曖昧さを避けるため、この仕様では認可クライアントと 呼ぶ）、および 認可サーバー。 ストレージサーバーは、LWSストレージ仕様にも適合するリソースサーバーの一種である。

この仕様は、クライアントと認可サーバーとの間のやり取り、および クライアントと適合ストレージサーバーとの間のやり取りを記述する。

認可サーバーとストレージサーバーとの間のやり取りは、この仕様の範囲外である。 認可サーバーはストレージサーバーと同じサーバーであってもよく、別個の実体であってもよい。

HTTP/2 401 Unauthorized
Link: <https://storage.example/storage_1>; rel="https://www.w3.org/ns/lws#storage"
WWW-Authenticate: Bearer resource_metadata="https://storage.example/.well-known/oauth-protected-resource/storage_1/photos/img.jpg",
                error="invalid_token"

{
    "resource": "https://storage.example/storage_1/photos/img.jpg",
    "authorization_servers": ["https://authorization.example"]
}

{
    "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"],
    "subject_identifier_types_supported": [
        "did:web",
        "did:key",
        "https"]
}

POST /token HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fstorage.example%2Fstorage_1
&subject_token=eyJ0eXAiOiJhcytqd3QiLCJhbGciO...fiK51VwhsxJ-siBMR-YFiA
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token":"eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso",
    "token_type":"Bearer",
    "expires_in":300
}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error":"invalid_request"
}

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

Authorization: Bearer eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso

ストレージ記述リソースは、 クライアントが利用できる情報を提供する。 これは、ストレージとやり取りする際の情報であり、機能および サービスエンドポイントの記述を含む。

{
  "@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/"
  }]
}

{
  "@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/json-patch+json", "application/merge-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"
  }]
}

Linked Web Storageは、リソースをコンテナーに整理する。コンテナーは、 メンバーと呼ばれる他のリソースへの参照を保持する特殊なリソースである。コンテナーは、 ディレクトリーやコレクションに類似した整理単位として機能し、クライアントによるリソースのグループ化、検出、 およびナビゲーションを可能にする。コンテナーは、メンバーリソースへの参照を維持する。 これらには、コンテナーではないリソースと追加のコンテナーリソースの両方を含めることができ、それによって 階層構造を形成できる。通常、コンテナーが保持する固有のコンテンツは、 メタデータやメンバーの列挙以外には最小限であり、その主な役割は集約および構造化である： 下位リソースの。ストレージシステムのルートは、コンテナーとして指定され、 上位の親を持たない最上位の整理単位として機能する。コンテナー表現の構造は、8.1 コンテナー 表現で定義され、そのメディア型およびページネーションの要件は、12. LWSメディア型で定義される。 ストレージは、ルートコンテナーとして機能し、直接書き込みを可能にしてもよい。

すべてのLWSストレージには、ストレージ ルートがあり、最上位の整理単位として機能する。ストレージルートは親を持たず、次のものへのエントリーポイントとして機能する： ストレージ 階層。

LWSのリソースは、次のいずれかに分類される：

• コンテナー — 他のリソースを含む リソース。
• データリソース — データを保持するリソース （例：文書、画像、または構造化データファイル）。

リソースとその親コンテナとの間の包含関係は、rel="up"リンク 関係によって表現される。サーバーは、任意の 非ルートリソースに対するGETおよびHEAD要求への応答において、親コンテナを指す rel="up"を持つLinkヘッダーを含めなければMUSTならない。

Link: </alice/notes/>; rel="up"

コンテナのメンバーは、その表現内で itemsプロパティを用いて一覧化される。サーバーがこの一覧を管理するため、クライアントは直接変更できない。 メンバーシップの変更は、リソースの作成および削除の副作用として発生する。

サーバーは、常に包含の完全性を維持しなければMUSTならない:

• 作成: 新しいリソースがコンテナ内に作成される場合、 サーバーは、そのリソースをコンテナの items一覧に原子的に追加しなければMUSTならない。
• 削除: リソースが削除される場合、サーバーは それを親コンテナのitems一覧から 原子的に削除しなければMUSTならない。 コンテナを削除するには、再帰的削除が明示的に要求されない限り、 コンテナが空である必要がある。
• 孤立なし: すべての非ルートリソースは、ストレージルートから包含 階層を通じて到達可能でなければMUSTならない。
• 循環なし: コンテナは、自身を直接または 間接的に含んではMUST NOTならない。

リソースはURIによって識別されます。リソースのURIは、包含階層内の位置から独立しています。サーバーはリソースの 作成時にURIを割り当て、クライアントヒントを組み込んでもよいものとしますが、クライアントはURI構造が包含を反映していると仮定すべきではありません。

包含関係は、URIパス構造ではなく、メタデータ （rel="up"リンクおよびコンテナ 表現内のitemsプロパティ）を通じて表現される。この分離により、明確に定義された編成モデルを維持しながら、 サーバーはURI割り当てに柔軟性を持てる。

クライアントがコンテナへの読み取りアクセス権を持つ場合、 コンテナ 表現は、そのコンテナに含まれるリソースのうち、 クライアントがアクセス権を持つすべてのリソースの識別子を含まなければMUSTならない。また、そのコンテナに含まれるリソースのうち、クライアントがアクセス権を持たないリソースの識別子を 含んでもMAYよい。

クライアントがコンテナ一覧を読み取れることは、含まれる リソース自体へのアクセス権を意味せず、その逆も同様である。

LWS のコンテナー表現はコンテナーとその内容を記述する。この節では、その表現が application/lws+jsonとして提供される場合の必須プロパティと任意のプロパティを定義する。他の RDF メディア タイプの表現は、コンテンツネゴシエーションを通じて要求できる。

{
  "@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"
    }
  ]
}

@prefix lws: <https://www.w3.org/ns/lws#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<> a lws:Container ;
  lws:totalItems 2 ;
  lws:items <shoppinglist.txt>, <todo.json> .

<shoppinglist.txt> a lws:DataResource ;
  dcterms:format "text/plain" ;
  schema:size "47"^^xsd:long ;
  dcterms:modified "2025-11-24T12:00:00Z"^^xsd:dateTime .

<todo.json> a lws:DataResource, <http://example.org/customType> ;
  dcterms:format "application/json" ;
  schema:size "2048"^^xsd:long ;
  dcterms:modified "2025-11-24T13:00:00Z"^^xsd:dateTime .

<https://storage.example/alice/notes/> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/lws#Container> .
<https://storage.example/alice/notes/> <https://www.w3.org/ns/lws#totalItems> "2"^^<http://www.w3.org/2001/XMLSchema#integer> .
<https://storage.example/alice/notes/> <https://www.w3.org/ns/lws#items> <https://storage.example/alice/notes/shoppinglist.txt> .
<https://storage.example/alice/notes/> <https://www.w3.org/ns/lws#items> <https://storage.example/alice/notes/todo.json> .
<https://storage.example/alice/notes/shoppinglist.txt> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/lws#DataResource> .
<https://storage.example/alice/notes/shoppinglist.txt> <http://purl.org/dc/terms/format> "text/plain" .
<https://storage.example/alice/notes/shoppinglist.txt> <http://schema.org/size> "47"^^<http://www.w3.org/2001/XMLSchema#long> .
<https://storage.example/alice/notes/shoppinglist.txt> <http://purl.org/dc/terms/modified> "2025-11-24T12:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
<https://storage.example/alice/notes/todo.json> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/lws#DataResource> .
<https://storage.example/alice/notes/todo.json> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/customType> .
<https://storage.example/alice/notes/todo.json> <http://purl.org/dc/terms/format> "application/json" .
<https://storage.example/alice/notes/todo.json> <http://schema.org/size> "2048"^^<http://www.w3.org/2001/XMLSchema#long> .
<https://storage.example/alice/notes/todo.json> <http://purl.org/dc/terms/modified> "2025-11-24T13:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

This section defines the model for associating metadata with Storage Resources。LWS metadata system は、型付き link を使用してサーバーが resource 間の関係を記述できる Web Linking [RFC8288] の原則に基づいている。 Metadata は発見可能性を向上させ、自己記述型 API をサポートし、resource 操作および container 階層と整合する。

Metadata Model LWS におけるすべての metadata は、resource（link context）を起点とする型付き link の集合として表現される。 各 link は以下で構成される。

• link target: 関連する resource を識別する URI。
• relation type: 関係の性質を定義する文字列。
• Optional target attributes: link または target resource をさらに記述する追加の key-value ペア。

Metadata は resource とその representation を区別し、該当する場合には複数の media type を許可する。 data resources の場合、metadata には representation が含まれ、 それぞれに format および省略可能な sizeInBytes がある。 containers および data resources については、 親 container resource への link を、 resource の metadata の一部であるとみなす。

Linkset Resource storage 内の各 resource について、サーバーは [RFC9264] に従い、metadata link をスタンドアロン resource として利用可能にしなければならない。

• Discovery: resource の linkset は、関係 rel="linkset" を持つ Link header によって発見可能である。
• Media Type: linkset resource は application/linkset+json として利用可能でなければならない。
• Integrity: 'linkset' link はサーバー管理の resource を指さなければならない。 linkset の更新は、一貫性を維持するため、関連する resource 操作とアトミックでなければならない。

メタデータの検出 クライアントは、主にGETまたはHEAD要求への応答に含まれるLinkヘッダーを通じてメタデータを検出します。

• ストレージ：サーバーは、関連する応答に必ず rel="https://www.w3.org/ns/lws#storage"を持つLinkヘッダーを含めなければなりません。
• 包含：サーバーは、ルート以外のすべてのリソースについて、親コンテナーを指す rel="up"を持つLinkヘッダーを必ず含めなければなりません。
• プリファレンス：クライアントは、特定の関係を含めるか省略するために、URI https://www.w3.org/ns/lws#PreferLinkRelationsとともにPreferヘッダー [RFC7240]を使用してもよいものとします。

メタデータの種類

変更可能性に関する考慮事項 コアメタデータは、クライアントによって変更してもよいものとします。相互運用性を確保するため、サーバーは、 必ず標準HTTPヘッダーを使用して、その能力を通知しなければなりません。

1. メソッドの検出：サーバーは、Allowヘッダーを介して、リンクセットリソースに対するGETおよびPATCH 操作のサポートを必ず通知しなければなりません。

2. パッチ形式の検出：サーバーは Accept-Patch ヘッダーを介して JSON Patch [RFC6902] のサポートを 必須 として通知しなければならない： Accept-Patch: application/json-patch+json。

3. 任意のメソッド：サーバーは、任意でPUTまたは代替のパッチ形式をサポートできます。 サポートする場合、それらは必ずそれぞれAllowヘッダーおよびAccept-Patch ヘッダーに含まれなければなりません。

[!IMPORTANT] クライアントは、リソースヘッダーで通知されていない限り、PUTまたは特定のパッチ形式のサポートを仮定すべきではなく、 405 Method Not Allowedまたは415 Unsupported Media Type応答を必ず適切に処理しなければなりません。

メタデータの管理 メタデータは、リソースに関連付けられたリンクセットリソースの URI を操作することで管理されます。サーバーは、GET および HEAD リクエストへの応答に、[RFC9110] で定義されている ETag ヘッダーを必ず含めなければなりません。

• 部分更新（PATCH）：これは、メタデータ管理の主要なメカニズムです。サーバーは、必ずapplication/json-patch+jsonを使用するPATCHをサポートしなければなりません。

• 置換（PUT）：Allowヘッダーで通知されている場合、クライアントはリンクセット全体を置換してもよい ものとします。サーバーがPUTをサポートしない場合、必ず 405 Method Not Allowedで要求を拒否しなければなりません。

• 制限：サーバーは、システムの整合性を維持するため、upや itemsなどの特定のリンクに対する変更を制限してもよいものとします。

• ライフサイクル：メタデータのライフサイクルは、記述対象のリソースに結び付けられます。リソースを削除すると、必ず、関連付けられたリンクセットリソースのメタデータが自動的に削除されなければなりません。

リソースの作成操作は、新しい提供リソースを既存のコンテナーに追加する。この 操作は、データリソースとサブコンテナーの両方の作成を扱う。

入力:

• 対象コンテナー: 新しいリソースが作成されるコンテナーの 識別子。
• 識別子のヒント: 新しいリソースの識別子に関する任意の提案。サーバーは このヒントを使用してもよいが、使用する義務はない。
• 内容: 新しいリソースの初期内容とタイプ。

動作:

• 識別子の生成: サーバーは新しい リソースの最終的な識別子（URI）を決定する。識別子のヒントが提供された場合、サーバーは コンテナー内での一意性と有効性を確保しながら、 そのヒントを取り入れようとする。ヒントが提供されない場合、 サーバーは一意の識別子を生成する。
• コンテナーのメンバーシップの更新: サーバーは新しいリソースを対象 コンテナーのメンバー一覧にアトミックに追加する。
• メタデータの初期化: サーバーは新しい リソースのシステムメタデータを初期化する。リソースに関連付けられたメタデータリソースがある場合、それも 初期化される。

考えられる応答:

• 作成済み: 操作が成功した。サーバーは新しく作成された リソースの最終的な識別子を返す。
• 対象が見つからない: 指定された対象コンテナーが 存在しない。
• 許可されていない: クライアントの識別情報は既知だが、この コンテナー内にリソースを作成する権限がない。
• 不明な要求者: サーバーがクライアントの識別情報を認識できず、 認証を必要とする。
• 競合: 生成された識別子を持つリソースがすでに存在するか、 別の状態の競合がある。
• 不明なエラー: 予期しない内部エラーが発生した。

新しいリソースは、対象のコンテナー URI に POST を使用して作成され、サーバーが 最終的な識別子を割り当てる。クライアントは任意で新しい リソースのユーザー管理の初期メタデータを、POST 要求に 1 つ以上のLinkヘッダーを含め、 [RFC8288] の Web リンクの構文に従って提供してもよい。サーバー管理のメタデータは必ず 作成時にサーバーによって自動生成されなければならず、決して クライアントが提供したリンクによって上書きされてはならない。

成功時、サーバーは必ず新しい URI を Locationヘッダーに含めて 201 ステータスコードを返さなければならない。サーバーは必ずLinkヘッダーに 主要なサーバー管理のメタデータを含めなければならない。これには、親コンテナーへのリンク （rel="up"）と、作成されたリソース専用のリンクセットリソースへのリンク （rel="linkset"; type="application/linkset+json"）が含まれる。追加のリンクには原則としてrel="type"を含めるべきである（ https://www.w3.org/ns/lws#Containerまたは https://www.w3.org/ns/lws#DataResourceを示す）。本文は任意で空にするか、 リソースの最小限の表現を含めてもよい。すべてのメタデータの作成とリンク付けは必ず整合性を維持するためにリソースの作成とアトミックに行わなければならない。

POST（コンテナー URI への要求） – サーバーが割り当てる名前で作成: POST を使用して、既存のコンテナー内に新しいリソースを追加する。サーバーが リソースの識別子を割り当てる。クライアントは、作成するリソースのタイプを次のように示す。

• コンテナーを作成するには、クライアントは必ずrel="type"を持つLinkヘッダーを含め、 Container タイプを指すようにしなければならない。 Link: <https://www.w3.org/ns/lws#Container>; rel="type"。
• データリソースを作成するには、クライアントは 適切なContent-Typeヘッダーとともに要求本文にリソースの内容を含める。

例（POST による新しいデータリソースの作成）:

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

この例では、クライアントはコンテナー/alice/notes/に POST する。 text/plainの内容（買い物リスト）を提供する。/alice/notes/が存在し、 クライアントが認可されている場合、サーバーは新しいデータリソースを作成し、それをコンテナーのメンバー一覧に追加する。

例（POST への応答 — データリソース）:

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

成功時には、新しい URI をLocationヘッダーに含めて 201 Created を返す。本文は 空でも、最小限の表現でもよい。 対象のコンテナー/alice/notes/が存在しない場合、サーバーは 必ず別のステータスコードの方が適切でない限り、404 エラーステータスを返さなければならない。

コンテナーの作成: 新しいコンテナーを作成するには、クライアントは既存の親コンテナーに対して、Container タイプを示すLinkヘッダーを 付けて POST を使用する。例:

POST /alice/ HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Content-Length: 0
Link: <https://www.w3.org/ns/lws#Container>; rel="type"

例（POST への応答 — コンテナー）:

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

これにより、/alice/notes/に新しいコンテナーが作成され、サーバーによって生成された rel="type"がhttps://www.w3.org/ns/lws#Containerであるメタデータも含まれる。

作成に関する追加の注記（HTTP バインディング）:

• POST は冪等ではない。繰り返すと重複が発生する可能性があるため、クライアントは原則として 意図しない再試行を避けるか、一意の識別子や検査を使用して重複を防ぐべきである。
• メタデータの更新はアトミックである。サーバーは必ずリンクセットリソースが作成され、必須の サーバー管理フィールドが設定されていることを、成功を返す前に保証しなければならない。
• 発見可能性のため、サーバーは原則としてLinkヘッダーに rel="https://www.w3.org/ns/lws#storage"を含めて 401 応答で返し、 URI をハードコードしていないクライアントを案内すべきである。

メタデータの管理と取得（作成に関連）: メタデータは主に読み取り操作によって取得されるが、作成時に生成される。クライアントは 作成直後に新しいリソース URI に GET または HEAD を使用して取得できる。クライアントは Preferヘッダーを使用して、特定のメタデータリンク（関係タイプによる）と 属性を含めるよう要求できる。

既存のリソースの表現、またはコンテナーの一覧を取得する。

• 入力: 対象の識別子と任意のパラメーター。
• 動作:
  • コンテナー以外のリソースについては、サーバーはリソースの内容を返す。
  • コンテナーについては、サーバーはメンバー リソースの一覧を返す。この一覧は認可に基づいて任意でフィルタリングしてもよい。一覧には 各メンバーの基本メタデータを含めなければならない。
• 結果: 要求された表現、または失敗の通知。

リソースの読み取り操作は、HTTP GET 要求（ヘッダーのみの要求には HEAD）を使用してリソースの表現を要求する。 動作は、対象 URL がコンテナーであるか、コンテナー以外のリソース（データリソース）であるかによって異なる。サーバーは必ず メタデータを通じてリソースのタイプを区別しなければならない。すべての応答は必ず 8.1 節で定義されるメタデータと統合しなければならず、これには rel="linkset"、rel="up"、rel="type"などの主要な関係を示すLinkヘッダーが含まれる。サーバーは必ず読み取り時にリソースの状態とそのメタデータの間の原子性を保証しなければならない。

GET（コンテナー以外のリソース） – リソースの内容を取得する: リソースの URI に GET を送信して、内容全体を取得する（認可されている場合）。200 OK で応答し、本文に データを含め、Content-Type を保存されているメディアタイプに一致させる。サーバーは必ず 部分取得のために [RFC7233] に従った範囲要求をサポートしなければならない。 応答には必ず [RFC9110] で定義されるETagヘッダーを含めなければならない。

例（ファイルの GET）:

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

これは/alice/notes/shoppinglist.txtの内容を要求し、クライアントが テキスト形式で取得したいことを示す。リソースが存在し、テキストであり、クライアントにアクセス権があると仮定すると、次のようになる。

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

サーバーはテキストの内容を返した（Content-Lengthが示すとおり、合計 34 バイト）。 内容はファイルに保存されているデータと完全に同一である。ETag: "abc123456"は、 キャッシュおよび条件付き要求のための検証子である。応答には メタデータの発見可能性のためのLinkヘッダーが含まれ、upやtypeなどの必須フィールドを持つ。

GET（コンテナーリソース） – コンテナーの内容を一覧表示する: 対象 URI がコンテナーに対応する場合（メタデータのタイプによって判定される）、GET 要求は コンテナーのメンバーの一覧を返す。 Content-Type: application/lws+jsonを持つ応答は、 コンテナー 表現であり、コンテナー 表現の節で定義される。この表現では、一覧に各メンバーのメタデータが含まれる。 リソースの識別子（必須）、タイプ（必須）、メディアタイプ （DataResources では必須）、サイズ（推奨）、および 更新日時のタイムスタンプ（推奨）。

例（コンテナーの GET）: コンテナーが存在し、クライアントにアクセス権があると仮定する。 タブには、異なるメディアタイプでの同じ要求が示される。12.1.2 コンテンツネゴシエーションを参照。

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

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"
    }
  ]
}

GET /alice/notes/ HTTP/1.1
Authorization: Bearer <token>
Accept: text/turtle; profile="https://www.w3.org/ns/lws/v1"

HTTP/1.1 200 OK
Content-Type: text/turtle; profile="https://www.w3.org/ns/lws/v1"
ETag: "container-etag-789"
Link: </alice/notes/.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/>; rel="up"
Link: <https://www.w3.org/ns/lws#Container>; rel="type"

@prefix lws: <https://www.w3.org/ns/lws#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<> a lws:Container ;
  lws:totalItems 2 ;
  lws:items <shoppinglist.txt>, <todo.json> .

<shoppinglist.txt> a lws:DataResource ;
  dcterms:format "text/plain" ;
  schema:size "47"^^xsd:long ;
  dcterms:modified "2025-11-24T12:00:00Z"^^xsd:dateTime .

<todo.json> a lws:DataResource, <http://example.org/customType> ;
  dcterms:format "application/json" ;
  schema:size "2048"^^xsd:long ;
  dcterms:modified "2025-11-24T13:00:00Z"^^xsd:dateTime .

この例では、/alice/notes/はコンテナーである。応答は LWS コンテキストを使用した JSON-LD で、必須のメタデータとともにメンバーを一覧表示する。各項目にはtype、 id、format、size、modifiedのタイムスタンプがフラットな プロパティとして含まれる。

いずれの場合も、サーバーは必ず応答ヘッダーに次のメタデータを含めなければならない。 [RFC9110] で定義されるETagヘッダーと、 rel="linkset"、rel="up"、rel="type"を持ち、それが コンテナーであることを示すLinkヘッダー。

HEAD（任意のリソースまたはコンテナー） – ヘッダーとメタデータのみ: LWS サーバーは必ずコンテナーと非コンテナーの両方について HEAD [RFC9110] をサポートし、 コンテナーと非コンテナーに対して、GET と同じヘッダーを返さなければならない。 （Content-Typeやメタデータ用のLinkを含む）が、本文は含めない。これにより、 内容を転送せずにメタデータを取得できる。

キャッシュと条件付き要求: LWS は HTTP のキャッシュセマンティクスを活用する。サーバーは原則として[RFC9110] で定義される条件付き要求をサポートすべきであり、 エンティティタグ（ETags）や日付ベースの検証子（ If-Modified-Sinceヘッダーなど）の仕組みを含む。リソースまたはコンテナーの一覧が 変更されていない場合は、不要な転送を避けるために304 Not Modifiedで応答する。

発見可能性と認可: 発見可能性を高めるため、 401 Unauthorized応答には、 resource_metadataパラメーターを持つWWW-Authenticateヘッダーが含まれる。これは認可サーバーの発見で説明されており、クライアントが URI をハードコードせずに認可サーバーを特定できるようにする。

既存の[提供されるリソース]の状態を、完全な置換または部分的なパッチによって変更します。

• 入力: 対象識別子、新しい内容、およびオプションの同時実行制約。
• 動作: サーバーは変更を原子的に適用します。同時実行制約が 指定されている場合、要求者が最後に読み取って以降にリソースが変更されていれば、 更新は拒否されます。
• 結果: 更新の確認または競合の通知。

リソースの更新は、PUT リクエスト（リソース全体を置換する場合）または PATCH リクエスト（ 部分的な変更を適用する場合）によって、既存の提供される リソースの内容を変更します。これらの 操作を実行するには、クライアントがリソースの URL への書き込みアクセス権を持っていなければなりません。 注: この節では、リソースの主要な内容の更新について説明します。メタデータを更新するには、9.3.2節を参照してください。 LWS サーバーは、リソース URI に対する PUT および PATCH リクエストを、 関連付けられたリンクセットリソースに既定では影響を与えない、リソース内容のみの変更として扱わなければなりません。単一の原子的な操作で内容と メタデータの両方を任意に更新するために、クライアントはリソース URI への PUT/PATCH リクエストに Link ヘッダーを含め、優先指定 'Prefer: set-linkset'（[RFC7240] で定義）を指定してもかまいません。この場合、 サーバーは、内容の変更を適用することに加えて、指定された Link ヘッダーをリンクセットの置換 （PUT の場合）または部分更新（PATCH の場合）として解釈しなければなりません。 この動作はサーバーにとって任意ですが、サポートする場合、意図しないメタデータの上書きを防ぐため、 Prefer ヘッダーを介して明示的に呼び出されなければなりません。複合更新をサポートしないサーバーは、その優先指定を無視しなければならないか、501 Not Implemented で応答しなければなりません。

PUT（リソース全体の置換） – 新しい完全な内容を 本文に入れ、一致する Content-Type（通常は既存の型と一致）とともにリソース URI に PUT を送信します。PUT は既存のリソースに対してべき等です。 クライアントは、同時変更の上書きを避けるため、 [RFC9110] で定義されている条件付きリクエストを使用するべきです。

例（PUT によるリソースの更新）:

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"
}

この例では、クライアントは /alice/personalinfo.json にある既存の JSON リソースを更新しています。以前の GET または HEAD リクエストから受信したエンティティタグ （ETag）を含む If-Match ヘッダーを指定しています。サーバーはそれを 現在のエンティティタグ（ETag）と比較し、一致する場合は、指定された JSON で内容を置換します。一致しない場合、サーバーは更新を拒否します（その間にリソースが 他者によって変更されたためです）。 成功応答: 更新に成功した場合、サーバーは 200 OK で応答し、 更新された表現または何らかの確認（新しい内容やその一部など）を含めることができます。 あるいは、本文なしで成功したことを示すために 204 No Content で応答することもできます （特に、追加情報を伝える必要がない場合によく使用されます）。例:

HTTP/1.1 204 No Content

• エラー応答: If-Match の前提条件が一致しなかった 場合（同時変更）、サーバーは 412 Precondition Failed で応答します。 リソースが存在しない場合、更新を目的とした PUT は 404 Not Found になります。 クライアントが認可されていない場合は 403 Forbidden（有効な 資格情報が提供されていない場合は 401 Unauthorized）です。リクエストペイロードが有効でない場合は 400 Bad Request です。

PATCH（部分更新） – HTTP PATCH メソッド [RFC5789] を使用すると、クライアントは新しい コンテンツ全体を送信する代わりに、リソースに対する部分的な変更を指定できる。これは、変更されたのが ごく一部だけである場合にコンテンツ全体を送信すると非効率になる大きなリソースや、特定の変更を適用したい並行編集に有用である。LWS サーバーは、最低限 JSON Patch をサポートしなければならない （application/json-patch+json）。これは [RFC6902] で定義されている。

リソースメタデータの更新（リンクセットに対する HTTP PUT / PATCH） リソースのメタデータは、Link ヘッダーの rel="linkset" を介して検出される、対応するリンクセットリソースを 変更することで更新されます。 完全な置換（PUT）: 完全な リンクセット文書を本文に含む、リンクセットリソース URI への PUT リクエストは、リソースのすべてのメタデータを置換します。 部分更新（PATCH）: リンクセットリソース URI への PATCH リクエストは、特定のリンクを追加、削除、または 変更します。

メタデータの条件付きリクエスト リソースのメタデータは複数の主体によって変更される可能性があるため、同時上書きを防ぐことが 重要です。サーバーとクライアントは、リンクセットリソースに対する PUT および PATCH 操作について、 [RFC9110] で定義されている条件付きリクエストを使用するべきです。サーバーが前提条件を満たさない条件付き リクエストを受信した場合、412 Precondition Failed ステータスコードでそのリクエストを拒否しなければなりません。 例（リンクセットを置換する PUT）: クライアントはまずリンクセットを取得します。

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
{
  "linkset": [
    {
      "anchor": "/alice/personalinfo.json",
      "describedby": [ { "href": "/schemas/personal-info.json" } ]
    }
  ]
}

クライアントは次にライセンスを追加しようとします。新しい完全なリンクセット文書を構築し、PUT リクエストを送信します。

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

成功した場合、サーバーは成功を示す応答を返します。

HTTP/1.1 204 No Content

更新規則の概要 リソースの内容のみを変更する場合 → リソース自体に PUT/PATCH を行います。 リソースのリンク（メタデータ）のみを変更する場合 → リソースに関連付けられたリンクセットリソースに PUT/PATCH を行います。 内容とリンクの両方を変更する場合 → 適切な Link ヘッダーと 'Prefer: set-linkset' の両方を含めて、リソース自体に PUT/PATCH を行います。両方の設定は既定では無効です。

リソースおよびそれに関連付けられたメタデータを完全に削除します。

• 入力: 対象識別子、オプションの再帰フラグ（コンテナーの場合）、およびオプションの同時実行制約。
• 動作:
  • コンテナー以外のリソースの場合、サーバーは内容とメタデータを削除し、 親コンテナーのメンバーシップを更新します。
  • コンテナーの場合、再帰的削除が 明示的に要求され、かつサポートされていない限り、通常、サーバーはコンテナーが空であることを要求します。
• 結果: 削除の確認、または失敗の通知。

リソース削除操作は、上記の抽象操作で定義されているように、HTTP DELETE メソッドを使用して実装されます。 この節では、入力、動作、および応答の HTTP バインディングを規定します。

DELETE リクエストは、削除するリソースまたはコンテナーの URI を対象とします。クライアントは、同時実行 チェックのために ETag を指定した If-Match ヘッダーを含めてもかまいません。

削除と包含: リソースが削除されるとき、サーバーは、その 親コンテナーの items リストから、そのリソースを原子的に削除しなければなりません。親コンテナーの totalItems の数も、それに応じて更新することが推奨されます。

コンテナー以外のリソースの場合、サーバーはリソースの内容、関連付けられたメタデータ（リンクセットリソース）、および親コンテナー内の包含参照を 削除します。

コンテナーリソースの場合、サーバーは既定で非再帰的 削除を行います。コンテナーが空でなく、再帰処理が要求されていない場合、サーバーは 409 Conflict でリクエストを拒否しなければなりません。サーバーは、削除対象のコンテナー内に含まれる すべてのリソースの再帰的削除をサポートしてもかまいません。クライアントは、 [RFC4918] で定義されているように、再帰的削除を要求するために Depth: infinity ヘッダーを使用しなければなりません。

成功した場合、サーバーは 204 No Content で応答しなければなりません。サーバーは、 [RFC9110] で定義されている条件付きリクエストをサポートすることが推奨されます。

クライアントに認可がない場合、サーバーは 403 Forbidden（クライアントの 識別情報は既知だが権限が不十分な場合）または 401 Unauthorized（有効な 認証が提供されていない場合）を返さなければなりません。リソースの存在を明らかにすることがセキュリティリスクとなる場合、 サーバーは代わりに 404 Not Found を返してもかまいません。

例（コンテナー以外のリソースを DELETE）:

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

ETagが一致し、クライアントが認可されていると仮定すると、サーバーはリソース、そのメタデータを削除し、 親コンテナ/alice/notes/からそれを原子的に削除する:

HTTP/1.1 204 No Content

例（再帰なしで空でないコンテナをDELETEする）:

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

/alice/notes/がリソースを含むと仮定すると、サーバーは削除を拒否する:

HTTP/1.1 409 Conflict
Content-Type: text/plain

Cannot delete container /alice/notes/ - container is not empty.

例（サポートされる場合、再帰でコンテナをDELETEする）:

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

サーバーが再帰をサポートし、クライアントがすべての内容に対する権限を持つと仮定すると、サーバーは コンテナとその子孫を原子的に削除する:

HTTP/1.1 204 No Content

この表は、一般的な LWS の応答（ 8節）を、一貫性を保つために HTTP ステータスコードおよびペイロードに対応付け、ページネーション、 条件付きリクエスト、クォータ制約、メタデータ統合などの具体的なシナリオを組み込んだものです:

ストレージは通知に対応してもよい。通知に対応するストレージには、必須として、 サービスオブジェクトを自身のservice配列内で公開することが求められる。この配列は、ストレージ記述 リソース内にあり、オブジェクトのtypeはNotificationServiceと等しい。

サービスオブジェクトは、serviceEndpointプロパティを含むことが必須であり、その 値は、 サブスクリプションエンドポイントのURIである。サービスオブジェクトは、次を含むことが必須である： subscriptionTypeプロパティで、その値は文字列の配列であり、各文字列は、 対応するサブスクリプション型を識別する。

サービスオブジェクトに追加のプロパティが存在してもよい。

{
  "@context": ["https://www.w3.org/ns/lws/v1"],
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [{
    "type": "NotificationService",
    "serviceEndpoint": "https://notification.example/subscriptions",
    "subscriptionType": [
      "WebhookSubscription"
    ]
  }]
}

通知は、Notificationタイプを持つ JSON-LD文書として表現される。エンベロープは配信コンテキストに関するメタデータを保持し、 イベントを記述するActivity Streams 2.0 [ACTIVITYSTREAMS-CORE] [ACTIVITYSTREAMS-VOCABULARY] アクティビティを包含する。

{
  "@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"
  }
}

{
  "@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"
    }
  ]
}

通知を受信するため、サブスクライバーは、 NotificationServiceのserviceEndpointに 認証済みのPOST要求を送信することにより、サブスクリプションを 作成する。要求本体はapplication/lws+jsonメディアタイプに 適合しなければならない。

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"
}

ストレージは、アクセス要求および アクセス許可への対応を、 自身のストレージ記述リソースで通知してもよい。このような対応が 通知される場合、サービス オブジェクトで、アクセス要求用のエンドポイントを記述するものは、必須として、 typeが文字列AccessRequestServiceと等しくなければならず、 サービスオブジェクトで、アクセス許可用のエンドポイントを記述するものは、必須として、 次を持たなければならない： 文字列AccessGrantServiceと等しいtype。サービス オブジェクトは、conformsToプロパティを含むことが推奨される。その値は、 コレクションであり、 1つ以上のURIからなり、それらはアクセスプロファイルを識別する。その対応先は、 当該エンドポイントである。追加のプロパティを含めてもよい：

{
  "@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"]
    }
  ]
}

アクセス要求またはアクセス許可は、 アイデンティティおよびルーティングのためのプロパティと、要求または許可された操作を記述する accessオブジェクトを表現するデータオブジェクトである。ODRLの概念を使用して アクセス要求を記述するプロファイルについては、11.3 アクセスプロファイルで説明する。

次の例は、アクセス要求を示す。この例は、 11.4.1 JSON-LDシリアル化で定義されるJSON-LDシリアル化を使用して示されている。

{
  "@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"
      }
    ]
  }]
}

次の例は、アクセス許可を示す。この例は、 11.4.1 JSON-LDシリアル化で定義されるJSON-LDシリアル化を使用して示されている。

{
  "@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"
      }
    ]
  }]
}

アクセス要求および アクセス許可には、他のプロパティが存在してもよい。

{
  "type": ["AccessGrant"]
}

{
  "storage": "https://storage.example/"
}

{
  "inbox": "https://id.example/agent/inbox/"
}

この仕様は、 ODRL情報モデルおよびODRL 語彙に基づき、次のURLで識別される アクセスプロファイルを定義する： https://www.w3.org/ns/lws#AccessProfile。

{
  "access": [{
    "type": ["AccessPolicy"]
  }]
}

{
  "access": [{
    "action": ["read", "create"]
  }]
}

{
  "access": [{
    "assignee": "https://id.example/agent"
  }]
}

{
  "access": [{
    "target": {
      "type": "StorageResource",
      "value": [
        "https://storage.example/root/2025",
        "https://storage.example/root/2026"
      ]
    }
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "purpose",
        "operator": "isAnyOf",
        "rightOperand": [
          "https://purpose.example/collaboration",
          "https://purpose.example/research"
        ]
      }
    ]
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "client",
        "operator": "eq",
        "rightOperand": "https://app.example/client-id"
      }
    ]
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "format",
        "operator": "isAnyOf",
        "rightOperand": ["image/jpeg", "image/png"]
      }
    ]
  }]
}

Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Link: <https://type.example/Playlist>; rel="type"

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "type",
        "operator": "isAnyOf",
        "rightOperand": [
          "https://type.example/Playlist",
          "https://type.example/Song"
        ]
      }
    ]
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "dateTime",
        "operator": "gteq",
        "rightOperand": "2026-03-09T12:00:00Z"
      },
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      }
    ]
  }]
}

{
  "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"
      }
    ]
  }]
}

この節で定義するデータモデルは、特定の シリアル化に依存しない。

{
  "@context": [
    "https://www.w3.org/ns/lws/v1"
  ]
}

アクセス要求およびアクセス許可の エンドポイントはLWSコンテナーであり、この仕様で定義される規則に 適合しなければならない。

これらのエンドポイントでは、最低限GETおよびPOST操作のサポートが必要である。 DELETE操作が推奨される。その他の操作をサポートしてもよい。

これらのエンドポイントは、要求および応答ペイロードの両方について、 11.4.1 JSON-LD シリアル化で定義されるJSON-LDシリアル化をサポートしなければならない。 サーバーは、追加のシリアル化をサポートしてもよい。

エージェントは、 アクセス要求エンドポイントに POST要求を送信することにより、アクセス要求を作成する。 ストレージ コントローラーは、アクセス許可エンドポイントに POST要求を送信することにより、アクセス許可を作成する。

成功したPOST操作は、Locationヘッダーを 新しいリソースのURLに設定して応答しなければならない。

通知は、エージェントおよびストレージ コントローラーに、 アクセス要求およびアクセス許可の変更について 通知するためのメカニズムを提供する。アクセス要求またはアクセス許可に inboxプロパティが存在する場合、サーバーは、割当先にイベントを通知するため、 そのエンドポイントに通知を配信することが望ましい。

通知のシリアル化は、LWS通知データモデルの要件に 適合しなければならない。

inboxエンドポイントに配信される通知は、通知配信について LWSプロトコルで定義される要件に適合しなければならない。

LWS のストレージ記述は必ずメディアタイプapplication/lws+cidでシリアライズ可能でなければならない。 application/lws+cidメディアタイプは、 W3Cの制御識別子文書[CID-1.0]を LWS 語彙で拡張した特化文書を識別する。

LWS のコンテナー表現は必ずメディアタイプapplication/lws+jsonをサポートしなければならない。

LWS のコンテナー表現は JSON-LD の規約を使用するが、LWS に固有の制約と要件により、 専用のメディアタイプを使用することが正当化される。

GET /alice/photos/ HTTP/1.1
Authorization: Bearer <token>
Accept: application/lws+json

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"
    }
  ]
}

GET /alice/photos/?page=2 HTTP/1.1
Authorization: Bearer <token>
Accept: application/lws+json

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"
    }
  ]
}