Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 7033 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 M. Jones
Microsoft
J. Smarr
Google
September 2013
WebFinger
概要
この仕様はWebFingerプロトコルを定義する。これは、標準的なHTTPメソッドを用いて、
インターネット上の人やその他のエンティティに関する情報を発見するために使用できる。
WebFingerは、アカウントURIや電子メールURIなど、そうでなければロケータとして
使用できない可能性のあるURIについての情報を発見する。
このメモの位置づけ
これはInternet Standards Track文書である。
この文書はInternet Engineering Task Force（IETF）の成果物である。これはIETF
コミュニティの合意を表している。公開レビューを受けており、Internet Engineering
Steering Group（IESG）によって発行が承認されている。Internet Standardsに関する
詳細情報はRFC 5741のセクション 2で入手できる。
この文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、
http://www.rfc-editor.org/info/rfc7033で入手できる。
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones, et al. Standards Track [Page 1]
RFC 7033 WebFinger September 2013
目次
1. はじめに ....................................................3
2. 用語 .........................................................3
3. WebFingerの使用例 ............................................4
3.1. OpenID Connectにおけるアイデンティティプロバイダーの発見 ...4
3.2. Webページの著者および著作権情報の取得 ......................5
4. WebFingerプロトコル ..........................................7
4.1. 要求URIのクエリコンポーネントの構築......................7
4.2. WebFingerクエリの実行....................................8
4.3. "rel"パラメーター........................................9
4.4. JSON Resource Descriptor（JRD）..........................11
4.4.1. subject.............................................11
4.4.2. aliases.............................................11
4.4.3. properties..........................................12
4.4.4. links...............................................12
4.5. WebFingerとURI..........................................14
5. Cross-Origin Resource Sharing（CORS） ........................14
6. アクセス制御 .................................................15
7. ホスト型WebFingerサービス ....................................15
8. WebFingerアプリケーションの定義 ..............................16
8.1. URIスキームおよびURIの仕様 ..............................17
8.2. ホスト解決 ..............................................17
8.3. プロパティの仕様 ........................................17
8.4. リンクの仕様 ............................................18
8.5. 1つのURI、複数のアプリケーション ........................18
8.6. リンク関係型およびプロパティの登録 ......................19
9. セキュリティ上の考慮事項 .....................................19
9.1. トランスポート関連の問題 ................................19
9.2. ユーザーのプライバシーに関する考慮事項 ..................19
9.3. 悪用の可能性 ............................................21
9.4. 情報の信頼性 ............................................21
10. IANAに関する考慮事項 .......................................22
10.1. Well-Known URI .........................................22
10.2. JSON Resource Descriptor（JRD）メディア型 ...............22
10.3. リンク関係型の登録 .....................................24
10.4. "WebFinger Properties"レジストリの設立 .................24
10.4.1. 登録テンプレート .................................24
10.4.2. 登録手続き .......................................25
11. 謝辞 .......................................................26
12. 参考文献 ....................................................26
12.1. 規範的参考文献 ........................................26
12.2. 参考情報 ..............................................27
Jones, et al. Standards Track [Page 2]
RFC 7033 WebFinger September 2013
1. はじめに
WebFingerは、セキュアなトランスポート [12] 上で標準的な
Hypertext Transfer Protocol（HTTP）[2] メソッドを用い、URI [6] によって
識別される、インターネット上の人やその他のエンティティに
関する情報を発見するために使用される。WebFingerリソースは、
照会されたエンティティを記述するJavaScript Object Notation
（JSON）[5] オブジェクトを返す。このJSONオブジェクトは
JSON Resource Descriptor（JRD）と呼ばれる。
人の場合、WebFingerを通じて発見可能な情報の種類には、
個人プロフィールのアドレス、アイデンティティサービス、
電話番号、または優先アバターが含まれ得る。インターネット上の
その他のエンティティについては、WebFingerリソースは、たとえば
プリンターがA4用紙にカラー印刷できること、サーバーの物理的な
位置、またはその他の静的情報をクライアントが発見できるようにする
リンク関係 [8] を含むJRDを返すことがある。
WebFingerによって返される情報は、人が直接利用するためのもの
（例：誰かの電話番号を調べる）である場合もあれば、何らかの
操作の実行を支援するためにシステムによって使用される場合もある
（例：追加のセキュリティ機構とともに、ユーザーの
アイデンティティサービスを特定することでWebサイトへのログインを
容易にする）。この情報は性質上静的であることを意図しており、
したがってWebFingerは、CPUの温度やレーザープリンターの現在の
トナー残量のような動的情報を返すために使用することを意図していない。
WebFingerプロトコルは、多くのアプリケーションで使用されるように
設計されている。WebFingerを利用したいアプリケーションは、その
アプリケーションに適したプロパティ、タイトル、およびリンク関係型を
指定する必要がある。さらに、アプリケーションは、クエリ対象に
利用する適切なURIスキームを定義する必要がある。
WebFingerの使用はSection 3の例で示され、
Section 4でより形式的に説明される。Section 8では、
WebFingerのアプリケーションをどのように定義できるかを説明する。
2. 用語
この文書におけるキーワード"MUST"、"MUST NOT"、"REQUIRED"、
"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、
"MAY"、および"OPTIONAL"は、RFC 2119 [1]で説明されている
とおりに解釈されるものとする。
WebFingerは「リンク関係」を多用する。リンク関係とは、
属性が、リンクされたエンティティまたはリソースと、値で
指定された情報との間の関係の種類を識別する、属性値ペアである。
Web Linking [4]では、リンク関係は"Link"というHTTP
エンティティヘッダーを用いて表され、そこで"rel"属性が関係の
種類を指定し、"href"
Jones, et al. Standards Track [Page 3]
RFC 7033 WebFinger September 2013
属性が、エンティティまたはリソースにリンクされた情報を指定する。
WebFingerでは、同じ概念が"links"オブジェクトのJSON配列を
用いて表され、"rel"という名前の各メンバーが関係の種類を
指定し、"href"という名前の各メンバーがエンティティまたは
リソースにリンクされた情報を指定する。なおWebFingerは、
"rel"メンバーの値が、単一のIANA登録済みリンク関係型 [8]
またはURI [6] のいずれかでなければならないと規定することにより、
Web Linkingで定義されているものよりもリンク関係の範囲を狭める。
この文書全体でURIを用いる場合、それはRFC 3986の
セクション 3 [6] で指定された構文に従うURIを指す。
RFC 3986のセクション 4.2の構文に従う相対URIは、
WebFingerでは使用されない。
3. WebFingerの使用例
このセクションでは、WebFingerのいくつかの使用例を示す。
WebFingerの任意のアプリケーションは、Section 8で説明される
とおり、この文書の外部で指定されることになる。このセクションの
例は、それらのアプリケーションの正式な仕様を見ていなくても
理解できる程度に単純であるべきである。
3.1. OpenID Connectにおけるアイデンティティプロバイダーの発見
Carolが、訪問したWebサイトでOpenID Connect [15]を使用して
認証したいとする。彼女はそのWebサイトに、自分のOpenID
Connect識別子、たとえばcarol@example.comを提供する。訪問先の
Webサイトは、OpenID Connectプロバイダーを探すWebFingerクエリを
実行する。そのサイトは1つの特定のリンク関係だけに関心があるため、
WebFingerリソースはSection 4.3で説明されるように
"rel"パラメーターを利用することがある。
GET /.well-known/webfinger?
resource=acct%3Acarol%40example.com&
rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1
Host: example.com
Jones, et al. Standards Track [Page 4]
RFC 7033 WebFinger September 2013
サーバーは次のように応答することがある。
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
"subject" : "acct:carol@example.com",
"links" :
[
{
"rel" : "http://openid.net/specs/connect/1.0/issuer",
"href" : "https://openid.example.com"
}
]
}
"rel"パラメーターは、リソースによって返されるリンク関係を
フィルターするためだけに機能するため、応答内の他の名前/値ペア、
すなわちエイリアスやプロパティを含むものは返される。また、
"rel"パラメーターのサポートは保証されていないため、クライアントは
"links"配列が要求されたリンク関係のみを含むと仮定してはならない。
3.2. Webページの著者および著作権情報の取得
著者や著作権情報など、WebページURLに関するメタデータ情報を
取得するアプリケーションが定義されているとする。その情報を
取得するために、クライアントはWebFingerを利用して特定のURLに対する
クエリを発行できる。関心のあるURLが
http://blog.example.com/article/id/314 であるとする。クライアントは
次のようなクエリを発行することになる。
GET /.well-known/webfinger?
resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314
HTTP/1.1
Host: blog.example.com
Jones, et al. Standards Track [Page 5]
RFC 7033 WebFinger September 2013
するとサーバーは次のように応答することがある。
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
"subject" : "http://blog.example.com/article/id/314",
"aliases" :
[
"http://blog.example.com/cool_new_thing",
"http://blog.example.com/steve/article/7"
],
"properties" :
{
"http://blgx.example.net/ns/version" : "1.3",
"http://blgx.example.net/ns/ext" : null
},
"links" :
[
{
"rel" : "copyright",
"href" : "http://www.example.com/copyright"
},
{
"rel" : "author",
"href" : "http://blog.example.com/author/steve",
"titles" :
{
"en-us" : "The Magical World of Steve",
"fr" : "Le Monde Magique de Steve"
},
"properties" :
{
"http://example.com/role" : "editor"
}
}
]
}
上の例では、サーバーが対象URLに関連するエイリアス、プロパティ、
およびリンクのリストを返していることがわかる。リンクには、
各リンク関係型についての情報への参照が含まれる。著者リンクについては、
サーバーは著者のブログへの参照を、2つの言語でのブログタイトルと
ともに提供した。サーバーはまた、著者に関連する単一のプロパティを
返し、その著者がブログの編集者であることを示している。
Jones, et al. Standards Track [Page 6]
RFC 7033 WebFinger September 2013
この例ではサーバーが"links"配列内に2つのリンクだけを返したが、
照会された場合、サーバーは任意の数のリンクを返すことがある点に
留意する価値がある。
4. WebFingerプロトコル
WebFingerプロトコルは、クエリ対象（URI）によって識別される
エンティティに関する情報を要求するために使用される。クライアントは、
情報を受け取りたい1つ以上のリンク関係型を任意で指定できる。
WebFinger要求は、WebFingerリソースに対するHTTPS要求である。
WebFingerリソースは、必須のクエリ対象および任意のリンク関係型と
ともに構築される、HTTPSスキームを用いるwell-known URI [3]である。
WebFingerリソースは、（HTTPなどの）他のいかなるURIスキームでも
提供されてはならない（MUST NOT）。
WebFingerリソースには常にクエリ対象が与えられる。これは、情報を
求めるエンティティを識別する別のURIである。WebFingerリソースへの
GET要求は、WebFinger URIのクエリ文字列の"resource"パラメーターで
クエリ対象を伝える。詳細はSection
4.1を参照。
WebFingerクエリが発行されるホストは重要である。クエリ対象が
"host"部分（RFC 3986のセクション 3.2.2）を含む場合、
WebFingerクエリが発行されるホストは、クライアントが何らかの
帯域外機構を通じて別のホストにクエリを送る指示を受けない限り、
クエリ対象の"host"部分と同じであるべきである（SHOULD）。
クエリ対象が"host"部分を含まない場合、クライアントは自分が持つ
追加情報を用いて、クエリの送信先となるホストを選択する。
WebFinger URIのパスコンポーネントは、well-knownパス
"/.well-known/webfinger"でなければならない（MUST）。WebFinger URIは、
Section 4.1で指定されるように、クエリ対象および任意の
リンク関係型をエンコードするクエリコンポーネントを含まなければ
ならない（MUST）。
WebFingerリソースは、インターネット上のエンティティに関する情報を
伝えるため、リソース表現としてJSON Resource Descriptor（JRD）を返す。
また、Webブラウザー経由で行われるクエリを容易にするため、
Cross-Origin Resource Sharing（CORS）[7]仕様が利用される。
4.1. 要求URIのクエリコンポーネントの構築
WebFinger URIは、クエリコンポーネントを含まなければならない
（RFC 3986のセクション 3.4を参照）。クエリコンポーネントは
"resource"パラメーターを含まなければならず（MUST）、
1つ以上の"rel"パラメーターを含んでもよい（MAY）。"resource"
Jones, et al. Standards Track [Page 7]
RFC 7033 WebFinger September 2013
パラメーターはクエリ対象（URI）を含まなければならず（MUST）、
"rel"パラメーターは、このセクションで説明するエンコーディングに
従ってエンコードされたリンク関係型を含まなければならない（MUST）。
クエリコンポーネントを構築するため、クライアントは次の手順を
実行する。まず、各パラメーター値をRFC 3986のセクション 2.1に
従ってパーセントエンコードする。このエンコーディングは、その仕様の
Section 3.4におけるquery生成規則に適合するように行われるが、
さらに、パラメーター値内に現れる"="および"&"文字も
パーセントエンコードされる。次に、クライアントは、最初の
パラメーターの名前、等号（"="）、およびパーセントエンコードされた
パラメーター値を連結することにより、クエリコンポーネントに配置する
文字列を構築する。後続の各パラメーターについては、クライアントは
文字列にアンパサンド（"&"）、次のパラメーターの名前、等号、
およびパラメーター値を追加する。クライアントは文字列を構築する際に
空白を挿入してはならない（MUST NOT）。クライアントが各属性値ペアを
クエリコンポーネント内に配置する順序は、クエリコンポーネントの
解釈において問題とならない。
4.2. WebFingerクエリの実行
WebFingerクライアントは、パスコンポーネントが
"/.well-known/webfinger"であり、クエリコンポーネントが
"resource"パラメーターを正確に1回含み、情報を求めるURIの値に
設定されていなければならないURIによって識別されるwell-known
[3]リソースに対して、GETメソッドを用いてクエリを発行する。
"resource"パラメーターが存在しない、または不正な形式である場合、
WebFingerリソースは、RFC 2616のセクション 10.4.1 [2]に従って、
要求が不正であることを示さなければならない（MUST）。
"resource"パラメーターが、サーバーに情報がない値である場合、
サーバーは、RFC 2616のセクション 10.4.5に従って、要求に
一致させることができなかったことを示さなければならない（MUST）。
クライアントは、HTTPSのみを用いてWebFingerリソースにクエリを
行わなければならない（MUST）。クライアントが、リソースの証明書が
無効であると判断した場合、リソースが4xxまたは5xxステータスコードを
返した場合、またはHTTPS接続を何らかの理由で確立できない場合、
クライアントはWebFingerクエリが失敗したことを受け入れなければ
ならず（MUST）、非セキュアな接続上のHTTPを用いてWebFinger要求を
再発行しようとしてはならない（MUST NOT）。
WebFingerリソースは、クライアントがHTTPの"Accept"ヘッダーを通じて
他のサポートされる形式を明示的に要求しない場合、リソースの表現として
JRDを返さなければならない（MUST）。クライアントは、望ましい表現を
示すために"Accept"ヘッダーを含めてもよい（MAY）。JRD以外の表現は、
将来の仕様で定義されることがある。WebFinger
Jones, et al. Standards Track [Page 8]
RFC 7033 WebFinger September 2013
リソースは、理解またはサポートしていない要求された表現を
黙って無視しなければならない（MUST）。JSON Resource Descriptor
（JRD）に使用されるメディア型は"application/jrd+json"である
（Section 10.2を参照）。
サーバーがJRD内で返すプロパティ、タイトル、およびリンク関係型は、
多様かつ多数であり得る。たとえば、サーバーは、ある人のブログ、
vCard [14]、アバター、OpenID Connectプロバイダー、RSSまたは
ATOMフィードなどに関する情報を応答として返すことがある。同様に、
サーバーが提供する情報を持たない場合、空の"links"配列を持つJRD、
または"links"配列を持たないJRDを返すことがある。
WebFingerリソースはクライアントをリダイレクトしてもよい（MAY）。
その場合、リダイレクト先は"https" URIのみでなければならず（MUST）、
クライアントはリダイレクト時に再度証明書検証を実行しなければならない
（MUST）。
WebFingerリソースは、RFC 2616のセクション 13に従って、クライアントに
よる条件付き要求を可能にするキャッシュバリデーター、および/または
有効期限を応答に含めることができる。
4.3. "rel"パラメーター
WebFingerリソースに要求を発行する際、クライアントは"rel"
パラメーターを利用して、"rel"パラメーターなしで返されるはずの
情報のサブセットのみを要求してもよい（MAY）。"rel"パラメーターが
使用され、受け入れられた場合、"rel"パラメーターを通じて提供された
リンク関係型に一致するリンク関係型のみが、JRDで返されるリンク配列に
含まれる。リソースに対して定義された一致するリンク関係型がない場合、
JRD内の"links"配列は存在しないか、または空になる。リソース記述子内に
存在するその他すべての情報は、"rel"が使用されている場合でも
存在したままである。
複数のリンク関係型を要求するため、"rel"パラメーターは複数回
含めてもよい（MAY）。
"rel"パラメーターの目的は、リソース記述子内で通常返される
"link relation objects"（Section 4.4.4を参照）のサブセットを
返すことである。このパラメーターの使用は、クライアントまたはサーバーの
処理要件を削減する可能性があり、また、特定の"resource"値について
伝達すべきリンク関係値が多数ある場合には、部分的なリソース記述子を
伝達するために必要な帯域幅を削減する可能性もある。なお、クライアントが
特定のリンク関係型を要求し、サーバーがそれについて情報を持たない場合、
サーバーは空の"links"配列を持つJRD、または"links"配列を持たない
JRDを返してもよい（MAY）。
Jones, et al. Standards Track [Page 9]
RFC 7033 WebFinger September 2013
WebFingerリソースは"rel"パラメーターをサポートすべきである（SHOULD）。
リソースが"rel"パラメーターをサポートしない場合、リソースはその
パラメーターを無視し、"rel"パラメーター値が存在しなかったかのように
要求を処理しなければならない（MUST）。
次の例では、"rel"パラメーターを使用して2つのリンク関係型のリンクを
要求している。
GET /.well-known/webfinger?
resource=acct%3Abob%40example.com&
rel=http%3A%2F%2Fwebfinger.example%2Frel%2Fprofile-page&
rel=http%3A%2F%2Fwebfinger.example%2Frel%2Fbusinesscard HTTP/1.1
Host: example.com
この例では、クライアントは型
"http://webfinger.example/rel/profile-page"および
"http://webfinger.example/rel/businesscard"のリンク関係を要求している。
その後、サーバーは次のようなメッセージで応答する。
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
{
"subject" : "acct:bob@example.com",
"aliases" :
[
"https://www.example.com/~bob/"
],
"properties" :
{
"http://example.com/ns/role" : "employee"
},
"links" :
[
{
"rel" : "http://webfinger.example/rel/profile-page",
"href" : "https://www.example.com/~bob/"
},
{
"rel" : "http://webfinger.example/rel/businesscard",
"href" : "https://www.example.com/~bob/bob.vcf"
}
]
}
Jones, et al. Standards Track [Page 10]
RFC 7033 WebFinger September 2013
応答からわかるように、リソース表現には、クライアントが要求し、
サーバーが情報を持っていた型のリンクだけが含まれているが、JRDの
他の部分は依然として存在している。また上の例で返された"links"配列の
リンクがすべてHTTPSを使用している点にも注意されたい。これは、
WebFingerを通じて間接的に取得されるデータを安全に返す必要がある場合に
重要である。
4.4. JSON Resource Descriptor（JRD）
JSON Resource Descriptor（JRD）は、もともとRFC 6415
[16]で導入され、Extensible Resource Descriptor（XRD）形式
[17]に基づくものであり、次の名前/値ペアから構成されるJSON
オブジェクトである。
o subject
o aliases
o properties
o links
メンバー"subject"は値が文字列である名前/値ペアであり、
"aliases"は文字列の配列、"properties"は値が文字列である名前/値ペアで
構成されるオブジェクト、"links"はリンク関係情報を含むオブジェクトの
配列である。
JRDを処理する際、クライアントは未知のメンバーを無視しなければならず
（MUST）、未知のメンバーが存在することをエラーとして扱ってはならない。
以下では、JRDのこれら各メンバーについて、より詳しく説明する。
4.4.1. subject
"subject"メンバーの値は、JRDが記述するエンティティを識別するURIである。
WebFingerリソースによって返される"subject"値は、クライアントの要求で
使用された"resource"パラメーターの値と異なっていてもよい（MAY）。
これは、たとえばsubjectのアイデンティティが変更された場合
（例：ユーザーが自分のアカウントを別のサービスへ移した場合）や、
リソースがURIを正規形式で表現することを好む場合に起こり得る。
"subject"メンバーはJRD内に存在すべきである（SHOULD）。
4.4.2. aliases
"aliases"配列は、"subject" URIと同じエンティティを識別する、
0個以上のURI文字列の配列である。
"aliases"配列はJRD内では任意である（OPTIONAL）。
Jones, et al. Standards Track [Page 11]
RFC 7033 WebFinger September 2013
4.4.3. properties
"properties"オブジェクトは、名前がURI（"property identifiers"と
呼ばれる）であり、値が文字列またはnullである0個以上の名前/値ペアで
構成される。プロパティは、JRDのsubjectに関する追加情報を伝えるために
使用される。例として、次の"properties"の使用を考える。
"properties" : { "http://webfinger.example/ns/name" : "Bob Smith" }
"properties"メンバーはJRD内では任意である（OPTIONAL）。
4.4.4. links
"links"配列は任意の数のメンバーオブジェクトを持ち、それぞれが
リンク [4]を表す。これらの各リンクオブジェクトは、次の
メンバーを持つことができる。
o rel
o type
o href
o titles
o properties
"rel"および"href"メンバーは、それぞれリンクの関係型および対象URIを
表す文字列である。リンクのコンテキストは"subject"である
（Section 4.4.1を参照）。
"type"メンバーは、リンクを逆参照した結果のメディア型が何であるべきかを
示す文字列である。
"links"配列内の要素の順序は、優先順を示すものとして解釈されてもよい
（MAY）。したがって、同じ"rel"値を持つリンク関係が2つ以上ある場合、
最初のリンク関係がユーザーの優先リンクを示すことになる。
"links"配列はJRD内では任意である（OPTIONAL）。
以下では、"links"配列内にあるオブジェクトの各メンバーについて、
より詳しく説明する。"links"配列内の各オブジェクトは、
"link relation object"と呼ばれ、配列内の他のどのオブジェクトからも
完全に独立している。リンク関係オブジェクトに所定のメンバーを
含めるという要件は、その特定のオブジェクトのみに適用される。
Jones, et al. Standards Track [Page 12]
RFC 7033 WebFinger September 2013
4.4.4.1. rel
"rel"メンバーの値は、URIまたは登録済み関係型 [8]
（RFC 5988 [4]を参照）のいずれかである文字列である。
"rel"メンバーの値は、正確に1つのURIまたは登録済み関係型を
含まなければならない（MUST）。URIまたは登録済み関係型は、
リンク関係の種類を識別する。
オブジェクトの他のメンバーは、リンク関係の種類が理解されて初めて
意味を持つ。場合によっては、リンク関係には、クライアントが
インターネット上の他のリソースを照会できるようにする関連セマンティクスが
ある。別の場合には、リンク関係には、追加の外部リソースを取得せずに
クライアントがリンク関係オブジェクトの他のメンバーを利用できるようにする
関連セマンティクスがある。
URIリンク関係型の値は、RFC 3986のセクション 6.2.1の
"Simple String Comparison"アルゴリズムを用いて比較される。
"rel"メンバーはリンク関係オブジェクト内に存在しなければならない（MUST）。
4.4.4.2. type
"type"メンバーの値は、ターゲットリソースのメディア型 [9]
（RFC 6838 [10]を参照）を示す文字列である。
"type"メンバーはリンク関係オブジェクト内では任意である（OPTIONAL）。
4.4.4.3. href
"href"メンバーの値は、ターゲットリソースを指すURIを含む文字列である。
"href"メンバーはリンク関係オブジェクト内では任意である（OPTIONAL）。
4.4.4.4. titles
"titles"オブジェクトは、名前が言語タグ [11] または
文字列"und"である0個以上の名前/値ペアで構成される。この文字列は
人間が読めるものであり、リンク関係を記述する。リンク関係を利用する
ユーザーの便宜のため、リンク関係に複数のタイトルを提供してもよく（MAY）、
使用する場合は、名前として言語識別子を適切に使用すべきである（SHOULD）。
言語が不明または未指定である場合、名前は"und"である。
JRDは、リンク関係オブジェクト内で同じ言語タグ（または"und"）によって
識別されるタイトルを複数含めるべきではない（SHOULD NOT）。リンク関係
オブジェクトが同じ言語タグ（または"und"）で名付けられたタイトルを複数
Jones, et al. Standards Track [Page 13]
RFC 7033 WebFinger September 2013
含む場合の意味は未定義であるが、これはエラーとして扱ってはならない
（MUST NOT）。クライアントは、利用したい任意のタイトルを選択してもよい
（MAY）。
以下は"titles"オブジェクトの例である。
"titles" :
{
"en-us" : "The Magical World of Steve",
"fr" : "Le Monde Magique de Steve"
}
"titles"メンバーはリンク関係オブジェクト内では任意である（OPTIONAL）。
4.4.4.5. properties
リンク関係オブジェクト内の"properties"オブジェクトは、名前がURI
（"property identifiers"と呼ばれる）であり、値が文字列またはnullである
0個以上の名前/値ペアで構成される。プロパティは、リンク関係に関する
追加情報を伝えるために使用される。例として、次の"properties"の使用を
考える。
"properties" : { "http://webfinger.example/mail/port" : "993" }
"properties"メンバーはリンク関係オブジェクト内では任意である（OPTIONAL）。
4.5. WebFingerとURI
WebFinger要求には、クライアントが情報を要求するクエリ対象（URI）を
指定する"resource"パラメーター（Section 4.1を参照）が含まれる。
WebFingerは、このようなURIのスキームに関して中立である。それは
"acct" URI [18]、"http"または"https" URI、
"mailto" URI [19]、またはその他のスキームであり得る。
5. Cross-Origin Resource Sharing（CORS）
WebFingerリソースは、"Same-Origin"ポリシーによりWebブラウザーから
アクセスできない場合がある。現在のベストプラクティスは、
Cross-Origin Resource Sharing（CORS）[7]を通じてリソースを
ブラウザーに利用可能にすることであり、サーバーは応答に
Access-Control-Allow-Origin HTTPヘッダーを含めなければならない（MUST）。
サーバーは、任意のドメインからWebFingerリソースへのアクセスを許可することで、
最も制限の少ない設定をサポートすべきである（SHOULD）。
Access-Control-Allow-Origin: *
Jones, et al. Standards Track [Page 14]
RFC 7033 WebFinger September 2013
最も制限の少ない設定を既定にすることが適切でない場合もある。たとえば、
機密性の高い企業情報を提供するイントラネット上のサーバーは、任意の
ドメインからのCORS要求を許可すべきではない（SHOULD NOT）。それにより、
その機密情報の漏えいが可能になる可能性があるためである。外部エンティティからの
情報へのアクセスを制限したいサーバーは、より制限的な
Access-Control-Allow-Originヘッダーを使用すべきである（SHOULD）。
6. アクセス制御
すべてのWebリソースと同様に、WebFingerリソースへのアクセスには
認証が必要となる場合がある。さらに、必要な資格情報を提供しなかった場合、
サーバーがアクセスを禁止する、またはクライアントがサーバーで認証していた場合とは
異なる応答を提供する結果となることがある。
同様に、WebFingerリソースは、クライアントが企業ネットワークの内側にいるか
外側にいるかなど、他の要因に基づいて、異なるクライアントに対して異なる応答を
提供してもよい（MAY）。具体例として、社内企業ネットワーク上で実行された
クエリは従業員写真へのリンク関係を返す可能性がある一方で、従業員写真への
リンク関係は外部エンティティには提供されない可能性がある。
さらに、WebFingerリソース表現で提供されるリンク関係は、アクセス制限を課す
Webリソースを指している場合がある。たとえば、前述の企業サーバーは、
社内および外部の両方のエンティティに従業員写真へのURIを提供することが
あるが、要求が企業ネットワークの外部から来る場合、クライアントが写真リソースに
アクセスするには追加の認証が必要となることがある。
WebFingerリソースがあるクライアントと別のクライアントに対してどの
リンク関係の集合を提供するか、どのリソースが追加認証を必要とするか、
および採用される具体的な認証機構に関する決定は、この文書の範囲外である。
7. ホスト型WebFingerサービス
インターネット上で提供されるほとんどのサービスと同様に、ドメイン所有者が
「ホスト型」WebFingerサービスを利用することは可能である。例として、
ドメイン所有者は自分のドメインの大部分の側面を制御しているが、電子メールには
サードパーティのホスティングサービスを使用している場合がある。電子メールの場合、
mail exchange（MX）レコードはドメインのメールサーバーを識別する。MXレコードは、
そのドメイン宛てのメールが配信されるべきメールサーバーを指す。送信サーバーに
とって、それらのMXレコードが宛先ドメイン内のサーバーを指しているか、
別のドメインを指しているかは問題ではない。
Jones, et al. Standards Track [Page 15]
RFC 7033 WebFinger September 2013
同様に、ドメイン所有者は、自分のユーザーに代わってWebFingerサービスを
提供するために第三者のサービスを利用することがある。ドメイン所有者が
ホスト型電子メールサービスを可能にするためDNSにMXレコードを挿入する必要が
あるのと同様に、ドメイン所有者は、ホスト型WebFingerサービスを可能にするため、
自分のドメインへのHTTPクエリをリダイレクトする必要がある。
WebFingerリソースにクエリが発行された場合、Webサーバーは、
ホスト型WebFingerサービスURIの場所を指すLocationヘッダーを含む
リダイレクトステータスコードの応答を返さなければならない（MUST）。
このWebFingerサービスURIは、ホスティングサービスプロバイダーのサーバー上の
well-known WebFingerロケーションを指している必要はない。
例として、example.comのWebFingerサービスがwf.example.netによって
ホストされていると仮定する。クライアントが次のように
acct:alice@example.comについてクエリを発行するとする。
GET /.well-known/webfinger?
resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
サーバーは次のように応答することがある。
HTTP/1.1 307 Temporary Redirect
Access-Control-Allow-Origin: *
Location: https://wf.example.net/example.com/webfinger?
resource=acct%3Aalice%40example.com
その後、クライアントはリダイレクトに従い、Locationヘッダーで提供された
URIに対して要求を再発行できる。なお、サーバーはLocationヘッダー値に
必要なURIパラメーターを含めることになり、これはクライアントが最初に使用した
URIパラメーターとは異なる場合がある。
8. WebFingerアプリケーションの定義
この仕様は、URIに関する情報についてドメインを照会するために使用される
プロトコル構文、そのクエリへの応答として返されるJSON Resource
Descriptor（JRD）の構文、セキュリティ要件および考慮事項、
ホスト型WebFingerサービス、想定される各種HTTPステータスコードなどを
詳述する。しかし、この仕様は、特定のアプリケーションについてWebFingerと
組み合わせて使用され得るさまざまな可能なプロパティやリンク関係型を列挙せず、
また、特定のURIまたはURIスキームについて照会した場合にどのプロパティや
リンク関係型が返されることを期待できるかも定義しない。それでもなお、
これらの未指定の要素はすべて、WebFingerプロトコルを利用する相互運用可能な
アプリケーションを実装するために重要であり、
Jones, et al. Standards Track [Page 16]
RFC 7033 WebFinger September 2013
このセクションで説明する手続きに従って、WebFingerプロトコルを利用する
特定のアプリケーションを定義する関連文書で指定されなければならない（MUST）。
8.1. URIスキームおよびURIの仕様
WebFingerを使用する任意のアプリケーションは、URIスキームを指定し、
適切な範囲で、そのURIがどのような形式を取り得るかを指定しなければならない
（MUST）。たとえば、あるドメインにおけるユーザーのアカウントに関する情報を
照会する場合、"acct" URIスキーム [18]の使用を指定することが
理にかなう場合がある。Webページの著作権情報を取得しようとする場合は、
WebページURI（httpまたはhttps）の使用を指定することが理にかなう。
Sections 3.1および3.2の例は、WebFingerアプリケーションで
異なるURIスキームを使用する例を示している。Section
3.1の例では、WebFingerはOpenID Connectに関連する情報を取得するために
使用される。Section 3.2の例では、WebFingerは、著者および
著作権情報を含む、Webページに関するメタデータ情報を発見するために
使用される。これらのWebFingerアプリケーションはそれぞれ、相互運用性を
確保するために完全に指定される必要がある。
8.2. ホスト解決
Section 4で説明したように、WebFingerクエリが発行されるホストは
重要である。一般に、WebFingerアプリケーションは、WebFingerクエリを
適切に送信するために、Section 4で説明された手続きに従うことになる。
しかし、一部のURIスキームにはホスト部分がなく、URIのホスト部分を
利用できない、または利用すべきでないWebFingerのアプリケーションが
存在する可能性がある。そのような場合、アプリケーション仕様は、
クエリの送信先となる「デフォルト」ホストをクライアント内に
プロビジョニングすることを含み得るホスト解決手続きを、明確に定義しなければ
ならない（MUST）。
8.3. プロパティの仕様
WebFingerは、subject固有のプロパティ（すなわち、情報が照会されるURIに
関連する、Section 4.4.3で説明されるプロパティ）と、リンク固有の
プロパティ（Section
4.4.4.5を参照）の両方を定義する。このセクションは
subject固有のプロパティを指す。
subject固有のプロパティを利用するアプリケーションは、それらの
プロパティを識別するために使用されるURIを、有効なプロパティ値とともに
定義しなければならない（MUST）。
Jones, et al. Standards Track [Page 17]
RFC 7033 WebFinger September 2013
Section 3.2の例にあるJRDのこの部分を考える。
"properties" :
{
"http://blgx.example.net/ns/version" : "1.3",
"http://blgx.example.net/ns/ext" : null
}
ここでは、WebFinger応答で2つのプロパティが返されている。これらは
それぞれ、WebFingerアプリケーション仕様で定義されることになる。
これら2つのプロパティは、同じWebFingerアプリケーション仕様で
定義される場合もあれば、異なる仕様で別々に定義される場合もある。
後者が可能であるため、特定のWebFingerアプリケーション仕様で何らかの関係が
明示的に定義されていない限り、WebFingerクライアントがあるプロパティと
別のプロパティとの間に何らかの特定の関係があると仮定しないことが重要である。
8.4. リンクの仕様
WebFinger応答で返されるリンクは、それぞれ複数の情報片で構成され、
その一部は任意である（Section
4.4.4を参照）。WebFingerアプリケーション仕様は、
各リンクと、リンクに関連付けられる任意の値を定義しなければならない（MUST）。
これには、リンク関係型（"rel"）、期待されるメディア型（"type"）、
プロパティ、およびタイトルが含まれる。
リンクが参照するターゲットURI（すなわち"href"）が存在する場合、
通常はアプリケーション仕様で指定されない。しかし、URIスキームまたは
URIの特別な特性は通常指定される。特定のリンクが外部参照を必要としない
場合、そのリンクの使用に関連するすべてのセマンティクスは、アプリケーション仕様内で
定義されなければならない（MUST）。そのようなリンクは、意味を伝えるために
リンク内のプロパティまたはタイトルのみに依存する場合がある。
8.5. 1つのURI、複数のアプリケーション
異なるWebFingerアプリケーションが同じURIスキーム、実質的には同じURIを
異なる目的で使用することを指定する可能性があるという事実に注意することが
重要である。それは問題にならないはずである。なぜなら、property identifier
（Sections 4.4.3および4.4.4.5を参照）とリンク関係型はそれぞれ、
特定のアプリケーションに対して一意に定義されるためである。
クライアントが特定のURIに関する情報を要求し、複数の異なる
property identifierまたはリンク関係型を含む応答を受け取る場合、その応答は
特定のセマンティクスなしにURIに関する情報を提供していることに
注意すべきである。
Jones, et al. Standards Track [Page 18]
RFC 7033 WebFinger September 2013
クライアントがその情報をどのように解釈するかは、クライアントが
実装する特定のアプリケーション仕様または仕様群に従うべきである（SHOULD）。
クライアントが受け取る構文的に有効なプロパティまたはリンクのうち、
完全には理解されないものは、無視されるべきであり（SHOULD）、クライアントが
エラーを報告する原因となるべきではない（SHOULD NOT）。
8.6. リンク関係型およびプロパティの登録
アプリケーション仕様は、リンクのリンク関係型として単純なトークンを
定義してもよい（MAY）。その場合、リンク関係型はSections 10.3で
指定されるように、IANAに登録されなければならない（MUST）。
さらに、定義されたすべてのプロパティは、Section 10.4で
説明されるように、IANAに登録されなければならない（MUST）。
9. セキュリティ上の考慮事項
9.1. トランスポート関連の問題
この仕様はCross-Origin Resource Sharing（CORS）[7]を利用するため、
CORSに適用されるすべてのセキュリティ上の考慮事項は、この仕様にも
適用される。
転送中に情報が変更されないことを確保するため、HTTPSの使用が必要である
（REQUIRED）。Webサーバーが通常利用可能な環境では、侵害されたネットワークが
HTTPS上で動作しているWebFingerリソースを、HTTPのみで動作するものに
置き換える可能性が存在することを認識すべきである。したがって、クライアントは
非セキュアな接続上でクエリを発行してはならない（MUST NOT）。
クライアントは、HTTPS接続で使用される証明書が（[12]で定義されるように）
有効であることを検証しなければならず（MUST）、証明書が有効な場合にのみ
応答を受け入れなければならない。
9.2. ユーザーのプライバシーに関する考慮事項
サービスプロバイダーとユーザーは、インターネット上に情報を置くことは、
任意のユーザーがその情報にアクセスできることを意味し、WebFingerはその情報を
発見することをさらに容易にし得ることを認識すべきである。WebFingerは、
自分のアバター、ブログ、またはその他の個人データを発見するための非常に有用な
ツールになり得る一方で、ユーザーはリスクも理解すべきである。
Jones, et al. Standards Track [Page 19]
RFC 7033 WebFinger September 2013
WebFingerを通じて個人データを公開するシステムまたはサービスは、
ユーザーがWebFingerインターフェースを通じて公開されるデータ要素を
選択できるインターフェースを提供しなければならない（MUST）。たとえば、
ソーシャルネットワーキングサイトは、ユーザーが特定のデータを「公開」と
マークできるようにし、そのマークをWebFingerを通じてどの情報を公開するかを
判断する手段として利用する場合がある。したがって、WebFingerを通じて公開される
情報は、ユーザーによって公開とマークされた情報のみで構成されることになる。
さらに、ユーザーはこのマークを削除することにより、WebFingerを通じた公開から
情報を削除できる。
関連するサービスによってWebFingerを通じてそのデータを公開することが、
情報を共有される本人によって明示的に許可されていない限り、WebFingerは
いかなる個人データも提供するために使用されてはならない（MUST NOT）。
インターネット上のアクセス制御された環境またはその他の制限された環境内で
自分の個人データを公開することは、そのデータをWebFingerを通じてさらに公開する
ことへの黙示的な許可を提供することと同等ではない。
WebFingerを通じて個人データを公開することに伴うプライバシーおよび
セキュリティ上の懸念は、ユーザーの現在のコンテキスト（例：ユーザーの位置）を
明らかにし得る個人データに関して、改めて強調する価値がある。WebFingerの力は、
他者が人に関する情報へのポインターを見つけられる単一の場所を提供することに
由来するが、サービスプロバイダーとユーザーは、共有される情報の性質と、それが
全世界から見える可能性があるという事実に注意すべきである。たとえば位置情報を
共有すると、その人に危害を加えようとする任意の個人によって、その人が危険に
さらされる可能性がある。
ユーザーは、自分が公開する可能性のある個人データが、意図しない方法で
どれほど容易に使用され得るかを認識すべきである。WebFingerに類似した
サービスに関連するある研究で、Balduzzi et al. [20]は、
漏えいした大量の電子メールアドレスを用い、複数のソーシャルネットワークに
わたって同一ユーザーのアカウントを相互関連付けできることを含む、多くの
潜在的なプライバシー上の懸念を実証した。著者らは、潜在的な緩和戦略も
説明している。
WebFingerを通じてユーザー情報へ容易にアクセスできることは、このプロトコルの
設計目標であり、制限ではない。企業ネットワーク内で使用するWebFingerリソースなど、
WebFingerを通じて利用可能な情報へのアクセスを制限したい場合、ネットワーク管理者は
ネットワーク外部からのアクセスを制限するために必要な措置を講じる必要がある。
Webリソースを保護するための標準的な方法を使用することで、ネットワーク管理者は
機密情報を返す可能性のあるリソースへのアクセスを制御する能力を持つ。さらに、
認証を要求し、許可されていないエンティティへの情報開示を防ぐようにサーバーを
採用することができる。
Jones, et al. Standards Track [Page 20]
RFC 7033 WebFinger September 2013
9.3. 悪用の可能性
サービスプロバイダーは、WebFingerを用いた悪用の可能性に注意すべきである。
1つの例として、あるURIが有効かどうかを発見する目的だけでWebFingerサーバーを
照会することが考えられる。このようなクエリにより、その人物は、たとえば
電子メール識別子が有効であると推測できる。このような手法は、スパマーが既知の
電子メールアドレスの最新リストを維持し、新しいアドレスを発見する助けとなり得る。
WebFingerは、名前またはその他の個人データを電子メールアドレスと関連付けるために
使用される可能性があり、それによりスパマーがより説得力のある電子メールメッセージを
作成できる。これはフィッシングの試みにおいて特に価値がある可能性がある。
WebFingerサーバーソフトウェアの実装者は、サーバーの悪意ある過剰利用や
ユーザー情報の収集を含む悪用を緩和するための措置を講じることが推奨される
（RECOMMENDED）。公開アクセス可能なWebFingerデータベースが収集されないことを
保証できる機構は存在しないが、IPアドレスによるレート制限は、ボットネットや
その他の分散システムにアクセスできない個人による収集を防止するか、少なくとも
大幅に遅らせる。このような緩和戦略が必須ではない理由は、正しい緩和戦略の選択
（もしあれば）が文脈に大きく依存するためである。実装者はこれを、緩和戦略を
使用するかどうか、使用する場合はどの戦略を使用するかを検討する必要がないという
意味に解釈すべきではない。
WebFingerクライアント開発者も、スパマーやユーザーに関する情報をフィッシングする
者による潜在的な悪用を認識すべきである。例として、メールクライアントが受信した
各メールメッセージの送信者について自動的にWebFingerクエリを実行するように
構成されていたとする。スパマーが'From'ヘッダーに一意の識別子を使用して
電子メールを送信した場合、WebFingerクエリが実行されると、スパマーはその要求を
特定のユーザーの電子メールアドレスと関連付けることができる。これにより、
ユーザーのIPアドレス、ユーザーがちょうど電子メールを確認したという事実、
ユーザーが利用したWebFingerクライアントの種類などの情報がスパマーに提供される。
このため、ユーザーによってそうすることが許可されていない限り、クライアントは
WebFingerクエリを実行しないことが強く推奨される。
9.4. 情報の信頼性
WebFingerリソースには、ユーザーによって提供された情報が正確であることを
確保する手段がない。同様に、リソースもクライアントも、情報がサーバー側または
クライアントとサーバー間の通信経路上で操作されていないことを絶対的に保証することは
Jones, et al. Standards Track [Page 21]
RFC 7033 WebFinger September 2013
できない。HTTPSの使用は、通信経路上での情報の操作に関するいくつかの
懸念に対処する助けとなるが、虚偽の情報が提供されたこと、またはサーバー管理者の
悪意ある行動により、リソースが誤った情報を提供した場合の問題には明らかに
対処できない。インターネット上で利用可能なあらゆる情報サービスと同様に、
ユーザーは信頼できない情報源から受け取った情報に注意すべきである。
10. IANAに関する考慮事項
10.1. Well-Known URI
この仕様は、RFC 5785 [3]で定義される"Well-Known URIs"
レジストリに、"webfinger" well-known URIを登録する。
URI suffix: webfinger
Change controller: IETF
Specification document(s): RFC 7033
Related information: WebFingerリソースへのクエリは、クエリ文字列に
1つ以上のパラメーターを含む。RFC 7033のセクション 4.1を参照。
この場所のリソースは、RFC 7033のセクション 4.4で説明される
JSON Resource Descriptor（JRD）を返すことができる。
10.2. JSON Resource Descriptor（JRD）メディア型
この仕様は、RFC 6838 [10]で定義されるメディア型登録手続きに
従って、WebFingerで使用するためのメディア型application/jrd+jsonを登録する。
Type name: application
Subtype name: jrd+json
Required parameters: N/A
Optional parameters: N/A
特に、RFC 4627がすでにJSONの文字エンコーディングを定義しているため、
"charset"パラメーターは使用されない。
Encoding considerations: RFC 6839, Section 3.1を参照。
Jones, et al. Standards Track [Page 22]
RFC 7033 WebFinger September 2013
Security considerations:
JSON Resource Descriptor（JRD）はJavaScript Object Notation
（JSON）オブジェクトである。これはテキスト形式であり、この形式を利用したい
エンティティによって解析されなければならない。JSONオブジェクトを解析するために
使用される言語および機構によっては、攻撃者が実行中のプログラムに振る舞いを
注入できる可能性がある。したがって、受信したJRDを適切に解析し、有効な
JSONオブジェクトのみが存在し、JavaScriptやその他のコードが予期せず注入または
実行されないことを確保するよう注意しなければならない。
Interoperability considerations:
このメディア型はJavaScript Object Notation（JSON）オブジェクトであり、
JSONオブジェクトを利用できる任意のソフトウェアアプリケーションによって
利用できる。
Published specification: RFC 7033
Applications that use this media type:
JSON Resource Descriptor（JRD）は、WebFingerプロトコル（RFC 7033）により、
HTTPS上でクライアントとWebFingerリソースとの間の情報交換を可能にするために
使用される。
Fragment identifier considerations:
フラグメント識別子の構文およびセマンティクスは、"application/json"に
指定されているものとすべきである（SHOULD）。（この文書の公開時点では、
"application/json"に対して定義されたフラグメント識別構文は存在しない。）
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): jrd
Macintosh file type code(s): N/A
Person & email address to contact for further information:
Paul E. Jones <paulej@packetizer.com>
Intended usage: COMMON
Jones, et al. Standards Track [Page 23]
RFC 7033 WebFinger September 2013
Restrictions on usage: N/A
Author: Paul E. Jones <paulej@packetizer.com>
Change controller:
IESGはこの登録に対する変更管理権限を持つ。
Provisional registration? (standards tree only): N/A
10.3. リンク関係型の登録
RFC 5988は、WebFingerアプリケーションによって再利用される
"Link Relation Types"レジストリを設立した。
WebFingerアプリケーションで使用されるリンク関係型は、RFC 5988の
セクション 6.2.1の手続きに従い、"Link Relation Types"
レジストリに登録される。登録の"Notes"項目は、リンク関係型に関連付けられた
プロパティ値が"WebFinger Properties"レジストリに登録されている場合、
そのレジストリへのリンクとともに示すべきである（SHOULD）。
10.4. "WebFinger Properties"レジストリの設立
WebFingerは、subjectまたはリンクのプロパティおよび関連する値を識別するために
URIを利用する（Sections 8.3および8.6を参照）。この仕様は、
property identifierを記録するための新しい"WebFinger Properties"レジストリを
設立する。
10.4.1. 登録テンプレート
WebFingerプロパティの登録テンプレートは次のとおりである。
o Property Identifier:
o Link Type:
o Description:
o Reference:
o Notes: [optional]
"Property Identifier"は、登録されるプロパティを識別するURIでなければならない。
Jones, et al. Standards Track [Page 24]
RFC 7033 WebFinger September 2013
"Link Type"には、このproperty identifierが使用されるリンク関係型の名前を
含める。プロパティがsubject固有のプロパティである場合、このフィールドは
"N/A"として指定される。
"Description"は、プロパティの目的を説明することを意図している。
"Reference"フィールドは、登録されるプロパティを定義する仕様を指す。
任意の"Notes"フィールドは、実装者にとって価値があり得る、プロパティに関する
有用な情報を伝えるためのものである。
10.4.2. 登録手続き
IETFはwebfinger@ietf.orgというメーリングリストを作成しており、これは
WebFingerプロトコルおよびそれを使用する任意のアプリケーションについての
公開討議に使用できる。WebFingerプロパティの登録に先立ち、メーリングリストでの
討議が強く推奨される。IESGはDesignated Experts [13]を任命しており、
彼らはwebfinger@ietf.orgメーリングリストを監視し、登録をレビューする。
WebFingerプロパティは、Designated Expertsによるレビューの後、Specification
Required（RFC 5226 [13]を参照）として登録される。レビューは通常、
おおむね2週間から4週間程度かかると想定される。しかし、Designated Expertsは、
そのような仕様が公開されると納得した場合、仕様の公開に先立って登録を承認する
ことがある。登録要求を評価する際、Designated Expertsは、同じ意味を持つ2つの
異なるプロパティが登録されることを避けるよう努めるべきである。提案された
プロパティが既に定義されたプロパティに類似している場合、Designated Expertsは、
新しいプロパティを既存のものから十分に区別するために、テンプレートのdescriptionまたは
notesセクションに十分なテキストが含まれるよう求めるべきである。
登録手続きは、上記で定義された完成済み登録テンプレートをwebfinger@ietf.orgに
送信することから始まる。メーリングリストで合意に達すると、登録テンプレートは
iana@iana.orgに送信される。その後、IANAはDesignated Expertsに連絡し、
結果を登録者に伝える。WebFingerメーリングリストは、コミュニティによる討議と
入力の機会を提供し、Designated Expertsはその入力をレビューに役立てることがある。
拒否には説明を含めるべきであり、該当する場合は、再提出時に要求を成功させる方法に
ついての提案も含めるべきである。
Jones, et al. Standards Track [Page 25]
RFC 7033 WebFinger September 2013
WebFingerプロパティを登録する仕様は、上に示した完成済み登録テンプレートを
含まなければならない（MUST）。登録手続きが正常に完了すると、IANAは
"WebFinger Properties"レジストリ内の対応するレコードを作成または変更する。
11. 謝辞
この文書は、APPSAWGワーキンググループの多くのメンバーによる広範な討議と
レビューの恩恵を受けた。著者らは、Eran Hammer-Lahav、Blaine Cook、
Brad Fitzpatrick、Laurent-Walter Goix、Joe Clarke、Peter Saint-Andre、
Dick Hardt、Tim Bray、James Snell、Melvin Carvalho、Evan Prodromou、
Mark Nottingham、Elf Pavlik、Bjoern Hoehrmann、Subramanian Moonesamy、
Joe Gregorio、John Bradley、および、間違いなく存在するものの意図せず
漏れてしまったその他の方々からの貴重な意見に、特に感謝したい。
著者らはまた、APPSAWGワーキンググループの議長、とりわけこの文書の
shepherdingにおける支援についてSalvatore Loretoに感謝の意を表したい。
また、Applications Area DirectorsであるBarry LeibaおよびPete Resnickの
支援と徹底的なレビューにも感謝したい。
12. 参考文献
12.1. 規範的参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999.
[3] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[4] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[5] Crockford, D., "The application/json Media Type for JavaScript
Object Notation (JSON)", RFC 4627, July 2006.
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[7] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS,
July 2010, <http://www.w3.org/TR/cors/>.
Jones, et al. Standards Track [Page 26]
RFC 7033 WebFinger September 2013
[8] IANA, "Link Relations",
<http://www.iana.org/assignments/link-relations/>.
[9] IANA, "MIME Media Types",
<http://www.iana.org/assignments/media-types>.
[10] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838,
January 2013.
[11] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. 参考情報
[14] Perreault, S., "vCard Format Specification", RFC 6350, August
2011.
[15] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0",
July 2013,
<http://openid.net/specs/openid-connect-messages-1_0.html>.
[16] Hammer-Lahav, E., Ed., and B. Cook, "Web Host Metadata", RFC
6415, October 2011.
[17] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor
(XRD) Version 1.0",
<http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html>.
[18] Saint-Andre, P., "The 'acct' URI Scheme", Work in Progress,
July 2013.
[19] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI
Scheme", RFC 6068, October 2010.
[20] Balduzzi, M., Platzer, C., Thorsten, H., Kirda, E., Balzarotti,
D., and C. Kruegel "Abusing Social Networks for Automated User
Profiling", Recent Advances in Intrusion Detection, Springer
Berlin Heidelberg, March 2010,
<https://www.eurecom.fr/en/publication/3042/download/
rs-publi-3042_1.pdf>.
Jones, et al. Standards Track [Page 27]
RFC 7033 WebFinger September 2013
著者の連絡先
Paul E. Jones
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 476 2048
EMail: paulej@packetizer.com
IM: xmpp:paulej@packetizer.com
Gonzalo Salgueiro
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 392 3266
EMail: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joseph Smarr
Google
EMail: jsmarr@google.com
URI: http://josephsmarr.com/
Jones, et al. Standards Track [Page 28]