Skip to content

Instantly share code, notes, and snippets.

@sizer

sizer/TR_websub_ja.md

Forked from tao-s/TR_websub.md
Last active June 27, 2023 01:38
Show Gist options
  • Save sizer/699256028e2d64cae5ccd0aae21fec1f to your computer and use it in GitHub Desktop.
Save sizer/699256028e2d64cae5ccd0aae21fec1f to your computer and use it in GitHub Desktop.
Download ZIP
W3CにあるWebSubのTRの日本語版
Raw
TR_websub_ja.md

WebSub

W3C Candidate Recommendation 11 April 2017

Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

概要

WebSubはあらゆる種類のWebコンテンツのパブリッシャとサブスクライバ間の通信にHTTP Webフックをベースとした共通のメカニズムを提供します。 購読sリクエストは、リクエストを検証するハブを介してリレーされます。 その後、ハブは利用可能になったときに新しいコンテンツと更新されたコンテンツをサブスクライバに配信します。 WebSubは以前はPubSubHubbubとして知られていました。

この文書のステータス

このセクションでは、このドキュメントの発行時点におけるステータスについて説明します。 他のドキュメントは、このドキュメントよりも優先されます。 現在のW3C technical reports indexの出版物のリストとこの技術レポートの最新の改訂版は、 W3C technical reports indexテクニカルレポートのインデックスは https://www.w3.org/TR/ でご覧いただけます。

This document was published by the Social Web Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them topublic-socialweb@w3.org (subscribe, archives). W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 11 May 2017. All comments are welcome.

Please see the Working Group's implementation report.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. 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 work in progress.

This document was produced by a group operating under the 5 February 2004 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 which 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 1 March 2017 W3C Process Document.

リスクのある機能（実装間に合わんかったやつ?）

これらの機能にはリスクがあります。; if interoperable implementations are not found, they may be removed to advance the other features in this specification to Proposed Recommendation:

  • Host-Metaの発見方法
  • <link>タグの制限は、HTML文書の<head>に制限されています

This document is currently a W3C TR track document. Current bugs and issues are managed in GitHub.

1. 定義

  • トピック
    • HTTP [RFC7230]リソースURL。 サブスクリプションできる一単位。
  • ハブ ("the hub")
    • このプロトコルの両側を実装するサーバー（URL [WHATWG-URL]）。すべてのハブは誰が使えるかについて独自のポリシーで実装してよい(MAY)。
  • パブリッシャ（出版者）
    • トピックの所有者。トピックフィードが更新された時、ハブへ通知する。ほぼ全てのPubSubシステムと同様、パプリッシャはサブスクライバがいたとしてもその存在を知らない。パブリッシャを「ソース」と呼ぶPubSubシステムもある。
  • サブスクライバ（購読者）
    • トピックの変更を通知したいエンティティ(個人またはプログラム)。サブスクライバはネットワークに直接アクセス可能でなければならず、そのサブスクライバコールバックURLによって識別されます。
  • サブスクリプション（購読状態）
    • トピックの更新を受け取るべきと表明したサブスクライバによる、トピックとの一意な関係。サブスクリプションのユニークキーは、(トピックURL, サブスクライバコールバックURL)のタプル。サブスクリプションは、定期的に更新する必要があるDHCPリースに似た有効期限を(ハブの決定次第で)持つことができます。
  • サブスクライバコールバックURL
    • サブスクライバが通知を受信するURL [WHATWG-URL]。
  • イベント
    • イベントは複数トピックの更新を引き起こします。 たとえば、「BradがLinuxコミュニティに投稿しました」などのイベントごとに、複数のトピックに影響を与える可能性があります。たとえば、（「Brad posted」や「Linux community has new post」など）。パブリッシャイベントはトピックの更新を引き起こし、ハブは影響を受けたトピックの購読状態をすべて検索し、通知をサブスクライバに送信します。
  • 通知
    • トピックの内容がどのように変更されたか、または更新された内容全体を表現するペイロード。トピックのコンテンツの種類に応じて、差分（または「デルタ」）がハブによって計算され、すべてのサブスクライバに送信されます。

2. ハイレベルプロトコルフロー

(このセクションは参考（non-normative）セクションです)

  • パブリッシャは彼らのトピックが変更された時に彼らのハブにURLを通知します。
  • サブスクライバは、興味を持っているトピックを、それが告知されているハブの1つ以上にPOSTします。
  • ハブは、トピックの変更を識別すると、登録されたすべてのサブスクライバに通知を送信します。

このプロトコルの以前のバージョンはPubSubHubbubと呼ばれました:

  • Working Draft 0.3 [PubSubHubbub-Core-0.3]
  • Working Draft 0.4 [PubSubHubbub-Core-0.4]

3. 適合性基準

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"は[RFC2119]で説明されているように解釈される。

3.1 適合性基準クラス

WebSubには、パブリッシャ、サブスクライバ、ハブの3つの役割が記述されています。 このセクションでは、各ロールの適合基準について説明します。

パブリッシャ

  • MUST 適合するパブリッシャは、発見（Discovery）で説明されている特定のリソースURLであるトピックURLとハブURLを宣言しなければならない。

サブスクライバ

A conforming subscriber:

  • MUST 特定の順序で各ディスカバリメカニズムをサポートし、ディスカバリで説明されているようにトピックURLとハブURLを検出します。
  • MUST 「サブスクライバは購読リクエストを送信します」で説明されているように購読リクエストを送信します。
  • MAY 特定のリース期間を要求する
  • MAY 購読リクエストに秘密を含めること。そうすることで、秘密を使用してコンテンツ配信リクエストのシグネチャを検証しなければならない。
  • MUST HTTP 2xxステータスコードを持つコンテンツ配信リクエストを確認します。
  • MAY 「購読解除」メカニズムを使用して購読状態が非アクティブ化されるように要求します。
ハブ

A conforming hub:

  • MUST hub.callback、hub.mode、およびhub.topicパラメータを使用して購読リクエストを受け入れます。
  • MUST hub.secretパラメーターを使用して購読リクエストを受け入れます。
  • MAY 購読リクエストにおける要求リース期間を尊重する。
  • MUST サブスクライバがすでにアクティブな購読状態を再リクエストできるようにします。
  • MUST 購読解除リクエストをサポートします。
  • MUST トピックURLのコンテンツタイプと一致するコンテンツ配信リクエストを送信します。
  • MAY コンテンツの配信で説明されているように、コンテンツ配信のペイロードを、サポートされているフォーマットにしたがってコンテンツの差分まで減らします。
  • MUST Authenticated Content Distributionで説明されているように、サブスクリプションがhub.secretで作成されている場合は、X-Hub-Signatureヘッダーを送信します。

3.2 Candidate Recommendation Exit Criteria

この仕様がCRステージを終了するには、各機能の少なくとも2つの独立した相互運用可能な実装が必要です。各機能は、異なる製品群によって実装されてもよい。すべての機能を単一の製品で実装する必要はありません。この基準の目的のために、以下の用語を定義する。

3.2.1 パブリッシャ

WebSubパブリッシャは、1つまたは複数のリソースURLにトピックおよびハブURLを宣伝する実装です。適合基準は、上記の適合クラスに記載されています。

3.2.2 サブスクライバ

WebSubサブスクライバは、リソースURLを指定してハブとトピックのURLを検出し、ハブの更新を購読し、ハブからのコンテンツ配信リクエストを受け入れる実装です。サブスクライバは、認証されたコンテンツ配信をサポートしてもよい(MAY)。適合基準は、上記の適合クラスに記載されています。

3.2.3 ハブ

WebSubハブは、購読リクエストを処理し、対応するトピックURLが更新されたときに通知をサブスクライバに配信する実装です。ハブは、秘密の購読リクエストをサポートし、リクエストを受けたときに認証された通知を配信しなければならない(MUST)。ハブは、通知内のトピックURLの完全な内容を配信しなければならず(MUST)、コンテンツタイプをサポートしていれば、ペイロードを差分に減らしてもよい(MAY)。適合基準は、上記の適合クラスに記載されています。

3.2.4 独立

各実装は、別々の当事者によって開発されなければならず、別の適格な実装で使用されるコードを共有、再利用、または派生することはできません。この仕様の実装に関係しないコードのセクションは、この要件から免除されます。

3.2.5 相互運用性

サブスクライバとハブの実装は、ハブがサブスクライバが要求する定義済みのアクションを取り、サブスクライバがその機能に従ってハブから期待されるレスポンスを取得し、ハブが予想されるレスポンスをサブスクライバに送信するときに、特定の機能に対して相互運用可能であると見なされます。

3.2.6 機能

退出基準を評価するために、以下の各項目が機能と見なされます。

  • リソースURLのHTTPヘッダーを見て、ハブとトピックのURLを検出します。
  • リソースURLの内容をXML文書として見て、ハブとトピックのURLを検出します。
  • リソースURLの内容をHTML文書として見て、ハブとトピックのURLを検出します。
  • Host-Meta Well-Known URIを使用してハブURLを検出する。
  • コールバックURLでハブを購読する。
  • ハブに加入し、特定のリース期間を要求する。
  • 秘密でハブに加入し、認証されたコンテンツ配信を処理する。
  • 購読解除解除リクエストを送信することによって、購読状態非アクティブ化されるように要求します。
  • サブスクライバは、検証リクエストに対して保留中の購読状態を確認します。
  • サブスクライバは、無効なトピックURLの購読状態検証リクエストを拒否します。
  • ペイロードが配信されると、サブスクライバはHTTP 2xxレスポンスを返します。
  • サブスクライバは、認証されたコンテンツ配信リクエストのシグネチャを検証します。
  • シグネチャが検証されない場合、サブスクライバは配布要求を拒否します。
  • サブスクライバは、サブスクリプションが秘密で行われた場合にシグネチャが存在しない場合、配布リクエストを拒否します。
  • ハブは、購読リクエスト内の要求リース期間を尊重します。
  • ハブは、サブスクライバがすでにアクティブな購読状態を再リクエストできるようにし、リース期間を延長します。
  • ハブは、配信リクエスト内のトピックURLの完全な内容を送信します。
  • ハブは、それをサポートする形式のトピックURLの差分を送信します。
  • ハブは、秘密で行われた購読に対して有効なシグネチャを送信します。

4. Discovery

The discovery mechanism aims at identifying at least 2 URLs.

  • サイト運営者によって指定されたハブのURL。 複数のURLが指定されている場合は、パブリッシャがこれらのURLのそれぞれにpingを実行し、サブスクライバがこれらのURLの1つ以上にサブスクライブすることが期待されます。
  • サブスクライバがサブスクリプションに使用するトピックの標準URL。

The protocol currently supports the following discovery mechanisms. Publishers MUST implement at least one of them:

  • リンクヘッダー[RFC5988]：発行者はrel = hub（ハブリンクヘッダー）とrel = self（自己リンクヘッダー）を持つちょうど1つのリンクヘッダー[RFC5988]を持つ少なくとも1つのリンクヘッダー[RFC5988]を含めるべきである（SHOULD）
  • トピックはXMLベースのフィードであるため、出版社はWeb Linking [RFC5988]の付録Bに記述されている埋め込みリンク要素を使用すべきです（SHOULD）。 同様に、HTMLページでは、Web Linking [RFC5988]の付録Aで説明されているように、パブリッシャは埋め込みリンク要素を使用すべきです（SHOULD）。 しかし、HTMLの場合、これらの要素はHTML文書のセクションにのみ存在しなければなりません。
  • 最後に、パブリッシャは、rel = "hub"を持つ要素を含めるために、Host-Meta Well-Known URI [RFC6415] /.well-known/host-metaを使用してもよい（MAY） 。 ただし、このメカニズムは現在At Riskであり、廃止される可能性があります。

Example 1

GET /feed HTTP/1.1
Host: example.com
HTTP/1.1 200 Ok
Content-type: text/html
Link: <https://hub.example.com/>; rel="hub"
Link: <http://example.com/feed>; rel="self"
<!doctype html>
<html>
<head>
<link rel="hub" href="https://hub.example.com/">
<link rel="self" href="http://example.com/feed">
</head>
<body>
...
</body>
</html>

When perfoming discovery, subscribers MUST implement all three discovery mechanisms in the following order, stopping at the first match:

  1. トピックURLを取得するためにGETリクエストまたはHEADリクエストを発行します。 サブスクライバはまずHTTPリンクヘッダをチェックしなければならない。
  2. HTTPリンクヘッダがなく、トピックがXMLベースのフィードまたはHTMLページである場合、ユーザは埋め込みリンク要素をチェックしなければならない（MUST）。
  3. HTTPリンクヘッダーと埋め込みリンク要素の両方がない場合、サブスクライバは、rel = "hub"の要素について、ホストメタのよく知られたURI [RFC6415] /.well-known/host-metaを検索しなければならない。 ただし、このメカニズムは現在At Riskであり、廃止される可能性があります。

Warning

Note: Host-Metaの検出方法は現在At Riskであり、推奨されない可能性があります。ワーキンググループは、この問題についてのフィードバックを求めています。これについてはここで説明します。

4.1 Content Negotiation

実際的な目的のために、rel = self URLは単一の表現しか提供しないことが重要です。 ハブは、発見時にサブスクライバが要求したMIMEタイプを知る方法がないため、同じMIMEタイプを使用して通知を実行することはできません。

ただし、コンテンツネゴシエーションで使用されるHTTPヘッダーに従って適切なrel = self URLを返すことによって、コンテンツネゴシエーションを実行することは可能です。 たとえば、application / jsonを含むAcceptヘッダーで/ feedを要求すると、/feed.jsonのrel = self値が返されます。

下の例は、送信されたAcceptヘッダーに応じてトピックURLが異なるリンクヘッダーを返す方法を示しています。

Example 2

GET /feed HTTP/1.1
Host: example.com
Accept: application/json
HTTP/1.1 200 Ok
Content-type: application/json
Link: </feed.json>; rel="self"
Link: <https://hub.example.com/>; rel="hub"
{
"items": [...]
}
Example 3
GET /feed HTTP/1.1
Host: example.com
Accept: text/html
HTTP/1.1 200 Ok
Content-type: text/html
Link: </feed.html>; rel="self"
Link: <https://hub.example.com/>; rel="hub"
<html>
...

5. 購読と購読取消

トピックURLを購読すると、順番にすぐに出現するか遅れが生じる可能性がある4つの部分で構成されます。

  • ハブを使用したサブスクリプションのリクエスト
  • サイト運営者とのサブスクリプションの検証 (OPTIONAL)
  • 購読者が実際に購読を確認していた
  • サブスクリプションを定期的に再確認することはまだ有効です (OPTIONAL)

サブスクライブ解除は、同じ方法で動作しますが、サブスクライブを希望することを示すために1つのパラメータが変更されています。また、ハブはパブリッシャとの契約解除要求を検証しません。

5.1 Subscriber Sends Subscription Request

サブスクリプションは、サブスクライバがハブURLに対してHTTPSまたはHTTP POST [RFC7231]要求を行うことによって開始されます。 この要求はapplication / x-www-form-urlencoded（セクション4.10.22.6 [HTML5]で説明されている）のContent-Typeヘッダーを持っていなければならず(MUST)、UTF-8 [エンコーディング]を文書の文字エンコーディングとして使用しなければならず(MUST)、 それに応じてフォーマットされた本体のパラメータ：

  • hub.callback
    • REQUIRED. 通知が配信されるべきサブスクライバのコールバックURL。コールバックURLは、サブスクリプションごとに一意ではない疑いのないURLである必要があります (SHOULD)。 （[機能 - URL]）
  • hub.mode
    • REQUIRED. 要求の目的に応じて、リテラル文字列 "subscribe"または "unsubscribe"。
  • hub.topic
    • REQUIRED. サブスクライバがサブスクリプションまたはサブスクライブを希望しているトピックURL。これは、発見ステップで見つかった「自己」URLでなければならない(MUST)ことに注意してください。これは、発見要求の作成に使用されたURLとは異なる場合があります。
  • hub.lease_seconds
    • OPTIONAL. サブスクリプションをアクティブにしたい場合の正の10進整数で与えられる秒数。 ハブは、自分のポリシーに応じて、この価値を尊重するかどうかを選択することができます。 このパラメタはアン購読リクエストのために存在するかもしれません、そして、その場合ハブによって無視されなければなりません。
  • hub.secret
    • OPTIONAL. 認可されたコンテンツ配信のためのHMACダイジェストを計算するために使用されるサブスクライバ提供の秘密ストリング。 指定されていない場合、コンテンツ配信要求に対してHMACダイジェストは存在しません。 このパラメタは、要求がHTTPS [RFC2818]でなされたときにのみ指定されるべきである（SHOULD）。 このパラメータは、200バイト未満の長さでなければならない（MUST）。

サブスクライバは、追加のHTTP [RFC7230]要求パラメータ、およびHTTP [RFC7230]ヘッダがハブによって必要とされる場合にはそれらも含めることができる（MAY）。

ハブは理解できない追加のリクエストパラメータを無視しなければならない（MUST）。

ハブは、既にアクティブになっているサブスクリプションをサブスクライバが再要求できるようにしなければならない。 サブスクライブまたはサブスクライブ解除のためのハブへの後続の各要求は、特定のトピックURLとコールバックURLの組み合わせに対して以前のサブスクリプション状態を上書きする必要があります。 検証に失敗した場合は、サブスクリプションの状態を変更しないでください。 これは、リース期間が終了する前に契約者が中断することなく契約を更新できるようにするために必要です。 サブスクライバは、将来のサブスクリプションで新しいhub.secret値を使用し、hub.secretなしで新しいサブスクリプションを作成することができる（MAY）。

5.1.1 Subscription Parameter Details

トピックとコールバックURLは、HTTPまたはHTTPS [RFC7230]スキームを使用してもよい（MAY）。 トピックURLは、ディスカバリー段階で自己リンクヘッダー内のパブリッシャによってアドバタイズされたものでなければなりません。 （セクション3を参照）。 ハブは、トピックのURLがパブリッシャが広告するものと一致しない場合、サブスクリプションを拒否することがあります（MAY）。 トピックURLは、そうでなければURL仕様[WHATWG-URL]に従って自由形式にすることができます。 ハブは、これらのURLパラメータのために予約されていない文字を常にデコードしなければならない（MUST） [WHATWG-URL]の「Percent-encoded bytes」のセクション1.2を参照してください。

コールバックURLは、推測できないユニークなURL（[capability-urls]）でなければならず、SHOULDはHTTPS [RFC7230]を使用すべきです（SHOULD）。 コールバックURLは、サブスクリプションの確認と通知の配信時に、ハブからサブスクライバへの認証として機能します。 さらに、コールバックはユニークであるべきであり（複数のハブでは再利用されない）、サブスクリプションが更新されるときに変更されるべきです（SHOULD）。

コールバックURLには、任意のクエリ文字列パラメータ（たとえば、？foo = bar＆red = fish）を含めることができます。 ハブは、結合する＆（アンパサンド）文字を使用して、リストの最後に新しいパラメータを追加することによって、サブスクリプションの検証中にクエリ文字列を保持しなければならない（MUST）。 検証要求で使用される名前と重複する既存のパラメータは上書きされません。 イベント通知の場合、コールバックURLは、POST本体パラメーターではなく、要求のURL部分にクエリー文字列パラメーターを含めるようにPOSTされます。

5.1.2 Subscription Response Details

ハブURLがWebSubをサポートしており、サブスクリプションまたは購読リクエストを処理できる場合は、HTTP [RFC7231] 202 "Accepted"応答を持つ購読リクエストに応答して、要求が受信されたことを示す必要があります ）、ハブによって検証された（セクション4.2）。 ハブは、できるだけ早くインテントの検証と検証を実行すべきである（SHOULD）。

ハブが購読リクエスト内にエラーを検出した場合、適切なHTTP [RFC7231]エラー応答コード（4xxまたは5xx）を返さなければなりません。 エラーが発生した場合、ハブはレスポンス本文のエラーの説明をプレーンテキストとして返します。クライアントの開発者がエラーを理解するのを助けるために使用されます。 これはエンドユーザーに表示されることを意味しません。 ハブは、独自のポリシー（ドメイン承認、トピックURLポート番号など）に基づいて、いくつかのコールバックURLまたはトピックURLを拒否することができます（MAY）。 しかし、HTTP応答が返された後に論理的に開始する非同期ステップであるため、検証または検証のプロセスまたは結果に依存してはなりません（MUST NOT）。

ハブURLがサブスクリプションまたはサブスクライブ解除要求を処理できない場合、WebSubをサポートする別のハブにリダイレクトされる可能性があります。 これは、HTTP [RFC7231] 307（一時的なリダイレクト）または308（永続的なリダイレクト）応答を生成することによってそうする。 それは、ハブがサブスクライバによって使用されるための好ましいURL参照を含む少なくともHTTP [RFC7230]ロケーションヘッダも含まなければならない（MUST）。 サブスクライバは、新しいハブURLでサブスクリプションまたはサブスクリプションを再試行する必要があります。

5.2 Subscription Validation

サブスクリプションは、サブスクリプションの受諾または拒否の詳細が必要なハブによって検証される可能性があります。ハブは、サブスクリプションを受け入れるかどうかをパブリッシャに確認することもできます。

サブスクリプションが受諾された場合、サブスクライバはそのサブスクライバのインテントの検証を実行しなければならない（MUST）。

サブスクリプションが拒否された場合、サブスクライバは購読リクエストに指定されているように、サブスクライバのコールバックURLにHTTP [RFC7231] GET要求を送信してサブスクライバに通知する必要があります。 このリクエストには、次のクエリ文字列引数が追加されています（[WHATWG-URL]のセクション4で説明されている形式）。

  • hub.mode
    • REQUIRED. リテラル文字列 "denied"。
  • hub.topic
    • REQUIRED. 対応するサブスクリプションリクエストで指定されたトピックのURL。
  • hub.reason
    • OPTIONAL. ハブには、サブスクリプションが拒否された理由が含まれる場合があります。

ハブは、追加のHTTP [RFC7231] Locationヘッダ（Hypertext Transfer Protocol [RFC7231]のセクション7.1.2で説明されているように）を提供して、サブスクライバが異なるhub.topicに加入を再試行できることを示すことができる。 これにより、ソーシャルウェブアプリケーションのコンテキストで、特定のグループまたはユーザに限定的に配布することができます。

サブスクリプションは、（以前に受け入れられたとしても）どの時点でもハブによって拒否されることがあります。サブスクライバは、加入がもはや不可能であると考えるべきである（SHOULD）

5.3 Hub Verifies Intent of the Subscriber

攻撃者がサブスクライバに代わって望ましくない購読を作成しないようにするには、購読者が実際に購読要求を送信したことをハブが保証する必要があります。

ハブは、購読リクエストで指定されているように、サブスクライバのコールバックURLにHTTP [RFC7231] GET要求を送信することによって、購読リクエストを検証します。 このリクエストには、次のクエリ文字列引数が追加されています（[WHATWG-URL]のセクション4で説明されている形式）。

  • hub.mode
    • REQUIRED. リテラル文字列 "subscribe"または "unsubscribe"。サブスクライバからハブへの元の要求に一致します。
  • hub.topic
    • REQUIRED. 対応するサブスクリプションリクエストで指定されたトピックのURL。
  • hub.challenge
    • REQUIRED. サブスクリプションを検証するためにサブスクライバによってエコーされなければならないハブ生成のランダムな文字列。
  • hub.lease_seconds
    • REQUIRED/OPTIONAL. 有効期限が切れる前にサブスクリプションがアクティブにとどまるハブが決定した秒数。ハブからサブスクライバへの検証要求が行われた時刻から測定されます。 ハブはサブスクリプションリクエストにこのパラメータを供給しなければならない（MUST）。 このパラメタは、加入解除要求のために存在してもよく、加入解除中にサブスクライバが無視しなければならない（MUST）。

5.3.1 Verification Details

サブスクライバは、hub.topicが実行したい保留中のサブスクリプションまたはサブスクリプションに対応していることを確認しなければならない（MUST）。 その場合、サブスクライバは、hub.challengeパラメータに等しいレスポンスボディを持つHTTP成功（2xx）コードで応答しなければならない。 サブスクライバがアクションに同意しない場合、サブスクライバは404 "Not Found"レスポンスで応答しなければならない（MUST）。

ハブは、他のサーバ応答コード（3xx、4xx、5xx）が検証要求が失敗したことを意味しなければならない（MUST）。 サブスクライバがHTTP [RFC7231]の成功（2xx）を返したが、コンテンツ本文がhub.challengeパラメータと一致しない場合、ハブは検証が失敗したとみなさなければならない（MUST）。

ハブは、サブスクライバが購読リクエストで渡した値と等しいhub.lease_secondsを作成することができますが、ハブのポリシーに応じて値を変更することがあります。 サブスクリプションを維持するには、hub.lease_seconds秒が経過する前にサブスクライバはサブスクリプションでサブスクリプションを再要求しなければならない（MUST）。

ハブは期限切れのリースを行う必要があります。また、永久リース期間を発行してはいけません。

Note

この仕様では、GETとPOSTを使用して、購読リクエストの確認/拒否と実際の通知を区別します。 これはWebアーキテクチャの観点からは「ベストプラクティス」とはみなされませんが、コールバックURLの実装が簡単になります。 通知のPOST本体は任意のコンテンツタイプであり、ドキュメントの実際の内容のみを含むので、これら2つのモードの処理を切り替えるためのGETとPOSTの区別を使用すると実装が簡単になります。

6. 出版

パブリッシャは、トピックが更新されたときに以前に指定したハブにその旨を通知しなければならない（MUST）。 ハブが更新されたペイロードを最終的にサブスクライバに送信できる限り、ハブおよびパブリッシャはどのようなメカニズムにも同意することができる。

7. コンテンツ配信

トピックURLに対して新しいコンテンツが利用可能な場合、コンテンツ配信要求がハブからサブスクライバに送信されます。 リクエストは、ハブからサブスクライバのコールバックURLへのHTTP [RFC7231] POSTリクエストです。 POSTリクエストのHTTP本体は、通知のペイロードを含まなければなりません（MUST）。 コンテンツ配信要求は、トピックのContent-Typeに対応するContent-Type Headerを持っていなければならず、トピックURLの完全な内容を含んでいなければならない（MUST）。

Atom（[RFC4287]）とRSS（[RSS-2.0]）フィードの場合、ハブはすでに配信されているatom：entryまたはrss：item要素をフィードから削除してもよい（MAY）。

要求は、更新されるトピックに関連するハブを指し示すrel = hubを有する少なくとも1つのリンクヘッダ[RFC5988]を含まなければならない（MUST）。 更新中のトピックの標準URLにrel = selfが設定された1つのリンクヘッダー[RFC5988]も含める必要があります。 ハブは、これらのヘッダーを単一のリンクヘッダー[RFC5988]に組み合わせるべきです（SHOULD）。 これらのURLはすべて、発見プロセスの結果であるものです（第3章）。 リンクヘッダーは、特定のサブスクリプションではなく、トピックコンテンツに関連付けられたメタデータであるため、サブスクライバは、コンテンツ配信要求に対応するサブスクリプションを識別するためにこれらのリンクヘッダーを使用してはいけません。 ハブは、トピックの標準URLとハブURLの変更を検出するために、時々ディスカバリを使用してもよい（MAY）。 そのような変更によって、その後のコンテンツ配信要求で送信されるリンクヘッダーが変更されます。

サブスクライバのコールバックURLからの成功した応答は、HTTP [RFC7231]成功（2xx）コードでなければならない（MUST）。 ハブは、他のすべてのサブスクライバ応答コードを失敗としてみなさなければならない（MUST） つまり、購読者は購読を移動するためにHTTPリダイレクトを使用してはいけません。 サブスクライバはできるだけ早く通知に応答しなければならない（SHOULD）。 彼らの成功応答コードは、それがサブスクライバによって首尾よく処理されたという確認ではなく、メッセージの受信を示すだけであるべきです（SHOULD）。 サブスクライバからの応答本文は、ハブによって無視されなければならない（MUST）。 ハブは、再試行の回数と全体的な時間の自己制限を超えて通知を再試行しなければならない（SHOULD）。 失敗した配信がハブの制限を超えた場合、ハブはサブスクリプションを終了します。

7.1 認証されたコンテンツ配信

サブスクライバが購読リクエストでhub.secretの値を提供した場合、ハブはペイロードのHMACシグネチャを生成し、そのシグネチャをコンテンツ配信要求の要求ヘッダーに含める必要があります。 X-Hub-Signatureヘッダーの値は、method = signatureの形式でなければならない（MUST）。methodは認識されたアルゴリズム名の1つであり、signatureは16進数の署名である。 この署名は、要求本体をデータとして、hub.secretを鍵としてHMACアルゴリズム[RFC6151]を用いて計算しなければならない（MUST）。

7.1.1 Recognized algorithm names

The following algorithms are the initially registered algorithm names, based on the contents of the referenced registry at the time of publishing. [FIPS PUB 180-4]

  • sha1
    • The SHA-1 algorithm as specified in Section 6.1 of [FIPS PUB 180-4]
  • sha256
    • The SHA-256 algorithm as specified in Section 6.2
  • sha384
    • The SHA-384 algorithm as specified in Section 6.5
  • sha512
    • The SHA-512 algorithm as specified in Section 6.4

In the future, any algorithm added to [FIPS PUB 180-4] SHOULD be supported by hubs and subscribers.

7.1.2 Signature validation

ユーザは、X-Hub-Signatureヘッダが指定されたコンテンツ配信要求を受信すると、ハブと同じ方法（X-Hub-Signatureヘッダで提供）を使用して共有秘密鍵で署名を再計算すべきである（SHOULD）。 署名が一致しない場合、購読者は領収書を確認するために2xx成功応答を返さなければならないが、メッセージを無効としてローカルで無視しなければならない。 このテクニックをサブスクリプションリクエスト用にHTTPS [RFC2818]とともに使用すると、単純なサブスクライバはHTTPS [RFC2818]サーバを実行する必要なく、ハブから認証済みの通知を受信できます。

ただし、この署名はペイロードが偽造されていないことを保証します。 通知にはヘッダーも含まれているので、サブスクライバがHTTPS [RFC2818]コールバックを使用していない限り、これらはヘッダーを含むので、これらは、サブスクライバが安全と考えるべきではありません。

8. Security Considerations

Here is a summary of security considerations. It is important to note that WebSub is a server to server protocol which relies only on HTTP. It is strongly recommended to use HTTPS for all requests.

8.1 Discovery

There are no specific security considerations for discovery.

8.2 Subscriptions

First, subscribers SHOULD always favor the HTTPS URL for hubs (even if the URL is advertised as HTTP). Then the subscribers SHOULD use unique unguessable capability URLs for the callbacks, as well as make them available via HTTPS. Finally, subscribers SHOULD use a hub.secret when subscribing to allow signature of the content distribution. Hubs SHOULD enforce short lived hub.lease_seconds (10 days is a good default). When performing intent verification, the hub SHOULD use a random, single use hub.challenge.

8.3 Distribution

The Hub MUST use the exact callback used by the subscriber (including the use of HTTPS). Hubs MUST sign their requests using the hub.secret supplied by subscribers. Subscribers MUST perform the same signature mechanism and MUST discard notifications which failed this test.

8.4 Security and Privacy Review

These questions provide an overview of security and privacy considerations for this specification as guided by Self-Review Questionnaire: Security and Privacy ([security-privacy-questionnaire]).

  • Does this specification deal with personally-identifiable information?
    • The only potentially personally-identifiable information involved are topic and callback URLs.
  • Does this specification deal with high-value data?
    • No, there is no authentication or other credentials involved.
  • Does this specification introduce new state for an origin that persists across browsing sessions?
    • No.
  • Does this specification expose persistent, cross-origin state to the web?
    • The WebSub subscriber should create a resource with information about the topic to which it subscribes.
  • Does this specification expose any other data to an origin that it doesn't currently have access to?
    • No.
  • Does this specification enable new script execution/loading mechanisms?
    • No.
  • Does this specification allow an origin access to a user's location?
    • No.
  • Does this specification allow an origin access to sensors on a user's device?
    • No.
  • Does this specification allow an origin access to aspects of a user's local computing environment?
    • No.
  • Does this specification allow an origin access to other devices?
    • No.
  • Does this specification allow an origin some measure of control over a user agent's native UI?
    • No.
  • Does this specification expose temporary identifiers to the web?
    • No.
  • Does this specification distinguish between behavior in first-party and third-party contexts?
    • No.
  • How should this specification work in the context of a user agent's "incognito" mode?
    • WebSub is a server to server protocol, in which "incognito" mode does not have a meaning.
  • Does this specification persist data to a user's local device?
    • No.
  • Does this specification allow downgrading default security characteristics?
    • No.

A. Change Log

This section is non-normative.

A.1 Changes from 24 November WD to this version

  • Clarified wording on supported algorithms for authenticated distribution
  • Only allow tags in the HTML element
  • Added conformance criteria and CR exit criteria
  • Added examples of discovery request and response
  • Added example of using different rel=self URLs to support content negotiation
  • Added a security considerations section
  • Updated references to [WHATWG-URL] instead of HTML 4
  • Replaced abstract with updated description

A.2 Changes from 20 October FPWD to 24 November 2016

  • Added informative reference to previous versions of the spec, PubSubHubbub 0.3 and 0.4
  • Split discovery section into separate publisher and subscriber sections
  • Clarify that publishers can use any available discovery method, and subscribers must support all
  • Marked host-meta discovery method At Risk due to no known implementations, and fixed reference to Host Meta spec instead of the previous reference to Well-Known
  • Recommend using Capability URLs as the subscriber's callback URLs for security and authenticating the notification delivery
  • Recommend not reusing callback URLs on subscription renewals
  • Clarify that the hub.topic must be the self URL that was discovered
  • Dropped the recommendation of including the From header on subscription requests
  • Clarify that the hub response to subscription requests must not depend on the verification or validation
  • Hubs must enforce lease expirations
  • Clarify that the notification payload should contain the full contents of the topic URL
  • Recommend that hubs should retry failed notification delivery up to self-imposed limits
  • Clarify that future defined signature methods in FIPS PUB 180-4 are allowed
  • Added informative note about the use of GET vs POST at the callback URL
  • Renamed the spec to WebSub

B. References

B.1 Normative references

B.2 Informative references

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment