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
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
网手指
Abstract
摘要
This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.
本规范定义了WebFinger协议，该协议可用于使用标准HTTP方法发现有关Internet上人员或其他实体的信息。WebFinger发现可能无法用作定位器的URI信息，如帐户或电子邮件URI。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7033.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Example Uses of WebFinger .......................................4
3.1. Identity Provider Discovery for OpenID Connect .............4
3.2. Getting Author and Copyright Information for a Web Page ....5
4. WebFinger Protocol ..............................................7
4.1. Constructing the Query Component of the Request URI.......7
4.2. Performing a WebFinger Query..............................8
4.3. The "rel" Parameter.......................................9
4.4. The 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 and URIs.......................................14
5. Cross-Origin Resource Sharing (CORS) ...........................14
6. Access Control .................................................15
7. Hosted WebFinger Services ......................................15
8. Definition of WebFinger Applications ...........................16
8.1. Specification of the URI Scheme and URI ...................17
8.2. Host Resolution ...........................................17
8.3. Specification of Properties ...............................17
8.4. Specification of Links ....................................18
8.5. One URI, Multiple Applications ............................18
8.6. Registration of Link Relation Types and Properties ........19
9. Security Considerations ........................................19
9.1. Transport-Related Issues ..................................19
9.2. User Privacy Considerations ...............................19
9.3. Abuse Potential ...........................................21
9.4. Information Reliability ...................................21
10. IANA Considerations ...........................................22
10.1. Well-Known URI ...........................................22
10.2. JSON Resource Descriptor (JRD) Media Type ................22
10.3. Registering Link Relation Types ..........................24
10.4. Establishment of the "WebFinger Properties" Registry .....24
10.4.1. The Registration Template .........................24
10.4.2. The Registration Procedures .......................25
11. Acknowledgments ...............................................26
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................27
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Example Uses of WebFinger .......................................4
3.1. Identity Provider Discovery for OpenID Connect .............4
3.2. Getting Author and Copyright Information for a Web Page ....5
4. WebFinger Protocol ..............................................7
4.1. Constructing the Query Component of the Request URI.......7
4.2. Performing a WebFinger Query..............................8
4.3. The "rel" Parameter.......................................9
4.4. The 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 and URIs.......................................14
5. Cross-Origin Resource Sharing (CORS) ...........................14
6. Access Control .................................................15
7. Hosted WebFinger Services ......................................15
8. Definition of WebFinger Applications ...........................16
8.1. Specification of the URI Scheme and URI ...................17
8.2. Host Resolution ...........................................17
8.3. Specification of Properties ...............................17
8.4. Specification of Links ....................................18
8.5. One URI, Multiple Applications ............................18
8.6. Registration of Link Relation Types and Properties ........19
9. Security Considerations ........................................19
9.1. Transport-Related Issues ..................................19
9.2. User Privacy Considerations ...............................19
9.3. Abuse Potential ...........................................21
9.4. Information Reliability ...................................21
10. IANA Considerations ...........................................22
10.1. Well-Known URI ...........................................22
10.2. JSON Resource Descriptor (JRD) Media Type ................22
10.3. Registering Link Relation Types ..........................24
10.4. Establishment of the "WebFinger Properties" Registry .....24
10.4.1. The Registration Template .........................24
10.4.2. The Registration Procedures .......................25
11. Acknowledgments ...............................................26
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................27
WebFinger is used to discover information about people or other entities on the Internet that are identified by a URI [6] using standard Hypertext Transfer Protocol (HTTP) [2] methods over a secure transport [12]. A WebFinger resource returns a JavaScript Object Notation (JSON) [5] object describing the entity that is queried. The JSON object is referred to as the JSON Resource Descriptor (JRD).
WebFinger用于通过安全传输[12]，使用标准超文本传输协议（HTTP）[2]方法，发现由URI[6]标识的互联网上的人或其他实体的信息。WebFinger资源返回描述所查询实体的JavaScript对象表示法（JSON）[5]对象。JSON对象称为JSON资源描述符（JRD）。
For a person, the type of information that might be discoverable via WebFinger includes a personal profile address, identity service, telephone number, or preferred avatar. For other entities on the Internet, a WebFinger resource might return JRDs containing link relations [8] that enable a client to discover, for example, that a printer can print in color on A4 paper, the physical location of a server, or other static information.
对于个人而言，可通过WebFinger发现的信息类型包括个人简档地址、身份服务、电话号码或首选化身。对于Internet上的其他实体，WebFinger资源可能返回包含链接关系[8]的JRD，该链接关系使客户端能够发现，例如，打印机可以在A4纸张上以彩色打印、服务器的物理位置或其他静态信息。
Information returned via WebFinger might be for direct human consumption (e.g., looking up someone's phone number), or it might be used by systems to help carry out some operation (e.g., facilitating, with additional security mechanisms, logging into a web site by determining a user's identity service). The information is intended to be static in nature, and, as such, WebFinger is not intended to be used to return dynamic information like the temperature of a CPU or the current toner level in a laser printer.
通过WebFinger返回的信息可能是供人类直接使用的（例如，查找某人的电话号码），也可能被系统用于帮助执行某些操作（例如，通过附加的安全机制，通过确定用户的身份服务来帮助登录网站）。该信息本质上是静态的，因此，WebFinger不用于返回动态信息，如CPU的温度或激光打印机中的当前碳粉水平。
The WebFinger protocol is designed to be used across many applications. Applications that wish to utilize WebFinger will need to specify properties, titles, and link relation types that are appropriate for the application. Further, applications will need to define the appropriate URI scheme to utilize for the query target.
WebFinger协议设计用于许多应用程序。希望使用WebFinger的应用程序需要指定适合该应用程序的属性、标题和链接关系类型。此外，应用程序将需要定义适当的URI方案以用于查询目标。
Use of WebFinger is illustrated in the examples in Section 3 and described more formally in Section 4. Section 8 describes how applications of WebFinger may be defined.
WebFinger的使用在第3节的示例中进行了说明，并在第4节中进行了更正式的描述。第8节描述了如何定义WebFinger的应用程序。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
WebFinger makes heavy use of "link relations". A link relation is an attribute-value pair in which the attribute identifies the type of relationship between the linked entity or resource and the information specified in the value. In Web Linking [4], the link relation is represented using an HTTP entity-header of "Link", where the "rel" attribute specifies the type of relationship and the "href"
WebFinger大量使用“链接关系”。链接关系是一种属性-值对，其中属性标识链接实体或资源与值中指定的信息之间的关系类型。在Web链接[4]中，链接关系使用HTTP实体标题“link”表示，其中“rel”属性指定关系类型和“href”
attribute specifies the information that is linked to the entity or resource. In WebFinger, the same concept is represented using a JSON array of "links" objects, where each member named "rel" specifies the type of relationship and each member named "href" specifies the information that is linked to the entity or resource. Note that WebFinger narrows the scope of a link relation beyond what is defined for Web Linking by stipulating that the value of the "rel" member needs to be either a single IANA-registered link relation type [8] or a URI [6].
属性指定链接到实体或资源的信息。在WebFinger中，相同的概念使用“links”对象的JSON数组表示，其中每个名为“rel”的成员指定关系类型，每个名为“href”的成员指定链接到实体或资源的信息。请注意，WebFinger通过规定“rel”成员的值必须是单个IANA注册的链接关系类型[8]或URI[6]，将链接关系的范围缩小到Web链接定义之外。
The use of URIs throughout this document refers to URIs following the syntax specified in Section 3 of RFC 3986 [6]. Relative URIs, having syntax following that of Section 4.2 of RFC 3986, are not used with WebFinger.
本文件中使用的URI指的是遵循RFC 3986[6]第3节规定语法的URI。WebFinger不使用相对URI，其语法遵循RFC 3986第4.2节的语法。
This section shows a few sample uses of WebFinger. Any application of WebFinger would be specified outside of this document, as described in Section 8. The examples in this section should be simple enough to understand without having seen the formal specifications of the applications.
本节展示了WebFinger的一些示例用法。如第8节所述，WebFinger的任何应用将在本文件之外指定。本节中的示例应该足够简单，以便在没有看到应用程序的正式规范的情况下理解。
Suppose Carol wishes to authenticate with a web site she visits using OpenID Connect [15]. She would provide the web site with her OpenID Connect identifier, say carol@example.com. The visited web site would perform a WebFinger query looking for the OpenID Connect provider. Since the site is interested in only one particular link relation, the WebFinger resource might utilize the "rel" parameter as described in Section 4.3:
假设Carol希望使用OpenID Connect对她访问的网站进行身份验证[15]。她会向网站提供她的OpenID连接标识符，比如carol@example.com. 访问的网站将执行WebFinger查询，查找OpenID连接提供程序。由于站点只对一个特定链接关系感兴趣，WebFinger资源可能会使用第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
获得/.well-known/webfinger？resource=acct%3Acarol%40example.com&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2fisher-http/1.1主机：example.com
The server might respond like this:
服务器可能会这样响应：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
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"
}
]
}
{
"subject" : "acct:carol@example.com",
"links" :
[
{
"rel" : "http://openid.net/specs/connect/1.0/issuer",
"href" : "https://openid.example.com"
}
]
}
Since the "rel" parameter only serves to filter the link relations returned by the resource, other name/value pairs in the response, including any aliases or properties, would be returned. Also, since support for the "rel" parameter is not guaranteed, the client must not assume the "links" array will contain only the requested link relation.
由于“rel”参数仅用于过滤资源返回的链接关系，因此将返回响应中的其他名称/值对，包括任何别名或属性。此外，由于不保证对“rel”参数的支持，因此客户端不能假定“links”数组将只包含请求的链接关系。
Suppose an application is defined to retrieve metadata information about a web page URL, such as author and copyright information. To retrieve that information, the client can utilize WebFinger to issue a query for the specific URL. Suppose the URL of interest is http://blog.example.com/article/id/314. The client would issue a query similar to the following:
假设定义了一个应用程序来检索有关网页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
获得/.well-known/webfinger？resource=http%3A%2F%2Fblog.example.com%2Fid%2F314 http/1.1主机：blog.example.com
The server might then reply in this way:
然后，服务器可能会以以下方式答复：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json
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"
}
}
{
"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"
}
}
] }
] }
In the above example, we see that the server returned a list of aliases, properties, and links related to the subject URL. The links contain references to information for each link relation type. For the author link, the server provided a reference to the author's blog, along with a title for the blog in two languages. The server also returned a single property related to the author, indicating the author's role as editor of the blog.
在上面的示例中，我们看到服务器返回了与主题URL相关的别名、属性和链接的列表。链接包含对每种链接关系类型的信息的引用。对于作者链接，服务器提供了作者博客的参考，以及两种语言的博客标题。服务器还返回一个与作者相关的属性，表示作者作为博客编辑的角色。
It is worth noting that, while the server returned just two links in the "links" array in this example, a server might return any number of links when queried.
值得注意的是，在本例中，虽然服务器仅返回“links”数组中的两个链接，但在查询时，服务器可能返回任意数量的链接。
The WebFinger protocol is used to request information about an entity identified by a query target (a URI). The client can optionally specify one or more link relation types for which it would like to receive information.
WebFinger协议用于请求有关查询目标（URI）标识的实体的信息。客户机可以选择指定一个或多个要接收其信息的链接关系类型。
A WebFinger request is an HTTPS request to a WebFinger resource. A WebFinger resource is a well-known URI [3] using the HTTPS scheme constructed along with the required query target and optional link relation types. WebFinger resources MUST NOT be served with any other URI scheme (such as HTTP).
WebFinger请求是对WebFinger资源的HTTPS请求。WebFinger资源是一个众所周知的URI[3]，它使用HTTPS方案以及所需的查询目标和可选链接关系类型构建。WebFinger资源不得与任何其他URI方案（如HTTP）一起提供。
A WebFinger resource is always given a query target, which is another URI that identifies the entity whose information is sought. GET requests to a WebFinger resource convey the query target in the "resource" parameter of the WebFinger URI's query string; see Section 4.1 for details.
WebFinger资源始终提供一个查询目标，该目标是另一个URI，用于标识要查找其信息的实体。GET对WebFinger资源的请求在WebFinger URI的查询字符串的“resource”参数中传递查询目标；详见第4.1节。
The host to which a WebFinger query is issued is significant. If the query target contains a "host" portion (Section 3.2.2 of RFC 3986), then the host to which the WebFinger query is issued SHOULD be the same as the "host" portion of the query target, unless the client receives instructions through some out-of-band mechanism to send the query to another host. If the query target does not contain a "host" portion, then the client chooses a host to which it directs the query using additional information it has.
向其发出WebFinger查询的主机是重要的。如果查询目标包含“主机”部分（RFC 3986第3.2.2节），则向其发出WebFinger查询的主机应与查询目标的“主机”部分相同，除非客户端通过带外机制接收到将查询发送到另一台主机的指令。如果查询目标不包含“主机”部分，则客户机使用其拥有的其他信息选择将查询定向到的主机。
The path component of a WebFinger URI MUST be the well-known path "/.well-known/webfinger". A WebFinger URI MUST contain a query component that encodes the query target and optional link relation types as specified in Section 4.1.
WebFinger URI的路径组件必须是已知路径“/.well-known/WebFinger”。WebFinger URI必须包含对查询目标和可选链接关系类型进行编码的查询组件，如第4.1节所述。
The WebFinger resource returns a JSON Resource Descriptor (JRD) as the resource representation to convey information about an entity on the Internet. Also, the Cross-Origin Resource Sharing (CORS) [7] specification is utilized to facilitate queries made via a web browser.
WebFinger资源返回一个JSON资源描述符（JRD）作为资源表示，以传递有关Internet上实体的信息。此外，跨源资源共享（CORS）[7]规范用于促进通过web浏览器进行的查询。
A WebFinger URI MUST contain a query component (see Section 3.4 of RFC 3986). The query component MUST contain a "resource" parameter and MAY contain one or more "rel" parameters. The "resource"
WebFinger URI必须包含查询组件（请参阅RFC 3986的第3.4节）。查询组件必须包含“资源”参数，并且可以包含一个或多个“rel”参数。“资源”
parameter MUST contain the query target (URI), and the "rel" parameters MUST contain encoded link relation types according to the encoding described in this section.
参数必须包含查询目标（URI），“rel”参数必须包含根据本节所述编码的编码链接关系类型。
To construct the query component, the client performs the following steps. First, each parameter value is percent-encoded, as per Section 2.1 of RFC 3986. The encoding is done to conform to the query production in Section 3.4 of that specification, with the addition that any instances of the "=" and "&" characters within the parameter values are also percent-encoded. Next, the client constructs a string to be placed in the query component by concatenating the name of the first parameter together with an equal sign ("=") and the percent-encoded parameter value. For any subsequent parameters, the client appends an ampersand ("&") to the string, the name of the next parameter, an equal sign, and the parameter value. The client MUST NOT insert any spaces while constructing the string. The order in which the client places each attribute-value pair within the query component does not matter in the interpretation of the query component.
要构造查询组件，客户端将执行以下步骤。首先，根据RFC 3986第2.1节，对每个参数值进行百分比编码。进行编码是为了符合该规范第3.4节中的查询结果，此外，参数值中“=”和“&”字符的任何实例也进行了百分比编码。接下来，客户机通过将第一个参数的名称与等号（“=”）和百分比编码参数值连接在一起，来构造一个要放置在查询组件中的字符串。对于任何后续参数，客户机会在字符串、下一个参数的名称、等号和参数值后面附加一个符号（&）。客户端在构造字符串时不得插入任何空格。客户机在查询组件中放置每个属性值对的顺序在查询组件的解释中并不重要。
A WebFinger client issues a query using the GET method to the well-known [3] resource identified by the URI whose path component is "/.well-known/webfinger" and whose query component MUST include the "resource" parameter exactly once and set to the value of the URI for which information is being sought.
WebFinger客户端使用GET方法向URI标识的已知[3]资源发出查询，该URI的路径组件为“/.well-known/WebFinger”，其查询组件必须只包含“resource”参数一次，并设置为正在查找信息的URI的值。
If the "resource" parameter is absent or malformed, the WebFinger resource MUST indicate that the request is bad as per Section 10.4.1 of RFC 2616 [2].
如果“resource”参数不存在或格式不正确，则WebFinger资源必须根据RFC 2616[2]第10.4.1节的规定指出请求不正确。
If the "resource" parameter is a value for which the server has no information, the server MUST indicate that it was unable to match the request as per Section 10.4.5 of RFC 2616.
如果“resource”参数是一个服务器没有信息的值，则服务器必须根据RFC 2616第10.4.5节指示它无法匹配请求。
A client MUST query the WebFinger resource using HTTPS only. If the client determines that the resource has an invalid certificate, the resource returns a 4xx or 5xx status code, or if the HTTPS connection cannot be established for any reason, then the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP over a non-secure connection.
客户端必须仅使用HTTPS查询WebFinger资源。如果客户端确定资源具有无效证书，资源返回4xx或5xx状态代码，或者由于任何原因无法建立HTTPS连接，则客户端必须接受WebFinger查询已失败，并且不得尝试通过非安全连接使用HTTP重新发出WebFinger请求。
A WebFinger resource MUST return a JRD as the representation for the resource if the client requests no other supported format explicitly via the HTTP "Accept" header. The client MAY include the "Accept" header to indicate a desired representation; representations other than JRD might be defined in future specifications. The WebFinger
如果客户端没有通过HTTP“Accept”头明确请求其他支持的格式，WebFinger资源必须返回JRD作为资源的表示。客户机可包括“接受”标题以指示期望的表示；JRD以外的表示可能在将来的规范中定义。网手指
resource MUST silently ignore any requested representations that it does not understand or support. The media type used for the JSON Resource Descriptor (JRD) is "application/jrd+json" (see Section 10.2).
资源必须以静默方式忽略它不理解或不支持的任何请求的表示。JSON资源描述符（JRD）使用的媒体类型为“应用程序/JRD+JSON”（见第10.2节）。
The properties, titles, and link relation types returned by the server in a JRD might be varied and numerous. For example, the server might return information about a person's blog, vCard [14], avatar, OpenID Connect provider, RSS or ATOM feed, and so forth in a reply. Likewise, if a server has no information to provide, it might return a JRD with an empty "links" array or no "links" array.
服务器在JRD中返回的属性、标题和链接关系类型可能多种多样。例如，服务器可以在回复中返回关于某人的博客、vCard[14]、化身、OpenID连接提供商、RSS或ATOM提要等的信息。同样，如果服务器没有信息可提供，它可能会返回一个带有空“links”数组或没有“links”数组的JRD。
A WebFinger resource MAY redirect the client; if it does, the redirection MUST only be to an "https" URI and the client MUST perform certificate validation again when redirected.
WebFinger资源可以重定向客户端；如果是，则重定向必须仅指向“https”URI，并且客户端在重定向时必须再次执行证书验证。
A WebFinger resource can include cache validators in a response to enable conditional requests by the client and/or expiration times as per Section 13 of RFC 2616.
WebFinger资源可以在响应中包括缓存验证器，以根据RFC 2616第13节启用客户端的条件请求和/或到期时间。
When issuing a request to a WebFinger resource, the client MAY utilize the "rel" parameter to request only a subset of the information that would otherwise be returned without the "rel" parameter. When the "rel" parameter is used and accepted, only the link relation types that match the link relation type provided via the "rel" parameter are included in the array of links returned in the JRD. If there are no matching link relation types defined for the resource, the "links" array in the JRD will be either absent or empty. All other information present in a resource descriptor remains present, even when "rel" is employed.
当向WebFinger资源发出请求时，客户机可以利用“rel”参数仅请求信息的子集，否则将在不使用“rel”参数的情况下返回这些信息。当使用并接受“rel”参数时，只有与通过“rel”参数提供的链接关系类型匹配的链接关系类型才会包含在JRD中返回的链接数组中。如果没有为资源定义匹配的链接关系类型，JRD中的“链接”数组将不存在或为空。即使使用了“rel”，资源描述符中存在的所有其他信息仍然存在。
The "rel" parameter MAY be included multiple times in order to request multiple link relation types.
可以多次包括“rel”参数，以请求多种链接关系类型。
The purpose of the "rel" parameter is to return a subset of "link relation objects" (see Section 4.4.4) that would otherwise be returned in the resource descriptor. Use of the parameter might reduce processing requirements on either the client or server, and it might also reduce the bandwidth required to convey the partial resource descriptor, especially if there are numerous link relation values to convey for a given "resource" value. Note that if a client requests a particular link relation type for which the server has no information, the server MAY return a JRD with an empty "links" array or no "links" array.
“rel”参数的目的是返回“链接关系对象”的子集（参见第4.4.4节），否则将在资源描述符中返回该子集。使用该参数可能会减少客户机或服务器上的处理要求，还可能会减少传送部分资源描述符所需的带宽，特别是在给定“资源”值有许多链路关系值要传送的情况下。请注意，如果客户端请求服务器没有信息的特定链接关系类型，服务器可能会返回一个带有空“links”数组或无“links”数组的JRD。
WebFinger resources SHOULD support the "rel" parameter. If the resource does not support the "rel" parameter, it MUST ignore the parameter and process the request as if no "rel" parameter values were present.
WebFinger资源应该支持“rel”参数。如果资源不支持“rel”参数，它必须忽略该参数，并像不存在“rel”参数值一样处理请求。
The following example uses the "rel" parameter to request links for two link relation types:
以下示例使用“rel”参数为两种链接关系类型请求链接：
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
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
In this example, the client requests the link relations of type "http://webfinger.example/rel/profile-page" and "http://webfinger.example/rel/businesscard". The server then responds with a message like this:
在此示例中，客户端请求类型为“”的链接关系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
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"
}
]
}
{
"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"
}
]
}
As you can see in the response, the resource representation contains only the links of the types requested by the client and for which the server had information, but the other parts of the JRD are still present. Note also in the above example that the links returned in the "links" array all use HTTPS, which is important if the data indirectly obtained via WebFinger needs to be returned securely.
正如您在响应中所看到的，资源表示只包含客户端请求的类型的链接，并且服务器已经为其提供了信息，但是JRD的其他部分仍然存在。在上面的示例中还要注意，“links”数组中返回的链接都使用HTTPS，如果需要安全地返回通过WebFinger间接获得的数据，这一点很重要。
The JSON Resource Descriptor (JRD), originally introduced in RFC 6415 [16] and based on the Extensible Resource Descriptor (XRD) format [17], is a JSON object that comprises the following name/value pairs:
JSON资源描述符（JRD）最初在RFC 6415[16]中引入，基于可扩展资源描述符（XRD）格式[17]，是一个JSON对象，包含以下名称/值对：
o subject o aliases o properties o links
o 主题o别名o属性o链接
The member "subject" is a name/value pair whose value is a string, "aliases" is an array of strings, "properties" is an object comprising name/value pairs whose values are strings, and "links" is an array of objects that contain link relation information.
成员“subject”是值为字符串的名称/值对，“alias”是字符串数组，“properties”是由值为字符串的名称/值对组成的对象，“links”是包含链接关系信息的对象数组。
When processing a JRD, the client MUST ignore any unknown member and not treat the presence of an unknown member as an error.
在处理JRD时，客户端必须忽略任何未知成员，并且不能将未知成员的存在视为错误。
Below, each of these members of the JRD is described in more detail.
下面，将对JRD的每个成员进行更详细的描述。
The value of the "subject" member is a URI that identifies the entity that the JRD describes.
“subject”成员的值是一个URI，用于标识JRD描述的实体。
The "subject" value returned by a WebFinger resource MAY differ from the value of the "resource" parameter used in the client's request. This might happen, for example, when the subject's identity changes (e.g., a user moves his or her account to another service) or when the resource prefers to express URIs in canonical form.
WebFinger资源返回的“subject”值可能与客户端请求中使用的“resource”参数的值不同。例如，当主体的身份发生变化时（例如，用户将其帐户移动到另一个服务），或者当资源倾向于以规范形式表示URI时，可能会发生这种情况。
The "subject" member SHOULD be present in the JRD.
“主题”成员应出现在JRD中。
The "aliases" array is an array of zero or more URI strings that identify the same entity as the "subject" URI.
“别名”数组是由零个或多个URI字符串组成的数组，这些字符串标识与“主题”URI相同的实体。
The "aliases" array is OPTIONAL in the JRD.
“别名”数组在JRD中是可选的。
The "properties" object comprises zero or more name/value pairs whose names are URIs (referred to as "property identifiers") and whose values are strings or null. Properties are used to convey additional information about the subject of the JRD. As an example, consider this use of "properties":
“properties”对象包含零个或多个名称/值对，其名称为URI（称为“property identifiers”），其值为字符串或null。属性用于传递有关JRD主题的附加信息。作为一个例子，考虑使用“属性”：
"properties" : { "http://webfinger.example/ns/name" : "Bob Smith" }
"properties" : { "http://webfinger.example/ns/name" : "Bob Smith" }
The "properties" member is OPTIONAL in the JRD.
“属性”成员在JRD中是可选的。
The "links" array has any number of member objects, each of which represents a link [4]. Each of these link objects can have the following members:
“links”数组有任意数量的成员对象，每个对象代表一个链接[4]。每个链接对象都可以有以下成员：
o rel o type o href o titles o properties
o rel o type o href o标题o属性
The "rel" and "href" members are strings representing the link's relation type and the target URI, respectively. The context of the link is the "subject" (see Section 4.4.1).
“rel”和“href”成员分别是表示链接的关系类型和目标URI的字符串。链接的上下文是“主题”（见第4.4.1节）。
The "type" member is a string indicating what the media type of the result of dereferencing the link ought to be.
“type”成员是一个字符串，指示取消引用链接的结果的媒体类型应该是什么。
The order of elements in the "links" array MAY be interpreted as indicating an order of preference. Thus, if there are two or more link relations having the same "rel" value, the first link relation would indicate the user's preferred link.
“链接”数组中元素的顺序可以解释为指示优先顺序。因此，如果存在具有相同“rel”值的两个或多个链路关系，则第一链路关系将指示用户的优选链路。
The "links" array is OPTIONAL in the JRD.
“链接”数组在JRD中是可选的。
Below, each of the members of the objects found in the "links" array is described in more detail. Each object in the "links" array, referred to as a "link relation object", is completely independent from any other object in the array; any requirement to include a given member in the link relation object refers only to that particular object.
下面，将对“链接”数组中找到的对象的每个成员进行更详细的描述。“链接”数组中的每个对象称为“链接关系对象”，与数组中的任何其他对象完全独立；在链接关系对象中包含给定成员的任何要求仅指该特定对象。
The value of the "rel" member is a string that is either a URI or a registered relation type [8] (see RFC 5988 [4]). The value of the "rel" member MUST contain exactly one URI or registered relation type. The URI or registered relation type identifies the type of the link relation.
“rel”成员的值是一个URI或注册关系类型[8]的字符串（请参阅RFC 5988[4]）。“rel”成员的值必须正好包含一个URI或注册的关系类型。URI或注册的关系类型标识链接关系的类型。
The other members of the object have meaning only once the type of link relation is understood. In some instances, the link relation will have associated semantics enabling the client to query for other resources on the Internet. In other instances, the link relation will have associated semantics enabling the client to utilize the other members of the link relation object without fetching additional external resources.
只有理解了链接关系的类型，对象的其他成员才有意义。在某些情况下，链接关系将具有相关的语义，使客户端能够查询Internet上的其他资源。在其他情况下，链接关系将具有相关的语义，使客户机能够利用链接关系对象的其他成员，而无需获取额外的外部资源。
URI link relation type values are compared using the "Simple String Comparison" algorithm of Section 6.2.1 of RFC 3986.
URI链接关系类型值使用RFC 3986第6.2.1节的“简单字符串比较”算法进行比较。
The "rel" member MUST be present in the link relation object.
链接关系对象中必须存在“rel”成员。
The value of the "type" member is a string that indicates the media type [9] of the target resource (see RFC 6838 [10]).
“type”成员的值是一个字符串，表示目标资源的媒体类型[9]（请参阅RFC 6838[10]）。
The "type" member is OPTIONAL in the link relation object.
“类型”成员在链接关系对象中是可选的。
The value of the "href" member is a string that contains a URI pointing to the target resource.
“href”成员的值是一个字符串，其中包含指向目标资源的URI。
The "href" member is OPTIONAL in the link relation object.
“href”成员在链接关系对象中是可选的。
The "titles" object comprises zero or more name/value pairs whose names are a language tag [11] or the string "und". The string is human-readable and describes the link relation. More than one title for the link relation MAY be provided for the benefit of users who utilize the link relation, and, if used, a language identifier SHOULD be duly used as the name. If the language is unknown or unspecified, then the name is "und".
“titles”对象包含零个或多个名称/值对，其名称为语言标记[11]或字符串“und”。字符串是人类可读的，并描述链接关系。为了使用链接关系的用户的利益，可以为链接关系提供多个标题，如果使用，应适当使用语言标识符作为名称。如果语言未知或未指定，则名称为“und”。
A JRD SHOULD NOT include more than one title identified with the same language tag (or "und") within the link relation object. Meaning is undefined if a link relation object includes more than one title
在链接关系对象中，JRD不应包含多个使用相同语言标记（或“und”）标识的标题。如果链接关系对象包含多个标题，则含义未定义
named with the same language tag (or "und"), though this MUST NOT be treated as an error. A client MAY select whichever title or titles it wishes to utilize.
使用相同的语言标记（或“und”）命名，但不能将其视为错误。客户可选择其希望使用的一个或多个标题。
Here is an example of the "titles" object:
以下是“标题”对象的示例：
"titles" :
{
"en-us" : "The Magical World of Steve",
"fr" : "Le Monde Magique de Steve"
}
"titles" :
{
"en-us" : "The Magical World of Steve",
"fr" : "Le Monde Magique de Steve"
}
The "titles" member is OPTIONAL in the link relation object.
“titles”成员在链接关系对象中是可选的。
The "properties" object within the link relation object comprises zero or more name/value pairs whose names are URIs (referred to as "property identifiers") and whose values are strings or null. Properties are used to convey additional information about the link relation. As an example, consider this use of "properties":
链接关系对象中的“属性”对象包含零个或多个名称/值对，其名称为URI（称为“属性标识符”），其值为字符串或null。属性用于传递有关链接关系的附加信息。作为一个例子，考虑使用“属性”：
"properties" : { "http://webfinger.example/mail/port" : "993" }
"properties" : { "http://webfinger.example/mail/port" : "993" }
The "properties" member is OPTIONAL in the link relation object.
“属性”成员在链接关系对象中是可选的。
WebFinger requests include a "resource" parameter (see Section 4.1) specifying the query target (URI) for which the client requests information. WebFinger is neutral regarding the scheme of such a URI: it could be an "acct" URI [18], an "http" or "https" URI, a "mailto" URI [19], or some other scheme.
WebFinger请求包括一个“资源”参数（请参见第4.1节），该参数指定客户端请求其信息的查询目标（URI）。WebFinger对于这种URI的方案是中立的：它可以是“acct”URI[18]、“http”或“https”URI、“mailto”URI[19]或其他方案。
WebFinger resources might not be accessible from a web browser due to "Same-Origin" policies. The current best practice is to make resources available to browsers through Cross-Origin Resource Sharing (CORS) [7], and servers MUST include the Access-Control-Allow-Origin HTTP header in responses. Servers SHOULD support the least restrictive setting by allowing any domain access to the WebFinger resource:
由于“同源”策略，可能无法从web浏览器访问WebFinger资源。当前的最佳实践是通过跨源资源共享（CORS）[7]向浏览器提供资源，服务器必须在响应中包含访问控制允许源HTTP头。服务器应通过允许任何域访问WebFinger资源来支持限制最少的设置：
Access-Control-Allow-Origin: *
访问控制允许来源：*
There are cases where defaulting to the least restrictive setting is not appropriate. For example, a server on an intranet that provides sensitive company information SHOULD NOT allow CORS requests from any domain, as that could allow leaking of that sensitive information. A server that wishes to restrict access to information from external entities SHOULD use a more restrictive Access-Control-Allow-Origin header.
在某些情况下，默认设置为限制性最小的设置是不合适的。例如，内联网上提供敏感公司信息的服务器不应允许来自任何域的CORS请求，因为这可能会导致敏感信息泄漏。希望限制从外部实体访问信息的服务器应使用更严格的访问控制允许源标题。
As with all web resources, access to the WebFinger resource could require authentication. Further, failure to provide required credentials might result in the server forbidding access or providing a different response than had the client authenticated with the server.
与所有web资源一样，访问WebFinger资源可能需要身份验证。此外，未能提供所需的凭据可能会导致服务器禁止访问或提供与客户端通过服务器身份验证不同的响应。
Likewise, a WebFinger resource MAY provide different responses to different clients based on other factors, such as whether the client is inside or outside a corporate network. As a concrete example, a query performed on the internal corporate network might return link relations to employee pictures, whereas link relations for employee pictures might not be provided to external entities.
类似地，WebFinger资源可以基于其他因素（例如客户端是在公司网络内部还是外部）向不同的客户端提供不同的响应。作为一个具体的例子，在内部公司网络上执行的查询可能会将链接关系返回给员工图片，而员工图片的链接关系可能不会提供给外部实体。
Further, link relations provided in a WebFinger resource representation might point to web resources that impose access restrictions. For example, the aforementioned corporate server may provide both internal and external entities with URIs to employee pictures, but further authentication might be required in order for the client to access the picture resources if the request comes from outside the corporate network.
此外，WebFinger资源表示中提供的链接关系可能指向施加访问限制的web资源。例如，前述公司服务器可以向内部和外部实体提供员工图片的uri，但是如果请求来自公司网络外部，则可能需要进一步的认证以便客户端访问图片资源。
The decisions made with respect to what set of link relations a WebFinger resource provides to one client versus another and what resources require further authentication, as well as the specific authentication mechanisms employed, are outside the scope of this document.
关于WebFinger资源提供给一个客户端与另一个客户端的链接关系集、需要进一步身份验证的资源以及使用的特定身份验证机制的决定不在本文档的范围内。
As with most services provided on the Internet, it is possible for a domain owner to utilize "hosted" WebFinger services. By way of example, a domain owner might control most aspects of their domain but use a third-party hosting service for email. In the case of email, mail exchange (MX) records identify mail servers for a domain. An MX record points to the mail server to which mail for the domain should be delivered. To the sending server, it does not matter whether those MX records point to a server in the destination domain or a different domain.
与Internet上提供的大多数服务一样，域所有者可以使用“托管”WebFinger服务。举例来说，域所有者可能控制其域的大部分方面，但使用第三方电子邮件托管服务。对于电子邮件，邮件交换（MX）记录标识域的邮件服务器。MX记录指向应将域的邮件传递到的邮件服务器。对于发送服务器，这些MX记录是指向目标域中的服务器还是指向其他域并不重要。
Likewise, a domain owner might utilize the services of a third party to provide WebFinger services on behalf of its users. Just as a domain owner is required to insert MX records into DNS to allow for hosted email services, the domain owner is required to redirect HTTP queries to its domain to allow for hosted WebFinger services.
同样，域所有者可能利用第三方的服务代表其用户提供WebFinger服务。正如域所有者需要将MX记录插入DNS以允许托管电子邮件服务一样，域所有者也需要将HTTP查询重定向到其域以允许托管WebFinger服务。
When a query is issued to the WebFinger resource, the web server MUST return a response with a redirection status code that includes a Location header pointing to the location of the hosted WebFinger service URI. This WebFinger service URI does not need to point to the well-known WebFinger location on the hosting service provider server.
向WebFinger资源发出查询时，web服务器必须返回一个带有重定向状态代码的响应，该代码包括指向托管WebFinger服务URI位置的位置标头。此WebFinger服务URI不需要指向托管服务提供商服务器上的已知WebFinger位置。
As an example, assume that example.com's WebFinger services are hosted by wf.example.net. Suppose a client issues a query for acct:alice@example.com like this:
例如，假设example.com的WebFinger服务由wf.example.net托管。假设客户机发出帐户查询：alice@example.com这样地：
GET /.well-known/webfinger?
resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
GET /.well-known/webfinger?
resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
The server might respond with this:
服务器可能会响应以下命令：
HTTP/1.1 307 Temporary Redirect
Access-Control-Allow-Origin: *
Location: https://wf.example.net/example.com/webfinger?
resource=acct%3Aalice%40example.com
HTTP/1.1 307 Temporary Redirect
Access-Control-Allow-Origin: *
Location: https://wf.example.net/example.com/webfinger?
resource=acct%3Aalice%40example.com
The client can then follow the redirection, reissuing the request to the URI provided in the Location header. Note that the server will include any required URI parameters in the Location header value, which could be different than the URI parameters the client originally used.
然后，客户端可以遵循重定向，将请求重新发送到Location标头中提供的URI。请注意，服务器将在Location标头值中包含任何必需的URI参数，这些参数可能不同于客户端最初使用的URI参数。
This specification details the protocol syntax used to query a domain for information about a URI, the syntax of the JSON Resource Descriptor (JRD) that is returned in response to that query, security requirements and considerations, hosted WebFinger services, various expected HTTP status codes, and so forth. However, this specification does not enumerate the various possible properties or link relation types that might be used in conjunction with WebFinger for a particular application, nor does it define what properties or link relation types one might expect to see in response to querying for a particular URI or URI scheme. Nonetheless, all of these unspecified elements are important in order to implement an interoperable application that utilizes the WebFinger protocol and
本规范详细说明了用于查询域以获取URI信息的协议语法、响应该查询返回的JSON资源描述符（JRD）语法、安全要求和注意事项、托管WebFinger服务、各种预期HTTP状态代码等。但是，该规范没有列举可能与WebFinger一起用于特定应用程序的各种可能的属性或链接关系类型，也没有定义在查询特定URI或URI方案时可能看到的属性或链接关系类型。尽管如此，为了实现利用WebFinger协议和
MUST be specified in the relevant document(s) defining the particular application making use of the WebFinger protocol according to the procedures described in this section.
必须在相关文件中指定，根据本节中描述的程序定义使用WebFinger协议的特定应用程序。
Any application that uses WebFinger MUST specify the URI scheme(s), and to the extent appropriate, what forms the URI(s) might take. For example, when querying for information about a user's account at some domain, it might make sense to specify the use of the "acct" URI scheme [18]. When trying to obtain the copyright information for a web page, it makes sense to specify the use of the web page URI (either http or https).
任何使用WebFinger的应用程序都必须指定URI方案，并在适当的范围内指定URI可能采用的形式。例如，当查询某个域中用户帐户的信息时，指定“acct”URI方案的使用可能是有意义的[18]。当试图获取网页的版权信息时，指定网页URI（http或https）的使用是有意义的。
The examples in Sections 3.1 and 3.2 illustrate the use of different URI schemes with WebFinger applications. In the example in Section 3.1, WebFinger is used to retrieve information pertinent to OpenID Connect. In the example in Section 3.2, WebFinger is used to discover metadata information about a web page, including author and copyright information. Each of these WebFinger applications needs to be fully specified to ensure interoperability.
第3.1节和第3.2节中的示例说明了在WebFinger应用程序中使用不同的URI方案。在第3.1节的示例中，WebFinger用于检索与OpenID Connect相关的信息。在第3.2节的示例中，WebFinger用于发现有关网页的元数据信息，包括作者和版权信息。每个WebFinger应用程序都需要完全指定，以确保互操作性。
As explained in Section 4, the host to which a WebFinger query is issued is significant. In general, WebFinger applications would adhere to the procedures described in Section 4 in order to properly direct a WebFinger query.
如第4节所述，向其发出WebFinger查询的主机非常重要。一般来说，WebFinger应用程序将遵循第4节中描述的过程，以便正确引导WebFinger查询。
However, some URI schemes do not have host portions and there might be some applications of WebFinger for which the host portion of a URI cannot or should not be utilized. In such instances, the application specification MUST clearly define the host resolution procedures, which might include provisioning a "default" host within the client to which queries are directed.
然而，一些URI方案没有主机部分，并且可能有一些WebFinger应用程序无法或不应该使用URI的主机部分。在这种情况下，应用程序规范必须明确定义主机解析过程，这可能包括在客户机内设置查询所指向的“默认”主机。
WebFinger defines both subject-specific properties (i.e., properties described in Section 4.4.3 that relate to the URI for which information is queried) and link-specific properties (see Section 4.4.4.5). This section refers to subject-specific properties.
WebFinger定义了主题特定属性（即第4.4.3节中描述的与查询信息的URI相关的属性）和链接特定属性（参见第4.4.4.5节）。本节涉及特定于主题的属性。
Applications that utilize subject-specific properties MUST define the URIs used in identifying those properties, along with valid property values.
使用特定于主题的属性的应用程序必须定义用于标识这些属性的URI以及有效的属性值。
Consider this portion of the JRD found in the example in Section 3.2.
考虑在第3.2节中示例中发现的JRD部分。
"properties" :
{
"http://blgx.example.net/ns/version" : "1.3",
"http://blgx.example.net/ns/ext" : null
}
"properties" :
{
"http://blgx.example.net/ns/version" : "1.3",
"http://blgx.example.net/ns/ext" : null
}
Here, two properties are returned in the WebFinger response. Each of these would be defined in a WebFinger application specification. These two properties might be defined in the same WebFinger application specification or separately in different specifications. Since the latter is possible, it is important that WebFinger clients not assume that one property has any specific relationship with another property, unless some relationship is explicitly defined in the particular WebFinger application specification.
这里，WebFinger响应中返回两个属性。其中每一项都将在WebFinger应用程序规范中定义。这两个属性可以在相同的WebFinger应用程序规范中定义，也可以在不同的规范中分别定义。由于后者是可能的，因此WebFinger客户端不应假定一个属性与另一个属性具有任何特定关系，除非在特定WebFinger应用程序规范中明确定义了某些关系，这一点很重要。
The links returned in a WebFinger response each comprise several pieces of information, some of which are optional (refer to Section 4.4.4). The WebFinger application specification MUST define each link and any values associated with a link, including the link relation type ("rel"), the expected media type ("type"), properties, and titles.
WebFinger响应中返回的每个链接都包含多条信息，其中一些是可选的（请参阅第4.4.4节）。WebFinger应用程序规范必须定义每个链接以及与链接相关的任何值，包括链接关系类型（“rel”）、预期媒体类型（“type”）、属性和标题。
The target URI to which the link refers (i.e., the "href"), if present, would not normally be specified in an application specification. However, the URI scheme or any special characteristics of the URI would usually be specified. If a particular link does not require an external reference, then all of the semantics related to the use of that link MUST be defined within the application specification. Such links might rely only on properties or titles in the link to convey meaning.
链接引用的目标URI（即“href”）如果存在，通常不会在应用程序规范中指定。然而，通常会指定URI方案或URI的任何特殊特征。如果特定链接不需要外部引用，那么与该链接的使用相关的所有语义都必须在应用程序规范中定义。此类链接可能仅依赖链接中的属性或标题来传达含义。
It is important to be mindful of the fact that different WebFinger applications might specify the use of the same URI scheme, and in effect, the same URI for different purposes. That should not be a problem, since each of property identifier (see Sections 4.4.3 and 4.4.4.5) and link relation type would be uniquely defined for a specific application.
需要注意的是，不同的WebFinger应用程序可能指定使用相同的URI方案，实际上，相同的URI用于不同的目的。这不应该是一个问题，因为属性标识符（见第4.4.3节和第4.4.4.5节）和链接关系类型中的每一个都是为特定应用程序唯一定义的。
It should be noted that when a client requests information about a particular URI and receives a response with a number of different property identifiers or link relation types that the response is providing information about the URI without any particular semantics.
应当注意，当客户端请求关于特定URI的信息并接收到具有多个不同属性标识符或链接关系类型的响应时，该响应提供关于URI的信息而没有任何特定语义。
How the client interprets the information SHOULD be in accordance with the particular application specification or set of specifications the client implements.
客户机解释信息的方式应符合客户机实现的特定应用程序规范或规范集。
Any syntactically valid properties or links the client receives and that are not fully understood SHOULD be ignored and SHOULD NOT cause the client to report an error.
客户端接收到的任何语法上有效的属性或链接，如果没有完全理解，都应该被忽略，并且不应该导致客户端报告错误。
Application specifications MAY define a simple token as a link relation type for a link. In that case, the link relation type MUST be registered with IANA as specified in Sections 10.3.
应用程序规范可以将简单令牌定义为链接的链接关系类型。在这种情况下，链接关系类型必须按照第10.3节的规定向IANA注册。
Further, any defined properties MUST be registered with IANA as described in Section 10.4.
此外，如第10.4节所述，任何定义的财产必须向IANA注册。
Since this specification utilizes Cross-Origin Resource Sharing (CORS) [7], all of the security considerations applicable to CORS are also applicable to this specification.
由于本规范使用了跨源资源共享（CORS）[7]，因此适用于CORS的所有安全注意事项也适用于本规范。
The use of HTTPS is REQUIRED to ensure that information is not modified during transit. It should be acknowledged that in environments where a web server is normally available, there exists the possibility that a compromised network might have its WebFinger resource operating on HTTPS replaced with one operating only over HTTP. As such, clients MUST NOT issue queries over a non-secure connection.
需要使用HTTPS以确保信息在传输过程中不被修改。应该承认的是，在web服务器通常可用的环境中，存在一种可能性，即受损网络可能会将其在HTTPS上运行的WebFinger资源替换为仅在HTTP上运行的WebFinger资源。因此，客户端不得通过非安全连接发出查询。
Clients MUST verify that the certificate used on an HTTPS connection is valid (as defined in [12]) and accept a response only if the certificate is valid.
客户端必须验证HTTPS连接上使用的证书是否有效（如[12]中所定义），并且仅当证书有效时才接受响应。
Service providers and users should be aware that placing information on the Internet means that any user can access that information, and WebFinger can be used to make it even easier to discover that information. While WebFinger can be an extremely useful tool for discovering one's avatar, blog, or other personal data, users should also understand the risks.
服务提供商和用户应该意识到，将信息放在互联网上意味着任何用户都可以访问该信息，而WebFinger可用于更容易地发现该信息。虽然WebFinger是发现个人头像、博客或其他个人数据的非常有用的工具，但用户也应该了解风险。
Systems or services that expose personal data via WebFinger MUST provide an interface by which users can select which data elements are exposed through the WebFinger interface. For example, social networking sites might allow users to mark certain data as "public" and then utilize that marking as a means of determining what information to expose via WebFinger. The information published via WebFinger would thus comprise only the information marked as public by the user. Further, the user has the ability to remove information from publication via WebFinger by removing this marking.
通过WebFinger公开个人数据的系统或服务必须提供一个界面，用户可以通过该界面选择通过WebFinger界面公开哪些数据元素。例如，社交网站可能允许用户将某些数据标记为“公共”，然后利用该标记确定通过WebFinger公开哪些信息。因此，通过WebFinger发布的信息将只包含用户标记为公共的信息。此外，用户还可以通过删除此标记，通过WebFinger从出版物中删除信息。
WebFinger MUST NOT be used to provide any personal data unless publishing that data via WebFinger by the relevant service was explicitly authorized by the person whose information is being shared. Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing implicit authorization of further publication of that data via WebFinger.
不得使用WebFinger提供任何个人数据，除非相关服务部门通过WebFinger发布该数据得到共享信息的人员的明确授权。在互联网上的访问控制或其他受限环境中发布个人数据并不等于通过WebFinger提供进一步发布该数据的隐含授权。
The privacy and security concerns with publishing personal data via WebFinger are worth emphasizing again with respect to personal data that might reveal a user's current context (e.g., the user's location). The power of WebFinger comes from providing a single place where others can find pointers to information about a person, but service providers and users should be mindful of the nature of that information shared and the fact that it might be available for the entire world to see. Sharing location information, for example, would potentially put a person in danger from any individual who might seek to inflict harm on that person.
通过WebFinger发布个人数据的隐私和安全问题值得再次强调，因为个人数据可能会泄露用户的当前上下文（例如，用户的位置）。WebFinger的力量来自于提供一个单一的地方，其他人可以在这里找到指向某人信息的指针，但服务提供商和用户应该注意共享信息的性质，以及整个世界都可以看到的事实。例如，共享位置信息可能会使一个人处于危险之中，因为任何人可能会试图对该人造成伤害。
Users should be aware of how easily personal data that one might publish can be used in unintended ways. In one study relevant to WebFinger-like services, Balduzzi et al. [20] took a large set of leaked email addresses and demonstrated a number of potential privacy concerns, including the ability to cross-correlate the same user's accounts over multiple social networks. The authors also describe potential mitigation strategies.
用户应该意识到，可能发布的个人数据很容易以非预期方式使用。在一项与WebFinger类服务相关的研究中，Balduzzi等人[20]收集了大量泄露的电子邮件地址，并证明了一些潜在的隐私问题，包括在多个社交网络上交叉关联同一用户帐户的能力。作者还描述了潜在的缓解策略。
The easy access to user information via WebFinger was a design goal of the protocol, not a limitation. If one wishes to limit access to information available via WebFinger, such as WebFinger resources for use inside a corporate network, the network administrator needs to take necessary measures to limit access from outside the network. Using standard methods for securing web resources, network administrators do have the ability to control access to resources that might return sensitive information. Further, a server can be employed in such a way as to require authentication and prevent disclosure of information to unauthorized entities.
通过WebFinger轻松访问用户信息是协议的设计目标，而不是限制。如果希望限制通过WebFinger访问可用信息，例如在公司网络内部使用的WebFinger资源，则网络管理员需要采取必要措施限制来自网络外部的访问。通过使用标准方法保护web资源，网络管理员确实能够控制对可能返回敏感信息的资源的访问。此外，服务器可以以要求认证和防止向未授权实体披露信息的方式使用。
Service providers should be mindful of the potential for abuse using WebFinger.
服务提供商应注意使用WebFinger的潜在滥用。
As one example, one might query a WebFinger server only to discover whether or not a given URI is valid. With such a query, the person may deduce that an email identifier is valid, for example. Such an approach could help spammers maintain a current list of known email addresses and to discover new ones.
例如，查询WebFinger服务器可能只是为了发现给定的URI是否有效。例如，通过这样的查询，此人可以推断电子邮件标识符是有效的。这种方法可以帮助垃圾邮件发送者维护已知电子邮件地址的当前列表，并发现新的电子邮件地址。
WebFinger could be used to associate a name or other personal data with an email address, allowing spammers to craft more convincing email messages. This might be of particular value in phishing attempts.
WebFinger可用于将姓名或其他个人数据与电子邮件地址相关联，从而使垃圾邮件发送者能够制作出更具说服力的电子邮件。这在网络钓鱼尝试中可能具有特别的价值。
It is RECOMMENDED that implementers of WebFinger server software take steps to mitigate abuse, including malicious over-use of the server and harvesting of user information. Although there is no mechanism that can guarantee that publicly accessible WebFinger databases won't be harvested, rate-limiting by IP address will prevent or at least dramatically slow harvest by private individuals without access to botnets or other distributed systems. The reason these mitigation strategies are not mandatory is that the correct choice of mitigation strategy (if any) depends greatly on the context. Implementers should not construe this as meaning that they do not need to consider whether to use a mitigation strategy, and if so, what strategy to use.
建议WebFinger服务器软件的实施者采取措施减少滥用，包括恶意过度使用服务器和获取用户信息。虽然没有任何机制可以保证公开访问的WebFinger数据库不会被捕获，但IP地址的速率限制将阻止或至少大大减缓个人在无法访问僵尸网络或其他分布式系统的情况下进行的捕获。这些缓解策略不是强制性的原因是，缓解策略（如有）的正确选择在很大程度上取决于环境。实施者不应该解释这意味着他们不需要考虑是否使用缓解策略，如果是的话，使用什么策略。
WebFinger client developers should also be aware of potential abuse by spammers or those phishing for information about users. As an example, suppose a mail client was configured to automatically perform a WebFinger query on the sender of each received mail message. If a spammer sent an email using a unique identifier in the 'From' header, then when the WebFinger query was performed, the spammer would be able to associate the request with a particular user's email address. This would provide information to the spammer, including the user's IP address, the fact the user just checked email, what kind of WebFinger client the user utilized, and so on. For this reason, it is strongly advised that clients not perform WebFinger queries unless authorized by the user to do so.
WebFinger客户端开发人员还应该意识到垃圾邮件发送者或网络钓鱼者对用户信息的潜在滥用。例如，假设邮件客户端配置为自动对收到的每封邮件的发件人执行WebFinger查询。如果垃圾邮件发送者使用“发件人”标题中的唯一标识符发送电子邮件，则在执行WebFinger查询时，垃圾邮件发送者将能够将请求与特定用户的电子邮件地址相关联。这将向垃圾邮件发送者提供信息，包括用户的IP地址、用户刚刚检查电子邮件的事实、用户使用的WebFinger客户端类型，等等。因此，强烈建议客户端不要执行WebFinger查询，除非得到用户授权。
A WebFinger resource has no means of ensuring that information provided by a user is accurate. Likewise, neither the resource nor the client can be absolutely guaranteed that information has not been manipulated either at the server or along the communication path
WebFinger资源无法确保用户提供的信息是准确的。同样，无论是资源还是客户端都不能绝对保证信息没有在服务器上或通信路径上被操纵
between the client and server. Use of HTTPS helps to address some concerns with manipulation of information along the communication path, but it clearly cannot address issues where the resource provided incorrect information, either due to being provided false information or due to malicious behavior on the part of the server administrator. As with any information service available on the Internet, users should be wary of information received from untrusted sources.
在客户端和服务器之间。使用HTTPS有助于解决在通信路径上操纵信息的一些问题，但它显然无法解决资源提供错误信息的问题，原因可能是提供了错误信息，也可能是服务器管理员的恶意行为。与互联网上的任何信息服务一样，用户应该警惕从不可信来源收到的信息。
This specification registers the "webfinger" well-known URI in the "Well-Known URIs" registry as defined by RFC 5785 [3].
本规范在RFC 5785[3]定义的“已知URI”注册表中注册“webfinger”已知URI。
URI suffix: webfinger
URI后缀：webfinger
Change controller: IETF
更改控制器：IETF
Specification document(s): RFC 7033
规范文件：RFC 7033
Related information: The query to the WebFinger resource will include one or more parameters in the query string; see Section 4.1 of RFC 7033. Resources at this location are able to return a JSON Resource Descriptor (JRD) as described in Section 4.4 of RFC 7033.
相关信息：对WebFinger资源的查询将在查询字符串中包含一个或多个参数；参见RFC 7033第4.1节。此位置的资源能够返回一个JSON资源描述符（JRD），如RFC 7033第4.4节所述。
This specification registers the media type application/jrd+json for use with WebFinger in accordance with media type registration procedures defined in RFC 6838 [10].
本规范根据RFC 6838[10]中定义的媒体类型注册程序，注册媒体类型应用程序/jrd+json，以便与WebFinger一起使用。
Type name: application
类型名称：应用程序
Subtype name: jrd+json
子类型名称：jrd+json
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
In particular, because RFC 4627 already defines the character encoding for JSON, no "charset" parameter is used.
特别是，因为RFC4627已经定义了JSON的字符编码，所以没有使用“charset”参数。
Encoding considerations: See RFC 6839, Section 3.1.
编码注意事项：见RFC 6839，第3.1节。
Security considerations:
安全考虑：
The JSON Resource Descriptor (JRD) is a JavaScript Object Notation (JSON) object. It is a text format that must be parsed by entities that wish to utilize the format. Depending on the language and mechanism used to parse a JSON object, it is possible for an attacker to inject behavior into a running program. Therefore, care must be taken to properly parse a received JRD to ensure that only a valid JSON object is present and that no JavaScript or other code is injected or executed unexpectedly.
JSON资源描述符（JRD）是一个JavaScript对象表示法（JSON）对象。它是一种文本格式，必须由希望使用该格式的实体进行解析。根据用于解析JSON对象的语言和机制，攻击者有可能将行为注入正在运行的程序。因此，必须注意正确解析接收到的JRD，以确保只存在有效的JSON对象，并且没有意外地注入或执行JavaScript或其他代码。
Interoperability considerations:
互操作性注意事项：
This media type is a JavaScript Object Notation (JSON) object and can be consumed by any software application that can consume JSON objects.
此媒体类型是一个JavaScript对象表示法（JSON）对象，可以由任何可以使用JSON对象的软件应用程序使用。
Published specification: RFC 7033
已发布规范：RFC 7033
Applications that use this media type:
使用此媒体类型的应用程序：
The JSON Resource Descriptor (JRD) is used by the WebFinger protocol (RFC 7033) to enable the exchange of information between a client and a WebFinger resource over HTTPS.
WebFinger协议（RFC 7033）使用JSON资源描述符（JRD）通过HTTPS实现客户端和WebFinger资源之间的信息交换。
Fragment identifier considerations:
片段标识符注意事项：
The syntax and semantics of fragment identifiers SHOULD be as specified for "application/json". (At publication of this document, there is no fragment identification syntax defined for "application/json".)
片段标识符的语法和语义应与“application/json”的语法和语义相同。（在本文档发布时，没有为“application/json”定义片段标识语法。）
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): jrd
文件扩展名：jrd
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Paul E. Jones <paulej@packetizer.com>
Paul E. Jones <paulej@packetizer.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Paul E. Jones <paulej@packetizer.com>
Author: Paul E. Jones <paulej@packetizer.com>
Change controller:
更改控制器：
IESG has change control over this registration.
IESG对此注册具有变更控制权。
Provisional registration? (standards tree only): N/A
临时登记？（仅限标准树）：不适用
RFC 5988 established a "Link Relation Types" registry that is reused by WebFinger applications.
RFC 5988建立了一个“链接关系类型”注册表，可供WebFinger应用程序重用。
Link relation types used by WebFinger applications are registered in the "Link Relation Types" registry as per the procedures of Section 6.2.1 of RFC 5988. The "Notes" entry for the registration SHOULD indicate if property values associated with the link relation type are registered in the "WebFinger Properties" registry with a link to the registry.
WebFinger应用程序使用的链接关系类型按照RFC 5988第6.2.1节的程序在“链接关系类型”注册表中注册。注册的“注释”条目应指明与链接关系类型关联的属性值是否在“WebFinger属性”注册表中注册，并带有指向注册表的链接。
WebFinger utilizes URIs to identify properties of a subject or link and the associated values (see Sections 8.3 and 8.6). This specification establishes a new "WebFinger Properties" registry to record property identifiers.
WebFinger利用URI识别主题或链接的属性以及相关值（参见第8.3节和第8.6节）。本规范建立了一个新的“WebFinger属性”注册表来记录属性标识符。
The registration template for WebFinger properties is:
WebFinger属性的注册模板为：
o Property Identifier:
o 属性标识符：
o Link Type:
o 链接类型：
o Description:
o 说明：
o Reference:
o 参考：
o Notes: [optional]
o 注：[可选]
The "Property Identifier" must be a URI that identifies the property being registered.
“属性标识符”必须是标识正在注册的属性的URI。
The "Link Type" contains the name of a link relation type with which this property identifier is used. If the property is a subject-specific property, then this field is specified as "N/A".
“链接类型”包含使用此属性标识符的链接关系类型的名称。如果属性是特定于主题的属性，则此字段指定为“不适用”。
The "Description" is intended to explain the purpose of the property.
“说明”旨在解释财产的用途。
The "Reference" field points to the specification that defines the registered property.
“Reference”字段指向定义注册属性的规范。
The optional "Notes" field is for conveying any useful information about the property that might be of value to implementers.
可选的“Notes”字段用于传递有关属性的任何有用信息，这些信息可能对实现者有价值。
The IETF has created a mailing list, webfinger@ietf.org, which can be used for public discussion of the WebFinger protocol and any applications that use it. Prior to registration of a WebFinger property, discussion on the mailing list is strongly encouraged. The IESG has appointed Designated Experts [13] who will monitor the webfinger@ietf.org mailing list and review registrations.
IETF已经创建了一个邮件列表，webfinger@ietf.org，可用于WebFinger协议和任何使用它的应用程序的公共讨论。在注册WebFinger财产之前，强烈鼓励对邮件列表进行讨论。IESG已经任命了指定的专家[13]，他们将监督webfinger@ietf.org邮件列表和审查注册。
A WebFinger property is registered with a Specification Required (see RFC 5226 [13]) after a review by the Designated Experts. The review is normally expected to take on the order of two to four weeks. However, the Designated Experts may approve a registration prior to publication of a specification once the Designated Experts are satisfied that such a specification will be published. In evaluating registration requests, the Designated Experts should make an effort to avoid registering two different properties that have the same meaning. Where a proposed property is similar to an already-defined property, the Designated Experts should insist that enough text be included in the description or notes section of the template to sufficiently differentiate the new property from an existing one.
经指定专家审查后，WebFinger财产按照要求的规范注册（见RFC 5226[13]）。通常预计审查时间为两到四周。但是，一旦指定专家确信规范将发布，指定专家可在规范发布前批准注册。在评估登记请求时，指定专家应努力避免登记两个含义相同的不同财产。如果拟议财产与已定义的财产相似，指定专家应坚持在模板的“说明”或“注释”部分包含足够的文本，以充分区分新财产与现有财产。
The registration procedure begins with a completed registration template (as defined above) sent to webfinger@ietf.org. Once consensus is reached on the mailing list, the registration template is sent to iana@iana.org. IANA will then contact the Designated Experts and communicate the results to the registrant. The WebFinger mailing list provides an opportunity for community discussion and input, and the Designated Experts may use that input to inform their review. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful if resubmitted.
注册过程从发送到的完整注册模板（如上所述）开始webfinger@ietf.org. 一旦就邮件列表达成共识，注册模板将发送至iana@iana.org. IANA随后将联系指定的专家，并将结果告知注册人。WebFinger邮件列表提供了一个社区讨论和输入的机会，指定专家可以使用该输入通知他们的审查。拒绝应包括解释，如果适用，还应包括如何在重新提交请求时使请求成功的建议。
The specification registering the WebFinger property MUST include the completed registration template shown above. Once the registration procedure concludes successfully, IANA creates or modifies the corresponding record in the "WebFinger Properties" registry.
注册WebFinger属性的规范必须包括上面显示的完整注册模板。注册过程成功结束后，IANA将在“WebFinger属性”注册表中创建或修改相应的记录。
This document has benefited from extensive discussion and review by many of the members of the APPSAWG working group. The authors would like to especially acknowledge the invaluable input of 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, and others that we have undoubtedly, but inadvertently, missed.
本文件得益于APPSAWG工作组许多成员的广泛讨论和审查。作者要特别感谢埃兰·哈默·拉哈夫、布莱恩·库克、布拉德·菲茨帕特里克、劳伦特·沃尔特·戈伊克斯、乔·克拉克、彼得·圣安德烈、迪克·哈特、蒂姆·布雷、詹姆斯·斯内尔、梅尔文·卡瓦略、埃文·普罗德罗莫、马克·诺丁汉、埃尔夫·帕弗里克、比约恩·霍尔曼、苏布拉曼尼安·穆内萨米、乔·格雷戈里奥、约翰·布拉德利、，和其他我们毫无疑问但无意中错过的东西。
The authors would also like to express their gratitude to the chairs of the APPSAWG working group, especially Salvatore Loreto for his assistance in shepherding this document. We also want to thank Barry Leiba and Pete Resnick, the Applications Area Directors, for their support and exhaustive reviews.
提交人还要感谢APPSAWG工作组主席，特别是Salvatore Loreto在指导本文件方面提供的帮助。我们还要感谢应用领域主管Barry Leiba和Pete Resnick的支持和详尽的评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[2] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[3] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[3] 诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 57852010年4月。
[4] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[4] 诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[5] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[5] Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC 4627，2006年7月。
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[6] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[7] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS, July 2010, <http://www.w3.org/TR/cors/>.
[7] Van Kesteren，A.，“跨来源资源共享”，W3C CORS，2010年7月<http://www.w3.org/TR/cors/>.
[8] IANA, "Link Relations", <http://www.iana.org/assignments/link-relations/>.
[8] IANA，“链接关系”<http://www.iana.org/assignments/link-relations/>.
[9] IANA, "MIME Media Types", <http://www.iana.org/assignments/media-types>.
[9] IANA，“MIME媒体类型”<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.
[10] Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[11] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[11] Phillips，A.，Ed.，和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，2009年9月。
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[13] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[14] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[14] Perreault，S.，“vCard格式规范”，RFC 63502011年8月。
[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>.
[15] Sakimura，N.，Bradley，J.，Jones，M.，de Medeiros，B.，Mortimore，C.，和E.Jay，“OpenID连接消息1.0”，2013年7月<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.
[16] Hammer Lahav，E.Ed.和B.Cook，“网络主机元数据”，RFC 6415，2011年10月。
[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>.
[17] Hammer Lahav，E.和W.Norris，“可扩展资源描述符（XRD）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.
[18] Saint Andre，P.，“acct”URI方案，正在进行的工作，2013年7月。
[19] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[19] Duerst，M.，Masinter，L.，和J.Zawinski，“mailto”URI方案”，RFC 6068，2010年10月。
[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>.
[20] Balduzzi，M.，Platzer，C.，Thorsten，H.，Kirda，E.，Balzarotti，D.，和C.Kruegel“滥用社交网络进行自动用户配置”，入侵检测的最新进展，斯普林格柏林海德堡，2010年3月<https://www.eurecom.fr/en/publication/3042/download/ rs-publi-3042_1.pdf>。
Authors' Addresses
作者地址
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Paul E.Jones Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编：27709
Phone: +1 919 476 2048
EMail: paulej@packetizer.com
IM: xmpp:paulej@packetizer.com
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
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编27709
Phone: +1 919 392 3266
EMail: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
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/
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joseph Smarr Google
约瑟夫·斯马尔谷歌
EMail: jsmarr@google.com
URI: http://josephsmarr.com/
EMail: jsmarr@google.com
URI: http://josephsmarr.com/