Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 7486 Trinity College Dublin
Category: Experimental P. Hoffman
ISSN: 2070-1721 VPN Consortium
M. Thomas
Phresheez
March 2015
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 7486 Trinity College Dublin
Category: Experimental P. Hoffman
ISSN: 2070-1721 VPN Consortium
M. Thomas
Phresheez
March 2015
HTTP Origin-Bound Authentication (HOBA)
HTTP源绑定身份验证（HOBA）
Abstract
摘要
HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.
HTTP源绑定身份验证（HOBA）是一种基于数字签名的HTTP身份验证方法设计。该设计还可用于嵌入HTML中的基于JavaScript的身份验证。HOBA是HTTP身份验证方案的替代方案，HTTP身份验证方案需要密码，因此避免了与密码相关的所有问题，例如服务器端密码数据库的泄漏。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7486.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7486.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Step-by-Step Overview of HOBA-http . . . . . . . . . . . 6
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 6
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 9
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 10
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 11
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 11
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 11
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 12
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 14
6.2. Associating Additional Keys to an Existing Account . . . 16
6.2.1. Moving Private Keys . . . . . . . . . . . . . . . . . 16
6.2.2. Human-Memorable One-Time Password (Don't Do This One) 16
6.2.3. Out-of-Band URL . . . . . . . . . . . . . . . . . . . 17
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 17
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
8.2. localStorage Security for JavaScript . . . . . . . . . . 19
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 20
8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 21
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 21
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 21
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Step-by-Step Overview of HOBA-http . . . . . . . . . . . 6
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 6
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 9
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 10
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 11
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 11
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 11
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 12
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 14
6.2. Associating Additional Keys to an Existing Account . . . 16
6.2.1. Moving Private Keys . . . . . . . . . . . . . . . . . 16
6.2.2. Human-Memorable One-Time Password (Don't Do This One) 16
6.2.3. Out-of-Band URL . . . . . . . . . . . . . . . . . . . 17
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 17
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
8.2. localStorage Security for JavaScript . . . . . . . . . . 19
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 20
8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 21
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 21
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 21
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 22
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 22
9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 26
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 22
9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 26
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
HTTP Origin-Bound Authentication (HOBA) is an authentication design that can be used as an HTTP authentication scheme [RFC7235] and for JavaScript-based authentication embedded in HTML. The main goal of HOBA is to offer an easy-to-implement authentication scheme that is not based on passwords but that can easily replace HTTP or HTML forms-based password authentication. Deployment of HOBA can reduce or eliminate password entries in databases, with potentially significant security benefits.
HTTP源绑定身份验证（HOBA）是一种身份验证设计，可以用作HTTP身份验证方案[RFC7235]，也可以用于嵌入HTML中的基于JavaScript的身份验证。HOBA的主要目标是提供一种易于实现的身份验证方案，该方案不基于密码，但可以轻松取代基于HTTP或HTML表单的密码身份验证。部署HOBA可以减少或消除数据库中的密码条目，具有潜在的重大安全好处。
HOBA is an HTTP authentication mechanism that complies with the framework for such schemes [RFC7235]. As a JavaScript design, HOBA demonstrates a way for clients and servers to interact using the same credentials that are used by the HTTP authentication scheme.
HOBA是一种HTTP身份验证机制，符合此类方案的框架[RFC7235]。作为一种JavaScript设计，HOBA演示了客户端和服务器使用HTTP身份验证方案使用的相同凭据进行交互的方法。
Current username/password authentication methods such as HTTP Basic, HTTP Digest, and web forms have been in use for many years but are susceptible to theft of server-side password databases. Instead of passwords, HOBA uses digital signatures in a challenge-response scheme as its authentication mechanism. HOBA also adds useful features such as credential management and session logout. In HOBA, the client creates a new public-private key pair for each host ("web origin" [RFC6454]) to which it authenticates. These keys are used in HOBA for HTTP clients to authenticate themselves to servers in the HTTP protocol or in a JavaScript authentication program.
当前的用户名/密码身份验证方法（如HTTP Basic、HTTP摘要和web表单）已使用多年，但容易被服务器端密码数据库窃取。HOBA在质询-响应方案中使用数字签名作为其身份验证机制，而不是密码。HOBA还添加了一些有用的功能，如凭证管理和会话注销。在HOBA中，客户机为其认证的每个主机（“web源”[RFC6454]）创建一个新的公私密钥对。这些密钥在HOBA中用于HTTP客户机向HTTP协议或JavaScript身份验证程序中的服务器进行身份验证。
HOBA session management is identical to username/password session management, with a server-side session management tool or script inserting a session cookie [RFC6265] into the output to the browser. Use of Transport Layer Security (TLS) for the HTTP session is still necessary to prevent session cookie hijacking.
HOBA会话管理与用户名/密码会话管理相同，通过服务器端会话管理工具或脚本将会话cookie[RFC6265]插入到浏览器的输出中。仍然需要为HTTP会话使用传输层安全性（TLS），以防止会话cookie劫持。
HOBA keys are "bare keys", so there is no need for the semantic overhead of X.509 public key certificates, particularly with respect to naming and trust anchors. The Client Public Key (CPK) structures
HOBA密钥是“裸密钥”，因此不需要X.509公钥证书的语义开销，特别是在命名和信任锚方面。客户端公钥（CPK）结构
in HOBA do not have any publicly visible identifier for the user who possesses the corresponding private key, nor the web origin with which the client is using the CPK.
在HOBA中，对于拥有相应私钥的用户，没有任何公开可见的标识符，也没有客户端使用CPK的web源。
HOBA also defines some services that are needed for modern HTTP authentication:
HOBA还定义了现代HTTP身份验证所需的一些服务：
o Servers can bind a CPK with an identifier, such as an account name. Servers using HOBA define their own policies for binding CPKs with accounts during account registration.
o 服务器可以使用标识符（如帐户名）绑定CPK。使用HOBA的服务器定义自己的策略，以便在帐户注册期间将CPK与帐户绑定。
o Users are likely to use more than one device or User Agent (UA) for the same HTTP-based service, so HOBA gives a way to associate more than one CPK to the same account without having to register for each separately.
o 用户可能会为同一个基于HTTP的服务使用多个设备或用户代理（UA），因此HOBA提供了一种方法，可以将多个CPK关联到同一个帐户，而无需分别注册。
o Logout features can be useful for UAs, so HOBA defines a way to close a current HTTP "session".
o 注销功能对UAs很有用，所以HOBA定义了一种关闭当前HTTP“会话”的方法。
o Digital signatures can be expensive to compute, so HOBA defines a way for HTTP servers to indicate how long a given challenge value is valid, and a way for UAs to fetch a fresh challenge at any time.
o 数字签名的计算成本很高，因此HOBA为HTTP服务器定义了一种指示给定质询值有效时间的方法，并为UAs定义了一种随时获取新质询的方法。
Users are also likely to lose a private key, or the client's memory of which key pair is associated with which origin, such as when a user loses the computer or mobile device in which state is stored. HOBA does not define a mechanism for deleting the association between an existing CPK and an account. Such a mechanism can be implemented at the application layer.
用户还可能丢失私钥，或者丢失与哪个来源相关联的密钥对的客户端内存，例如当用户丢失存储状态的计算机或移动设备时。HOBA没有定义删除现有CPK和帐户之间关联的机制。这种机制可以在应用层实现。
The HOBA scheme is far from new; for example, the basic idea is pretty much identical to the first two messages from "Mechanism R" on page 6 of [MI93], which predates HOBA by 20 years.
霍巴计划远非新鲜事；例如，基本思想与[MI93]第6页上“机制R”的前两条消息几乎相同，这两条消息比HOBA早20年。
HOBA can be used as a drop-in replacement for password-based user authentication schemes used in common web applications. The simplest way is to (re)direct the UA to a HOBA "Login" URL and for the response to a successful HTTP request containing a HOBA signature to set a session cookie [RFC6265]. Further interactions with the web application will then be secured via the session cookie, as is commonly done today.
HOBA可以作为普通web应用程序中使用的基于密码的用户身份验证方案的替代品。最简单的方法是（重新）将UA定向到HOBA“登录”URL，并响应包含HOBA签名的成功HTTP请求以设置会话cookie[RFC6265]。然后，与web应用程序的进一步交互将通过会话cookie进行保护，就像今天通常做的那样。
While cookies are bearer tokens, and thus weaker than HOBA signatures, they are currently ubiquitously used. If non-bearer token session continuation schemes are developed in the future in the IETF or elsewhere, then those can interface to HOBA as easily as with any password-based authentication scheme.
虽然Cookie是承载令牌，因此比HOBA签名弱，但它们目前被广泛使用。如果将来在IETF或其他地方开发了非承载令牌会话延续方案，那么这些方案可以像任何基于密码的认证方案一样容易地与HOBA接口。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）符号。
Account: The term "account" is (loosely) used to refer to whatever data structure(s) the server maintains that are associated with an identity. That will contain at least one CPK and a web origin; it will also optionally include an HTTP "realm" as defined in the HTTP authentication specification [RFC7235]. It might also involve many other non-standard pieces of data that the server accumulates as part of account creation processes. An account may have many CPKs that are considered equivalent in terms of being usable for authentication, but the meaning of "equivalent" is really up to the server and is not defined here.
Account：术语“Account”（不严格地）用于指服务器维护的与标识关联的任何数据结构。至少包含一个CPK和一个web源；它还可以选择包括HTTP身份验证规范[RFC7235]中定义的HTTP“领域”。它还可能涉及服务器在帐户创建过程中积累的许多其他非标准数据。一个帐户可能有许多在可用于身份验证方面被认为是等效的CPK，但“等效”的含义实际上取决于服务器，这里没有定义。
Client public key (CPK): A CPK is the public key and associated cryptographic parameters needed for a server to validate a signature.
客户端公钥（CPK）：CPK是服务器验证签名所需的公钥和相关加密参数。
HOBA-http: We use this term when describing something that is specific to HOBA as an HTTP authentication mechanism.
hobahttp：我们在描述HOBA特有的http身份验证机制时使用这个术语。
HOBA-js: We use this term when describing something that is unrelated to HOBA-http but is relevant for HOBA as a design pattern that can be implemented in a browser in JavaScript.
HOBA js：我们在描述与HOBA http无关但与HOBA相关的设计模式时使用这个术语，该设计模式可以在JavaScript浏览器中实现。
User agent (UA): typically, but not always, a web browser.
用户代理（UA）：通常但不总是web浏览器。
User: a person who is running a UA. In this document, "user" does not mean "user name" or "account name".
用户：运行UA的人员。在本文件中，“用户”不是指“用户名”或“账户名”。
Web client: the content and JavaScript code that run within the context of a single UA instance (such as a tab in a web browser).
Web客户端：在单个UA实例（例如Web浏览器中的选项卡）的上下文中运行的内容和JavaScript代码。
Step-by-step, a typical HOBA-http registration and authentication flow might look like this:
一步一步，典型的HOBA http注册和身份验证流程可能如下所示：
1. The client connects to the server and makes a request, and the server's response includes a WWW-Authenticate header field that contains the "HOBA" auth-scheme, along with associated parameters (see Section 3).
1. 客户端连接到服务器并发出请求，服务器的响应包括一个WWW Authenticate头字段，该字段包含“HOBA”身份验证方案以及相关参数（请参见第3节）。
2. If the client was not already registered with the web origin and realm it is trying to access, the "joining" process is invoked (see Section 6.1). This creates a key pair and makes the CPK known to the server so that the server can carry out the account creation processes required.
2. 如果客户机尚未向其试图访问的web源和域注册，则会调用“加入”过程（参见第6.1节）。这将创建一个密钥对，并使服务器知道CPK，以便服务器可以执行所需的帐户创建过程。
3. The client uses the challenge from the HOBA auth-scheme parameters, along with other information it knows about the web origin and realm, to create and sign a HOBA to-be-signed (HOBA-TBS) string (see Section 2).
3. 客户机使用来自HOBA auth方案参数的质询，以及它知道的有关web源和领域的其他信息，来创建和签署HOBA待签名（HOBA-TBS）字符串（请参阅第2节）。
4. The client creates a HOBA client-result (HOBA-RES), using the signed HOBA-TBS for the "sig" value (see Section 2).
4. 客户端使用签名的HOBA-TBS作为“sig”值创建HOBA客户端结果（HOBA-RES）（参见第2节）。
5. The client includes the Authorization header field in its next request, using the "HOBA" auth-scheme and putting the HOBA client-result in an auth-param named "result" (see Section 3).
5. 客户机在其下一个请求中包括Authorization header字段，使用“HOBA”身份验证方案，并将HOBA客户机结果放入名为“result”的身份验证参数中（参见第3节）。
6. The server authenticates the HOBA client-result (see Section 5.1).
6. 服务器验证HOBA客户端结果（参见第5.1节）。
7. Typically, the server's response includes a session cookie that allows the client to indicate its authentication state in future requests (see Section 1.1).
7. 通常，服务器的响应包括一个会话cookie，该cookie允许客户端在将来的请求中指示其身份验证状态（请参阅第1.1节）。
A UA that implements HOBA maintains a list of web origins and realms. The UA also maintains one or more client credentials for each web origin/realm combination for which it has created a CPK.
实现HOBA的UA维护web源和领域的列表。UA还为其已创建CPK的每个web源/领域组合维护一个或多个客户端凭据。
On receipt of a challenge (and optional realm) from a server, the client marshals a HOBA-TBS blob that includes a client generated nonce, the web origin, the realm, an identifier for the CPK, and the challenge string, and signs that blob with the private key corresponding to the CPK for that web origin. The formatting chosen
在从服务器接收质询（和可选领域）时，客户端封送一个HOBA-TBS blob，其中包括客户端生成的nonce、web源、领域、CPK标识符和质询字符串，并使用与该web源的CPK对应的私钥对该blob进行签名。所选格式
for this TBS blob is chosen so as to make server-side signature verification as simple as possible for a wide range of current server tooling.
为此，选择TBS blob是为了使服务器端签名验证尽可能简单，适用于当前广泛的服务器工具。
Figure 1 specifies the ABNF for the signature input. The term "unreserved" means that the field does not have a specific format defined and allows the characters specified in Section 2.3 of [RFC3986].
图1指定了签名输入的ABNF。术语“未保留”表示该字段未定义特定格式，允许使用[RFC3986]第2.3节中规定的字符。
HOBA-TBS = len ":" nonce
len ":" alg
len ":" origin
len ":" [ realm ]
len ":" kid
len ":" challenge
len = 1*DIGIT
nonce = 1*base64urlchars
alg = 1*2DIGIT
origin = scheme "://" authority ":" port
; scheme, etc., are from RFC 3986
realm = unreserved
; realm is to be treated as in Section 2.2 of RFC 7235
kid = 1*base64urlchars
challenge = 1*base64urlchars
; Characters for Base64URL encoding from Table 2 of RFC 4648
; all of which are US-ASCII (see RFC 20)
base64urlchars = %x30-39 ; Digits
/ %x41-5A ; Uppercase letters
/ %x61-7A ; Lowercase letters
/ "-" / "_" / "=" ; Special characters
HOBA-TBS = len ":" nonce
len ":" alg
len ":" origin
len ":" [ realm ]
len ":" kid
len ":" challenge
len = 1*DIGIT
nonce = 1*base64urlchars
alg = 1*2DIGIT
origin = scheme "://" authority ":" port
; scheme, etc., are from RFC 3986
realm = unreserved
; realm is to be treated as in Section 2.2 of RFC 7235
kid = 1*base64urlchars
challenge = 1*base64urlchars
; Characters for Base64URL encoding from Table 2 of RFC 4648
; all of which are US-ASCII (see RFC 20)
base64urlchars = %x30-39 ; Digits
/ %x41-5A ; Uppercase letters
/ %x61-7A ; Lowercase letters
/ "-" / "_" / "=" ; Special characters
Figure 1: To-Be-Signed Data for HOBA
图1:HOBA的待签名数据
The fields above contain the following:
上述字段包含以下内容：
o len: Each field is preceded by the number of octets of the following field, expressed as a decimal number in ASCII [RFC20]. Lengths are separated from field values by a colon character. So if a nonce with the value "ABCD" were used, then that would be preceeded by "4:" (see the example in Appendix B for details).
o len：每个字段前面都有以下字段的八位字节数，用ASCII[RFC20]中的十进制数表示。长度与字段值之间用冒号分隔。因此，如果使用了值为“ABCD”的nonce，则其前面将加上“4:”（有关详细信息，请参见附录B中的示例）。
o nonce: a random value chosen by the UA and MUST be base64url encoded before being included in the HOBA-TBS value. (base64url encoding is defined in [RFC4648]; guidelines for randomness are given in [RFC4086].) UAs MUST be able to use at least 32 bits of randomness in generating a nonce. UAs SHOULD be able to use 64 or more bits of randomness for nonces.
o nonce：UA选择的一个随机值，在包含在HOBA-TBS值中之前必须进行base64url编码。（base64url编码在[RFC4648]中定义；随机性准则在[RFC4086]中给出）。UAs必须能够在生成nonce时使用至少32位随机性。UAs应该能够为nonce使用64位或更多的随机性。
o alg: specifies the signature algorithm being used. See Section 7 for details of algorithm support requirements. The IANA-registered algorithm values (see Section 9.3) are encoded as one-or two-digit ASCII numbers. For example, RSA-SHA256 (number 0) is encoded as the ASCII character "0" (0x30), while a future algorithm registered as number 17 would be encoded as the ASCII characters "17" (0x3137).
o alg：指定正在使用的签名算法。有关算法支持要求的详细信息，请参见第7节。IANA注册算法值（见第9.3节）编码为一位或两位ASCII数字。例如，RSA-SHA256（数字0）编码为ASCII字符“0”（0x30），而注册为数字17的未来算法将编码为ASCII字符“17”（0x3137）。
o origin: the web origin expressed as the concatenation of the scheme, authority, and port from [RFC3986]. These are not base64 encoded, as they will be most readily available to the server in plain text. For example, if accessing the URL "https://www.example.com:8080/foo", then the bytes input to the signature process will be "https://www.example.com:8080". There is no default for the port number, and the port number MUST be present.
o 来源：web来源，表示为[RFC3986]中方案、权限和端口的连接。这些不是base64编码的，因为它们最容易以纯文本形式提供给服务器。例如，如果访问URL“https://www.example.com:8080/foo，则输入到签名进程的字节将为https://www.example.com:8080". 端口号没有默认值，端口号必须存在。
o realm: a string with the syntactic restrictions defined in [RFC7235]. If no realm is specified for this authentication, then this is absent but is preceeded by a length of zero ("0:"). Recall that both sides know when this needs to be there, independent of the encoding via a zero length.
o 领域：具有[RFC7235]中定义的语法限制的字符串。如果没有为此身份验证指定域，则不存在该域，但前面的长度为零（“0:”）。回想一下，双方都知道何时需要这样做，这与通过零长度进行编码无关。
o kid: a key identifier. This MUST be a base64url-encoded value that is presented to the server in the HOBA client result (see below).
o 孩子：一个关键标识符。这必须是在HOBA客户端结果中呈现给服务器的base64url编码值（见下文）。
o challenge: MUST be a base64url-encoded challenge value that the server chose to send to the client. The challenge MUST be chosen so that it is infeasible to guess and SHOULD be indistinguishable from (the base64url encoding of) a random string that is at least 128 bits long.
o 质询：必须是服务器选择发送给客户端的base64url编码的质询值。必须选择质询，使其无法猜测，并且与至少128位长的随机字符串（的base64url编码）无法区分。
The HOBA-TBS string is the input to the client's signing process but is not itself sent over the network since some fields are already inherent in the HTTP exchange. The challenge, however, is sent over the network so as to reduce the amount of state that needs to be maintained by servers. (One form of stateless challenge might be a ciphertext that the server decrypts and checks, but that is an implementation detail.) The value that is sent over the network by the UA is the HOBA "client result", which we now define.
HOBA-TBS字符串是客户端签名过程的输入，但它本身不是通过网络发送的，因为HTTP交换中已经存在一些字段。然而，挑战通过网络发送，以减少服务器需要维护的状态量。（无状态质询的一种形式可能是服务器解密和检查的密文，但这是一个实现细节。）UA通过网络发送的值是HOBA“客户端结果”，我们现在定义它。
The HOBA "client result" is a dot-separated string that includes the signature and is sent in the HTTP Authorization header field value using the value syntax defined in Figure 2. The "sig" value is the base64url-encoded version of the binary output of the signing process. The kid, challenge, and nonce are as defined above and are also base64url encoded.
HOBA“客户机结果”是一个以点分隔的字符串，包含签名，并使用图2中定义的值语法在HTTP授权头字段值中发送。“sig”值是签名过程二进制输出的base64url编码版本。kid、challenge和nonce如上所述，并且也是base64url编码的。
HOBA-RES = kid "." challenge "." nonce "." sig sig = 1*base64urlchars
HOBA-RES=kid.“challenge.”nonce.“sig sig=1*base64urlchars
Figure 2: HOBA Client Result Value
图2:HOBA客户端结果值
If a malformed message of any kind is received by a server, the server MUST fail authentication. If a malformed message of any kind is received by a client, the client MUST abandon that authentication attempt. (The client is, of course, free to start another authentication attempt if it desires.)
如果服务器接收到任何形式的错误消息，则服务器的身份验证必须失败。如果客户端接收到任何形式的错误消息，则客户端必须放弃该身份验证尝试。（当然，如果需要，客户端可以自由地启动另一次身份验证尝试。）
An HTTP server that supports HOBA authentication includes the "HOBA" auth-scheme value in a WWW-Authenticate header field when it wants the client to authenticate with HOBA. Note that the HOBA auth-scheme might not be the only one that the server includes in a WWW-Authenticate header.
支持HOBA身份验证的HTTP服务器希望客户端使用HOBA进行身份验证时，会在WWW Authenticate标头字段中包含“HOBA”身份验证方案值。注意，HOBA auth方案可能不是服务器在WWW-Authenticate头中包含的唯一方案。
The HOBA scheme has two REQUIRED attributes (challenge and max-age) and one OPTIONAL attribute (realm):
HOBA方案有两个必需属性（挑战和最大年龄）和一个可选属性（领域）：
o The "challenge" attribute MUST be included. The challenge is the string made up of the base64url-encoded octets that the server wants the client to sign in its response. The challenge MUST be unique for every 401 HTTP response in order to prevent replay attacks from passive observers.
o 必须包括“挑战”属性。挑战是由base64url编码的八位字节组成的字符串，服务器希望客户端在其响应中签名。为了防止被动观察者的重播攻击，每个401 HTTP响应的质询必须是唯一的。
o A "max-age" attribute MUST be included. It specifies the number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted; for example, "max-age: 10" would indicate ten seconds. If max-age is set to zero, then that means that only one signature will be accepted for this challenge.
o 必须包含“最大年龄”属性。它指定从HTTP响应发出开始的秒数，可以接受对此质询的响应；例如，“最大年龄：10”表示10秒。如果“最大年龄”设置为零，则表示此质询只接受一个签名。
o A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Authentication [RFC7235]. The "realm" attribute MUST NOT appear more than once.
o 可以包括“realm”属性，以按照HTTP/1.1认证[RFC7235]中描述的方式指示保护范围。“realm”属性不能出现多次。
When the "client response" is created, the UA encodes the HOBA client-result and returns that in the Authorization header. The client-result is a string matching the HOBA-RES production in Figure 2 as an auth-param with the name "result".
创建“客户机响应”时，UA对HOBA客户机结果进行编码，并在授权标头中返回结果。客户机结果是一个字符串，与图2中的HOBA-RES产品匹配，作为一个名为“result”的auth参数。
The server MUST check the cryptographic correctness of the signature based on a public key it knows for the kid in the signatures, and if the server cannot do that, or if the signature fails cryptographic checks, then validation has failed. The server can use any
服务器必须根据它为签名中的孩子知道的公钥来检查签名的加密正确性，如果服务器不能这样做，或者如果签名未通过加密检查，则验证失败。服务器可以使用任何
additional mechanisms to validate the signature. If the validation fails, or if the server chooses to reject the signature for any reason whatsoever, the server fails the request with a 401 Unauthorized HTTP response.
验证签名的其他机制。如果验证失败，或者如果服务器出于任何原因选择拒绝签名，服务器将使用401未经授权的HTTP响应使请求失败。
The server MUST check that the same web origin is used in all of the server's TLS server certificates, the URL being accessed, and the HOBA signature. If any of those checks fail, the server treats the signature as being cryptographically incorrect.
服务器必须检查服务器的所有TLS服务器证书、正在访问的URL和HOBA签名中是否使用了相同的web源。如果其中任何一项检查失败，服务器会将签名视为加密错误。
Note that a HOBA signature is good for however long a non-zero max-age parameter allows. This means that replay is possible within the time window specified by the "max-age" value chosen by the server. Servers can attempt to detect any such replay (via caching if they so choose) and MAY react to such replays by responding with a second (or subsequent) 401 HTTP response containing a new challenge.
请注意，无论非零max age参数允许多长时间，HOBA签名都是有效的。这意味着可以在服务器选择的“最大年龄”值指定的时间窗口内重播。服务器可以尝试检测任何此类重播（如果他们选择的话，可以通过缓存），并且可以通过使用第二个（或后续的）包含新质询的401 HTTP响应来响应此类重播。
To optimize their use of challenges, UAs MAY prefetch a challenge value, for example, after (max-age)/2 seconds have elapsed, using the ".well-known/hoba/getchal" scheme described later in this document. This also allows for precalculation of HOBA signatures, if that is required in order to produce a responsive user interface.
为了优化质询的使用，UAs可以预取质询值，例如，在（最大年龄）/2秒之后，使用本文档后面描述的“.well-known/hoba/getchal”方案。这还允许预先计算HOBA签名（如果需要），以生成响应性用户界面。
Web sites using JavaScript can also perform origin-bound authentication without needing to involve the HTTP layer and by inference not needing HOBA-http support in browsers. HOBA-js is not an on-the-wire protocol like HOBA-http is; instead, it is a design pattern that can be realized completely in JavaScript served in normal HTML pages.
使用JavaScript的网站也可以执行源代码绑定的身份验证，而无需涉及HTTP层，并且可以推断浏览器中不需要HTTP支持。HOBA js不像HOBA http那样是在线协议；相反，它是一种设计模式，完全可以在普通HTML页面中提供的JavaScript中实现。
One thing that is highly desirable for HOBA-js is WebCrypto (see <http://www.w3.org/TR/WebCryptoAPI>), which is (at the time of writing) starting to see deployment. In lieu of WebCrypto, JavaScript crypto libraries can be employed with the known deficiencies of their pseudo-random number generators and the general immaturity of those libraries.
HOBA js非常需要的一件事是WebCrypto（参见<http://www.w3.org/TR/WebCryptoAPI>)，它（在编写本文时）开始看到部署。可以使用JavaScript加密库代替WebCrypto，因为它们的伪随机数生成器存在已知的缺陷，而且这些库通常还不成熟。
Without Webcrypto, one element is required for HOBA-js; localStorage (see <http://www.w3.org/TR/webstorage/>) from HTML5 can be used for persistent key storage. For example, an implementation would store a dictionary account identifier as well as public key and private key tuples in the origin's localStorage for subsequent authentication requests. How this information is actually stored in localStorage is an implementation detail. This type of key storage relies on the security properties of the same-origin policy that localStorage enforces. See the security considerations for discussion about
如果没有Webcrypto，HOBA js需要一个元素；本地存储（请参阅<http://www.w3.org/TR/webstorage/>)从HTML5可以用于持久密钥存储。例如，实现将字典帐户标识符以及公钥和私钥元组存储在源本地存储中，以供后续身份验证请求使用。如何在localStorage中实际存储此信息是一个实现细节。这种类型的密钥存储依赖于localStorage实施的同源策略的安全属性。有关的讨论，请参见安全注意事项
attacks on localStorage. Note that IndexedDB (see <http://www.w3.org/TR/IndexedDB/>) is an alternative to localStorage that can also be used here and that is used by WebCrypto.
对本地存储的攻击。注意IndexedDB（参见<http://www.w3.org/TR/IndexedDB/>)是localStorage的替代品，也可在此处使用，并由WebCrypto使用。
Because of JavaScript's same-origin policy, scripts from subdomains do not have access to the same localStorage that scripts in their parent domains do. For larger or more complex sites, this could be an issue that requires enrollment into subdomains, which could be difficult for users. One way to get around this is to use session cookies because they can be used across subdomains. That is, with HOBA-js, the user might log in using a single well-known domain, and then session cookies are used whilst the user navigates around the site.
由于JavaScript的同源策略，子域中的脚本无法访问与其父域中的脚本相同的本地存储。对于更大或更复杂的站点，这可能是一个需要注册到子域的问题，这对用户来说可能很困难。解决这个问题的一种方法是使用会话cookie，因为它们可以跨子域使用。也就是说，使用HOBA js，用户可以使用单个已知域登录，然后在用户浏览站点时使用会话cookie。
This section describes how clients and servers use HOBA for authentication. The interaction between an HTTP client and HTTP server using HOBA happens in three phases: the CPK preparation phase, the signing phase, and the authentication phase. This section also covers the actions that give HOBA features similar to today's password-based schemes.
本节介绍客户端和服务器如何使用HOBA进行身份验证。使用HOBA的HTTP客户机和HTTP服务器之间的交互分为三个阶段：CPK准备阶段、签名阶段和身份验证阶段。本节还介绍了赋予HOBA类似于当今基于密码的方案的功能的操作。
In the CPK preparation phase, the client determines if it already has a CPK for the web origin with which it needs to authenticate. If the client has a CPK, the client will use it; if the client does not have a CPK, it generates one in anticipation of the server asking for one.
在CPK准备阶段，客户机确定它是否已经拥有用于需要验证的web源的CPK。如果客户有CPK，客户将使用它；如果客户端没有CPK，它会在服务器请求CPK时生成一个CPK。
In the signing phase, the client connects to the server, the server asks for HOBA-based authentication, and the client authenticates by signing a blob of information as described in the previous sections.
在签名阶段，客户机连接到服务器，服务器请求基于HOBA的身份验证，客户机通过签名一组信息进行身份验证，如前几节所述。
The authentication phase is completely dependent on the policies and practices of the server. That is, this phase involves no standardized protocol in HOBA-http; in HOBA-js, there is no suggested interaction template.
身份验证阶段完全依赖于服务器的策略和实践。也就是说，这个阶段不涉及HOBA http中的标准化协议；在HOBA js中，没有建议的交互模板。
In the authentication phase, the server uses the key identifier (kid) to determine the CPK from the signing phase and decides if it recognizes the CPK. If the server recognizes the CPK, the server may finish the client authentication process.
在身份验证阶段，服务器使用密钥标识符（kid）从签名阶段确定CPK，并决定是否识别CPK。如果服务器识别出CPK，则服务器可以完成客户端身份验证过程。
If this stage of the process involves additional information for authentication, such as asking the user which account she wants to use (in the case where a UA is used for multiple accounts on a site), the server can prompt the user for account identifying information, or the user could choose based on HTML offered by the server before the 401 response is triggered. None of this is standardized: it all follows the server's security policy and session flow. At the end of this, the server probably assigns or updates a session cookie for the client.
如果该过程的这一阶段涉及用于身份验证的附加信息，例如询问用户想要使用哪个帐户（在一个站点上的多个帐户使用UA的情况下），服务器可以提示用户提供帐户标识信息，或者用户可以在触发401响应之前根据服务器提供的HTML进行选择。所有这些都不是标准化的：它们都遵循服务器的安全策略和会话流。最后，服务器可能会为客户端分配或更新会话cookie。
During the authentication phase, if the server cannot determine the correct CPK, it could use HTML and JavaScript to ask the user if they are really a new user or want to associate this new CPK with another CPK. The server can then use some out-of-band method (such as a confirmation email round trip, SMS, or a UA that is already enrolled) to verify that the "new" user is the same as the already-enrolled one. Thus, logging in on a new UA is identical to logging in with an existing account.
在身份验证阶段，如果服务器无法确定正确的CPK，它可以使用HTML和JavaScript询问用户是否真的是新用户，或者是否希望将此新CPK与另一个CPK关联。然后，服务器可以使用一些带外方法（如确认电子邮件往返、SMS或已注册的UA）来验证“新”用户是否与已注册的用户相同。因此，在新UA上登录与使用现有帐户登录完全相同。
If the server does not recognize the CPK, the server might send the client through either a join or login-new-UA (see below) process. This process is completely up to the server and probably entails using HTML and JavaScript to ask the user some questions in order to assess whether or not the server wants to give the client an account. Completion of the joining process might require confirmation by email, SMS, CAPTCHA, and so on.
如果服务器无法识别CPK，则服务器可能会通过加入或登录新UA（请参见下文）进程发送客户端。这个过程完全取决于服务器，可能需要使用HTML和JavaScript向用户询问一些问题，以便评估服务器是否想要给客户端一个帐户。完成加入过程可能需要通过电子邮件、短信、验证码等进行确认。
Note that there is no necessity for the server to initiate a joining or login process upon completion of the signing phase. Indeed, the server may desire to challenge the UA even for unprotected resources and set a session cookie for later use in a join or login process as it becomes necessary. For example, a server might only want to offer an account to someone who had been to a few pages on the web site; in such a case, the server could use the CPK from an associated session cookie as a way of building reputation for the user until the server wants the user to join.
请注意，服务器没有必要在完成签名阶段后启动加入或登录过程。事实上，服务器可能希望挑战UA，即使是不受保护的资源，并设置会话cookie，以便在必要时在加入或登录过程中使用。例如，服务器可能只想向浏览过网站上几页的人提供一个帐户；在这种情况下，服务器可以使用关联会话cookie中的CPK为用户建立信誉，直到服务器希望用户加入。
The authentication process is more than just the act of authentication. In password-based authentication and HOBA, there are other processes that are needed both before and after an authentication step. This section covers those processes. Where possible, it combines practices of HOBA-http and HOBA-js; where that is not possible, the differences are called out.
认证过程不仅仅是认证行为。在基于密码的身份验证和HOBA中，在身份验证步骤之前和之后都需要其他过程。本节介绍这些过程。在可能的情况下，它结合了hobahttp和hobajs的实践；如果这是不可能的，差异就会被指出。
All HOBA interactions other than those defined in Section 5 MUST be performed in TLS-protected sessions [RFC5246]. If the current HTTP traffic is not running under TLS, a new session is started before any of the actions described here are performed.
除第5节中定义的HOBA交互外，所有HOBA交互必须在TLS保护会话[RFC5246]中执行。如果当前HTTP通信未在TLS下运行，则在执行此处描述的任何操作之前，将启动一个新会话。
HOBA-http uses a well-known URI [RFC5785] "hoba" as a base URI for performing many tasks: "https://www.example.com/.well-known/hoba". These URIs are based on the name of the host that the HTTP client is accessing.
HOBA http使用众所周知的URI[RFC5785]“HOBA”作为执行许多任务的基本URI：https://www.example.com/.well-known/hoba". 这些URI基于HTTP客户端正在访问的主机的名称。
There are many use cases for these URLs to redirect to other URLs: a site that does registration through a federated site, a site that only does registration under HTTPS, and so on. Like any HTTP client, HOBA-http clients have to be able to handle redirection of these requests. However, as that would potentially cause security issues when a re-direct brings the client to a different web origin, servers implementing HOBA-http SHOULD NOT redirect to a different web origin from below ".well-known/hoba" URLs. The above is considered sufficient to allow experimentation with HOBA, but if at some point HOBA is placed on the Standards Track, then a full analysis of off-origin redirections would need to be documented.
这些URL有许多重定向到其他URL的用例：通过联邦站点进行注册的站点，仅通过HTTPS进行注册的站点，等等。与任何HTTP客户端一样，HOBA HTTP客户端必须能够处理这些请求的重定向。但是，当重新定向将客户端带到不同的web源时，这可能会导致安全问题，因此实现HOBA http的服务器不应从下面的“.well-known/HOBA”URL重定向到不同的web源。上述内容被认为足以进行HOBA试验，但如果在某一点上HOBA被置于标准轨道上，则需要记录对异地重定向的完整分析。
Normally, a registration (also called "joining") is expected to happen after a UA receives a 401 response for a web origin and realm (for HOBA-http) or on demand (for HOBA-js) for which it has no associated CPK. The process of registration for a HOBA account on a server is relatively lightweight. The UA generates a new key pair and associates it with the web origin/realm in question.
通常，注册（也称为“加入”）预计在UA收到401响应后发生，该响应针对的是它没有关联CPK的web源和领域（对于HOBA http）或按需（对于HOBA js）。在服务器上注册HOBA帐户的过程相对较轻。UA生成一个新的密钥对，并将其与相关的web源/域相关联。
Note that if the UA has a CPK associated with the web origin, but not for the realm concerned, then a new registration is REQUIRED. If the server did not wish for that outcome, then it ought to use the same or no realm.
请注意，如果UA有一个与web源关联的CPK，但不适用于相关领域，则需要重新注册。如果服务器不希望出现这样的结果，那么它应该使用相同的或不使用任何领域。
The registration message for HOBA-http is sent as a POST message to the URL ".well-known/hoba/register" with an HTML form (x-www-form-encoded, see <http://www.w3.org/TR/2014/REC-html5-20141028/ forms.html#url-encoded-form-data>), described below. The registration message for HOBA-js can be in any format specified by the server, but it could be the same as the one described here for HOBA-http. It is up to the server to decide what kind of user interaction is required before the account is finally set up. When the server's chosen registration flow is completed successfully, the server MUST add a Hobareg HTTP header (see Section 6.1.1) to the HTTP response message that completes the registration flow.
HOBA http的注册消息作为POST消息发送到URL“.well-known/HOBA/register”，带有HTML表单（x-www-form-encoded，请参阅<http://www.w3.org/TR/2014/REC-html5-20141028/ html#url编码表单数据>），如下所述。hobajs的注册消息可以是服务器指定的任何格式，但它可以与这里描述的hobahttp的格式相同。在最终设置帐户之前，由服务器决定需要何种用户交互。当服务器选择的注册流成功完成时，服务器必须向完成注册流的HTTP响应消息中添加Hobareg HTTP头（参见第6.1.1节）。
The registration message sent to the server has one mandatory field (pub) and some optional fields that allow the UA to specify the type and value of key and device identifiers that the UA wishes to use.
发送到服务器的注册消息有一个必填字段（pub）和一些可选字段，允许UA指定UA希望使用的密钥和设备标识符的类型和值。
o pub: a mandatory field containing the Privacy Enhanced Mail (PEM) formatted public key of the client. See Appendix C of [RFC6376] for an example of how to generate this key format.
o pub：包含客户端隐私增强邮件（PEM）格式公钥的必填字段。有关如何生成此密钥格式的示例，请参见[RFC6376]的附录C。
o kidtype: contains the type of key identifier. This is a numeric value intended to contain one of the values from Section 9.4. If this is not present, then the mandatory-to-implement hashed public key option MUST be used.
o kidtype：包含密钥标识符的类型。这是一个数字值，旨在包含第9.4节中的一个值。如果不存在此选项，则必须使用强制实现哈希公钥选项。
o kid: contains the key identifier as a base64url-encoded string that is of the type indicated in the kidtype. If the kid is a hash of a public key, then the correct (base64url-encoded) hash value MUST be provided and the server SHOULD check that and refuse the registration if an incorrect value was supplied.
o kid：包含密钥标识符，作为基德类型中指定类型的base64url编码字符串。如果kid是公钥的散列，则必须提供正确的（base64url编码的）散列值，并且服务器应检查该散列值，如果提供的值不正确，则拒绝注册。
o didtype: specifies a kind of device identifier intended to contain one of the values from Section 9.5. If absent, then the "string" form of device identifier defined in Section 9.5 MUST be used.
o didtype：指定一种设备标识符，用于包含第9.5节中的一个值。如果没有，则必须使用第9.5节中定义的设备标识符的“字符串”形式。
o did: a UTF-8 string that specifies the device identifier. This can be used to help a user be confident that authentication has worked, e.g., following authentication, some web content might say "You last logged in from device 'did' at time T."
o did：指定设备标识符的UTF-8字符串。这可用于帮助用户确信身份验证已起作用，例如，在身份验证之后，某些web内容可能会说“您上次从设备‘did’登录是在时间T。”
Note that replay of registration (and other HOBA) messages is quite possible. That, however, can be counteracted if challenge freshness is ensured. See Section 2 for details. Note also that with HOBA-http, the HOBA signature does not cover the POST message body. If that is required, then HOBA-JS may be a better fit for registration and other account management actions.
请注意，注册（和其他HOBA）消息的重播是完全可能的。然而，如果保证了挑战新鲜度，这一点可以抵消。详见第2节。还请注意，对于HOBA http，HOBA签名不包括POST消息体。如果需要，那么HOBA-JS可能更适合注册和其他帐户管理操作。
Since registration can often be a multi-step process, e.g., requiring a user to fill in contact details, the initial response to the HTTP POST message defined above may not be the end of the registration process even though the HTTP response has a 200 OK status. This creates an issue for the UA since, during the registration process (e.g., while dealing with interstitial pages), the UA doesn't yet know whether the CPK is good for that web origin or not.
由于注册通常可以是一个多步骤的过程，例如，要求用户填写联系人详细信息，因此对上面定义的HTTP POST消息的初始响应可能不是注册过程的结束，即使HTTP响应具有200 OK状态。这给UA带来了一个问题，因为在注册过程中（例如，在处理中间页面时），UA还不知道CPK是否适合该web源。
For this reason, the server MUST add a header field to the response message when the registration has succeeded in order to indicate the new state. The header to be used is "Hobareg", and the value when
因此，当注册成功时，服务器必须在响应消息中添加头字段，以指示新状态。要使用的标题是“Hobareg”，并且
registration has succeeded is to be "regok". When registration is in an intermediate state (e.g., on an HTTP response for an interstitial page), the server MAY add this header with a value of "reginwork". See Section 9.6 for the relevant IANA registration of this header field.
注册已成功，请输入“regok”。当注册处于中间状态时（例如，在间隙页面的HTTP响应上），服务器可以使用“reginwork”值添加此标头。有关此标题字段的相关IANA注册，请参见第9.6节。
For interstitial pages, the client MAY include a HOBA Authorization header. This is not considered a "MUST", as that might needlessly complicate client implementations, but is noted here in case a server implementer assumes that all registration messages contain a HOBA Authorization header.
对于中间页，客户端可以包括HOBA授权头。这不被认为是“必须”，因为这可能会使客户端实现变得不必要的复杂，但在服务器实现者假设所有注册消息都包含HOBA授权头的情况下需要注意。
Hobareg-val = "regok" / "reginwork"
Hobareg-val = "regok" / "reginwork"
Figure 3: Hobareg Header Field Definition
图3:Hobareg头字段定义
Figure 3 provides an ABNF definition for the values allowed in the Hobareg header field. Note that these (and the header field name) are case insensitive. Section 8.3.1 of [RFC7231] calls for documenting the following details for this new header field:
图3为Hobareg header字段中允许的值提供了ABNF定义。请注意，这些字段（以及标题字段名）不区分大小写。[RFC7231]第8.3.1节要求记录此新标题字段的以下详细信息：
o Only one single value is allowed in a Hobareg header field. Should more than one (a list) be encountered, or any other ABNF-invalid value, that SHOULD be interpreted as being the same as "reginwork".
o Hobareg头字段中只允许有一个值。如果遇到多个（列表）或任何其他ABNF无效值，应解释为与“reginwork”相同。
o The Hobareg header field can only be used in HTTP responses.
o Hobareg标头字段只能在HTTP响应中使用。
o Since Hobareg is only meant for responses, it ought not appear in requests.
o 因为Hobareg只用于响应，所以它不应该出现在请求中。
o The HTTP response code does affect the interpretation of Hobareg. Registration is only considered to have succeeded if the regok value is seen in a 2xx response. 4xx and other errors mean that registration has failed regardless of the value of Hobareg seen. The request method has no influence on the interpretation of Hobareg.
o HTTP响应代码确实会影响Hobareg的解释。只有在2xx响应中看到regok值时，才认为注册成功。4xx和其他错误意味着注册失败，无论看到的Hobareg值是多少。请求方法对Hobareg的解释没有影响。
o Intermediaries never insert, delete, or modify a Hobareg header field.
o 中介机构从不插入、删除或修改Hobareg头字段。
o As a response-only header field, it is not appropriate to list a Hobareg in a Vary response header field.
o 作为仅响应标头字段，在Vary响应标头字段中列出Hobareg是不合适的。
o Hobareg is allowed in trailers.
o 允许在拖车中使用Hobareg。
o As a response-only header field, Hobareg will not be preserved across re-directs.
o 作为仅响应标头字段，Hobareg将不会在重定向中保留。
o Hobareg itself discloses little security- or privacy-sensitive information. If an attacker can somehow detect that a Hobareg header field is being added, then that attacker would know that the UA is in the process of registration, which could be significant. However, it is likely that the set of messages between the UA and server would expose this information in many cases, regardless of whether or not TLS is used. Using TLS is still, however, a good plan.
o Hobareg本身很少披露安全或隐私敏感信息。如果攻击者能够以某种方式检测到正在添加Hobareg头字段，那么该攻击者将知道UA正在注册，这可能非常重要。然而，无论是否使用TLS，UA和服务器之间的消息集在许多情况下都可能会公开此信息。然而，使用TLS仍然是一个好计划。
From the user perspective, the UA having a CPK for a web origin will often appear to be the same as having a way to sign in to an account at that web site. Since users often have more than one UA, and since the CPKs are, in general, UA specific, that raises the question of how the user can sign in to that account from different UAs. And from the server perspective, that turns into the question of how to safely bind different CPKs to one account. In this section, we describe some ways in which this can be done, as well as one way in which this ought not be done.
从用户的角度来看，UA拥有一个用于web源的CPK通常看起来与拥有登录该web站点的帐户的方式相同。由于用户通常有多个UA，而且CPK通常特定于UA，这就提出了一个问题，即用户如何从不同的UA登录到该帐户。从服务器的角度来看，这就变成了如何将不同的CPK安全地绑定到一个帐户的问题。在本节中，我们将介绍一些可以实现这一点的方法，以及一种不应该实现这一点的方法。
Note that the context here is usually that the user has succeeded in registering with one or more UAs (for the purposes of this section, we call this "the first UA" below) and can use HOBA with those, and the user is now adding another UA. The newest UA might or might not have a CPK for the site in question. Since it is in fact trivial, we assume that the site is able to put in place some appropriate, quicker, easier registration for a CPK for the newest UA. The issue then becomes one of binding the CPK from the newest UA with those of other UAs bound to the account.
请注意，这里的上下文通常是用户已成功注册一个或多个UA（在本节中，我们在下面称之为“第一UA”），并且可以将HOBA与这些UA一起使用，并且用户现在正在添加另一个UA。最新的UA可能有也可能没有相关站点的CPK。由于它实际上是微不足道的，我们假设该站点能够为最新的UA提供一些适当、更快、更容易的CPK注册。然后，问题变成将最新UA的CPK与绑定到该帐户的其他UA的CPK绑定。
It is common for a user to have multiple UAs and to want all those UAs to be able to authenticate to a single account. One method to allow a user who has an existing account to be able to authenticate on a second device is to securely transport the private and public keys and the origin information from the first device to the second. If this approach is taken, then there is no impact on the HOBA-http or HOBA-js, so this is a pure UA implementation issue and not discussed further.
一个用户通常拥有多个UAs，并希望所有这些UAs都能够对单个帐户进行身份验证。允许具有现有帐户的用户能够在第二设备上认证的一种方法是将私钥和公钥以及源信息从第一设备安全地传输到第二设备。如果采用这种方法，那么对HOBA http或HOBA js没有影响，因此这是一个纯粹的UA实现问题，没有进一步讨论。
It will be tempting for implementers to use a human-memorable One-Time Password (OTP) in order to "authenticate" binding CPKs to the same account. The workflow here would likely be something along the lines of some server administrative utility generating a human-
对于实现者来说，使用人工记忆一次性密码（OTP）来“验证”绑定到同一帐户的CPK是很有诱惑力的。这里的工作流很可能是类似于某个服务器管理实用程序生成的人工工作流-
memorable OTP such as "1234" and sending that to the user out of band for the user to enter at two web pages, each authenticated via the relevant CPK. While this seems obvious enough and could even be secure enough in some limited cases, we consider that this is too risky to use in the Internet, and so servers SHOULD NOT provide such a mechanism. The reason this is so dangerous is that it would be trivial for an automated client to guess such tokens and "steal" the binding intended for some other user. At any scale, there would always be some in-process bindings so that even with only a trickle of guesses (and hence not being detectable via message volume), an attacker would have a high probability of succeeding in registering a binding with the attacker's CPK.
令人难忘的OTP，如“1234”，并将其发送给带外用户，以便用户在两个网页上输入，每个网页通过相关CPK进行身份验证。虽然这似乎是足够明显的，甚至可以在一些有限的情况下足够安全，我们认为这是太危险的在互联网上使用，因此服务器不应该提供这样的机制。这是如此危险的原因是，对于自动客户端来说，猜测这些令牌并“窃取”其他用户的绑定是微不足道的。在任何规模上，都会存在一些进程内绑定，因此即使只有少量猜测（因此无法通过消息量检测），攻击者也很有可能成功地向攻击者的CPK注册绑定。
This method of binding CPKs together is therefore NOT RECOMMENDED.
因此，不建议使用这种将CPK绑定在一起的方法。
One easy binding method is to simply provide a web page where, using the first UA, the user can generate a URL (containing some "unguessable" cryptographically generated value) that the user then later dereferences on the newest UA. The user could email that URL to herself, for example, or the web server accessed at the first UA could automatically do that.
一种简单的绑定方法是简单地提供一个网页，在该网页中，用户可以使用第一个UA生成一个URL（包含一些“不可用的”加密生成的值），用户随后可以在最新的UA上取消引用该URL。例如，用户可以通过电子邮件将该URL发送给自己，或者在第一次UA访问时访问的web服务器可以自动执行此操作。
Such a URL SHOULD contain at least the equivalent of 128 bits of randomness.
这样的URL应该至少包含128位随机性的等价物。
The user can tell the server it wishes to log out. With HOBA-http, this is done by sending a HOBA-authenticated POST message to the URL ".well-known/hoba/logout" on the site in question. The UA SHOULD also delete session cookies associated with the session so that the user's state is no longer "logged in."
用户可以告诉服务器它希望注销。使用HOBA http，这是通过向相关站点上的URL“.well-known/HOBA/logout”发送一条经过HOBA验证的POST消息来完成的。UA还应删除与会话相关联的会话cookie，以便用户的状态不再为“已登录”
The server MUST NOT allow TLS session resumption for any logged out session.
服务器不得允许任何注销会话的TLS会话恢复。
The server SHOULD also revoke or delete any cookies associated with the session.
服务器还应撤销或删除与会话相关的任何cookie。
The UA can get a "fresh" challenge from the server. In HOBA-http, it sends a POST message to ".well-known/hoba/getchal". If successful, the response MUST contain a fresh (base64url-encoded) HOBA challenge for this origin in the body of the response. Whitespace in the response MUST be ignored.
UA可以从服务器获得“新”挑战。在hobahttp中，它向“.well-known/HOBA/getchal”发送POST消息。如果成功，响应体中必须包含一个新的（base64url编码的）HOBA质询。必须忽略响应中的空白。
RSA-SHA256 MUST be supported. HOBA implementations MUST use RSA-SHA256 if it is provided by the underlying cryptographic libraries. RSA-SHA1 MAY be used. RSA modulus lengths of at least 2048 bits SHOULD be used. RSA indicates the RSASSA-PKCS1-v1_5 algorithm defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. Keys with moduli shorter than 2048 bits SHOULD only be used in cases where generating 2048-bit (or longer) keys is impractical, e.g., on very constrained or old devices.
必须支持RSA-SHA256。如果基础加密库提供RSA-SHA256，则HOBA实现必须使用它。可以使用RSA-SHA1。应使用至少2048位的RSA模数长度。RSA表示[RFC3447]第8.2节中定义的RSASSA-PKCS1-v1_5算法，[SHS]中定义了SHA-1和SHA-256。模短于2048位的密钥只能在无法生成2048位（或更长）密钥的情况下使用，例如，在非常受限的设备或旧设备上。
Binding my CPK with someone else's account would be fun and profitable so SHOULD be appropriately hard. In particular, URLs or other values generated by the server as part of any CPK binding process MUST be hard to guess, for whatever level of difficulty is chosen by the server. The server SHOULD NOT allow a random guess to reveal whether or not an account exists.
将我的CPK与其他人的帐户绑定将是有趣和有利可图的，因此应该是相当困难的。特别是，无论服务器选择了何种难度，服务器作为任何CPK绑定过程的一部分生成的URL或其他值都很难猜测。服务器不应允许随机猜测来显示帐户是否存在。
If key binding was server selected, then a bad actor could bind different accounts belonging to the user from the network with possible bad consequences, especially if one of the private keys was compromised somehow.
如果服务器选择了密钥绑定，那么坏的参与者可能会从网络中绑定属于用户的不同帐户，这可能会带来不良后果，特别是如果其中一个私钥以某种方式被泄露。
When the max-age parameter is not zero, then a HOBA signature has a property that is like a bearer token for the relevant number of seconds: it can be replayed for a server-selected duration. Similarly, for HOBA-js, signatures might be replayable depending on the specific implementation. The security considerations of [RFC6750] therefore apply in any case where the HOBA signature can be replayed. Server administrators can set the max-age to the minimum acceptable value in such cases, which would often be expected to be just a few seconds. There seems to be no reason to ever set the max-age more than a few minutes; the value ought also decrease over time as device capabilities improve. The administrator will most likely want to set the max-age to something that is not too short for the slowest signing device that is significant for that site.
当max age参数不为零时，HOBA签名的属性类似于相关秒数的承载令牌：它可以在服务器选择的持续时间内重播。类似地，对于HOBA js，签名可能是可重放的，具体取决于具体的实现。因此，[RFC6750]的安全注意事项适用于可以重放HOBA签名的任何情况。在这种情况下，服务器管理员可以将max age设置为可接受的最小值，通常只需几秒钟。似乎没有理由将最大年龄设定在几分钟以上；随着设备性能的提高，该值也会随着时间的推移而降低。管理员很可能希望将“最大年龄”设置为对最慢的签名设备而言不太短的值，这对该站点非常重要。
HOBA does, to some extent, impact privacy and could be considered to represent a super-cookie to the server or to any entity on the path from UA to HTTP server that can see the HOBA signature. This is because we need to send a key identifier as part of the signature and that will not vary for a given key. For this reason, and others, it is strongly RECOMMENDED to only use HOBA over server-authenticated TLS and to migrate web sites using HOBA to only use "https" URLs.
在某种程度上，HOBA确实会影响隐私，并且可以被视为向服务器或从UA到HTTP服务器的路径上的任何实体（可以看到HOBA签名）表示超级cookie。这是因为我们需要发送一个密钥标识符作为签名的一部分，并且对于给定的密钥，该标识符不会改变。出于这个原因，以及其他原因，强烈建议只在经过服务器验证的TLS上使用HOBA，并将使用HOBA的网站迁移为只使用“https”URL。
UAs SHOULD provide users a way to manage their CPKs. Ideally, there would be a way for a user to maintain their HOBA details for a site while at the same time deleting other site information such as cookies or non-HOBA HTML5 localStorage. However, as this is likely to be complex, and appropriate user interfaces counterintuitive, we expect that UAs that implement HOBA will likely treat HOBA information as just some more site data that would disappear should the user choose to "forget" that site.
UAs应该为用户提供一种管理其CPK的方法。理想情况下，用户可以在删除其他站点信息（如cookie或非HOBA HTML5 localStorage）的同时维护其站点的HOBA详细信息。然而，由于这可能很复杂，并且适当的用户界面违反直觉，我们预计实现HOBA的UAs可能会将HOBA信息视为更多的站点数据，如果用户选择“忘记”该站点，这些数据将消失。
Device identifiers are intended to specify classes of device in a way that can assist with registration and with presentation to the user of information about previous sessions, e.g., last login time. Device identifier types MUST NOT be privacy sensitive, with values that would allow tracking a user in unexpected ways. In particular, using a device identifier type that is analogous to the International Mobile Equipment Identifier (IMEI) would be a really bad idea and is the reason for the "MUST NOT" above. In that case, "mobile phone" could be an acceptable choice.
设备标识符旨在以一种方式指定设备类别，该方式可以帮助注册和向用户呈现关于先前会话的信息，例如，上次登录时间。设备标识符类型不得对隐私敏感，其值允许以意外方式跟踪用户。特别是，使用类似于国际移动设备标识符（IMEI）的设备标识符类型将是一个非常糟糕的主意，并且是上述“不得”的原因。在这种情况下，“手机”可能是一个可以接受的选择。
If possible, implementations ought to encourage the use of device identifier values that are not personally identifying except for the user concerned; for example, "Alice's mobile" is likely to be chosen and is somewhat identifying, but "Alice's phone: UUID 1234-5567- 89abc-def0" would be a very bad choice.
如果可能的话，实现应该鼓励使用除相关用户之外没有个人识别的设备标识符值；例如，“Alice的手机”可能会被选中，并且在某种程度上具有识别性，但“Alice的手机：UUID 1234-5567-89abc-def0”将是一个非常糟糕的选择。
The use of localStorage (likely with a non-WebCrypto implementation of HOBA-js) will undoubtedly be a cause for concern. localStorage uses the same-origin model that says that the scheme, domain, and port define a localStorage instance. Beyond that, any code executing will have access to private keying material. Of particular concern are Cross-Site Scripting (XSS) attacks, which could conceivably take the keying material and use it to create UAs under the control of an attacker. XSS attacks are, in reality, devastating across the board since they can and do steal credit card information, passwords, perform illicit acts, etc. It's not evident that we are introducing unique threats from which cleartext passwords don't already suffer.
localStorage的使用（可能与HOBA js的非WebCrypto实现一起）无疑会引起关注。localStorage使用与方案、域和端口定义localStorage实例相同的源模型。除此之外，任何执行的代码都可以访问私钥材料。特别值得关注的是跨站点脚本（XSS）攻击，可以想象，这种攻击会获取密钥材料，并使用它在攻击者的控制下创建UAs。实际上，XSS攻击是毁灭性的，因为它们可以而且确实会窃取信用卡信息、密码、执行非法行为等。我们引入的独特威胁并不明显，明文密码还没有受到影响。
Another source of concern is local access to the keys. That is, if an attacker has access to the UA itself, they could snoop on the key through a JavaScript console or find the file(s) that implement localStorage on the host computer. Again, it's not clear that we are worse in this regard because the same attacker could get at browser password files, etc., too. One possible mitigation is to encrypt the keystore with a password/PIN that the user supplies. This may sound counterintuitive, but the object here is to keep passwords off of
另一个令人担忧的问题是本地访问密钥。也就是说，如果攻击者可以访问UA本身，他们可以通过JavaScript控制台窥探密钥，或者找到在主机上实现本地存储的文件。同样，我们也不清楚我们在这方面是否更差，因为同一个攻击者也可能获取浏览器密码文件等。一种可能的缓解措施是使用用户提供的密码/PIN对密钥库进行加密。这听起来可能有悖常理，但这里的目的是防止密码进入
servers to mitigate the multiplier effect of a large-scale compromise (e.g., [ThreatReport]) because of shared passwords across sites.
服务器，以减轻由于跨站点共享密码而导致的大规模危害（例如，[ThreatReport]）的乘数效应。
It's worth noting that HOBA uses asymmetric keys and not passwords when evaluating threats. As various password database leaks have shown, the real threat of a password breach is not just to the site that was breached, it's also to all of the sites on which a user used the same password. That is, the collateral damage is severe because password reuse is common. Storing a password in localStorage would also have a similar multiplier effect for an attacker, though perhaps on a smaller scale than a server-side compromise: one successful crack gains the attacker potential access to hundreds if not thousands of sites the user visits. HOBA does not suffer from that attack multiplier since each asymmetric key pair is unique per site/UA/user.
值得注意的是，HOBA在评估威胁时使用非对称密钥而不是密码。正如各种密码数据库泄漏所显示的，密码泄露的真正威胁不仅仅是被泄露的站点，还包括用户使用相同密码的所有站点。也就是说，由于密码重用很常见，因此附带损害很严重。在localStorage中存储密码也会对攻击者产生类似的倍增效应，尽管其规模可能小于服务器端的危害：一次成功的破解可能会让攻击者访问用户访问的数百甚至数千个站点。由于每个非对称密钥对在每个站点/UA/用户中都是唯一的，所以HOBA不会受到这种攻击乘数的影响。
A shared UA with multiple accounts is possible if the account identifier is stored along with the asymmetric key pair binding them to one another. Multiple entries can be kept, one for each account, and selected by the current user. This, of course, is fraught with the possibility for abuse, since a server is potentially enrolling the device for a long period and the user may not want to have to be responsible for the credential for that long. To alleviate this problem, the user could request that the credential be erased from the browser. Similarly, during the enrollment phase, a user could request that the key pair only be kept for a certain amount of time or that it not be stored beyond the current browser session. However, all such features really ought to be part of the operating system or platform and not part of a HOBA implementation, so those are not discussed further.
如果帐户标识符与将它们彼此绑定的非对称密钥对一起存储，则可以使用多个帐户共享UA。可以保留多个条目，每个帐户一个条目，并由当前用户选择。当然，这充满了滥用的可能性，因为服务器可能会在很长一段时间内注册设备，并且用户可能不想在那么长的时间内对凭据负责。为了缓解此问题，用户可以请求从浏览器中删除凭据。类似地，在注册阶段，用户可以请求仅将密钥对保留一段时间，或者不将其存储在当前浏览器会话之外。然而，所有这些特性实际上都应该是操作系统或平台的一部分，而不是HOBA实现的一部分，因此这些将不再进一步讨论。
The repeated length fields in the HOBA-TBS structure are present in order to ensure that there is no possibility that the catenation of different input values can cause confusion that might lead to an attack, either against HOBA as specified here, or else an attack against some other protocol that reused this to-be-signed structure. Those fields ensure that the mapping from input fields to the HOBA-TBS string is an injective mapping.
HOBA-TBS结构中存在重复长度字段，以确保不同输入值的链接不可能导致混淆，从而可能导致攻击，或者针对此处指定的HOBA，或者针对重用此待签名结构的其他协议的攻击。这些字段确保从输入字段到HOBA-TBS字符串的映射是内射映射。
IANA has made registrations and created new registries as described below.
IANA进行了注册并创建了新的注册，如下所述。
All new registries have been placed beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" category.
所有新的注册表都被置于新的“HTTP源绑定身份验证（HOBA）参数”类别之下。
A new scheme has been registered in the HTTP Authentication Scheme Registry as follows:
已在HTTP身份验证方案注册表中注册了一个新方案，如下所示：
Authentication Scheme Name: HOBA
身份验证方案名称：HOBA
Reference: Section 3 of RFC 7486
参考：RFC 7486第3节
Notes (optional): The HOBA scheme can be used with either HTTP servers or proxies. When used in response to a 407 Proxy Authentication Required indication, the appropriate proxy authentication header fields are used instead, as with any other HTTP authentication scheme.
注意（可选）：HOBA方案可以与HTTP服务器或代理一起使用。当用于响应407代理身份验证要求指示时，将使用适当的代理身份验证头字段，与任何其他HTTP身份验证方案一样。
A new .well-known URI has been registered in the Well-Known URIs registry as described below.
一个新的.well-known URI已在众所周知的URI注册表中注册，如下所述。
URI Suffix: hoba
URI后缀：hoba
Change Controller: IETF
更改控制器：IETF
Reference: Section 6 of RFC 7486
参考：RFC 7486第6节
Related Information: N/A
相关信息：不适用
A new HOBA signature algorithms registry has been created as follows, with Specification Required as the registration procedure. New HOBA signature algorithms SHOULD be in use with other IETF Standards Track protocols before being added to this registry.
新的HOBA签名算法注册表已创建如下，注册程序需要规范。在添加到此注册表之前，新的HOBA签名算法应与其他IETF标准跟踪协议一起使用。
Number Meaning Reference
----------- ------------------------------ ------------
0 RSA-SHA256 RFC 7486
1 RSA-SHA1 RFC 7486
Number Meaning Reference
----------- ------------------------------ ------------
0 RSA-SHA256 RFC 7486
1 RSA-SHA1 RFC 7486
RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].
RSA在[RFC3447]第8.2节中有定义，SHA-1和SHA-256在[SHS]中有定义。
For this registry, the number column should contain a small positive integer. Following the ABNF in Figure 1, the maximum value for this is decimal 99.
对于此注册表，数字列应包含一个小的正整数。在图1中的ABNF之后，其最大值为十进制99。
A new HOBA Key Identifier Types registry has been created as follows, with Specification Required as the registration procedure.
新的HOBA密钥标识符类型注册表已创建如下，注册过程需要规范。
Number Meaning Reference
----------- ------------------------------ ------------
0 a hashed public key [RFC6698]
1 a URI [RFC3986]
2 an unformatted string, at the RFC 7486
user's/UA's whim
Number Meaning Reference
----------- ------------------------------ ------------
0 a hashed public key [RFC6698]
1 a URI [RFC3986]
2 an unformatted string, at the RFC 7486
user's/UA's whim
For the number 0, hashed public keys are as done in DNS-Based Authentication of Named Entities (DANE) [RFC6698].
对于数字0，哈希公钥与基于DNS的命名实体身份验证（DANE）[RFC6698]中的操作相同。
For this registry, the number column should contain a small positive integer.
对于此注册表，数字列应包含一个小的正整数。
A new HOBA Device Identifier Types registry has been created as follows, with Specification Required as the registration procedure.
已创建一个新的HOBA设备标识符类型注册表，如下所示，注册过程需要规范。
The designated expert for this registry is to carefully pay attention to the notes on this field in Section 8.1, in particular, the "MUST NOT" stated therein.
本登记册的指定专家应仔细注意第8.1节中关于该领域的注释，尤其是其中所述的“不得”。
Number Meaning Reference
----------- ------------------------------ -----------
0 an unformatted string, at the RFC 7486
user's/UA's whim
Number Meaning Reference
----------- ------------------------------ -----------
0 an unformatted string, at the RFC 7486
user's/UA's whim
For this registry, the number column should contain a small positive integer.
对于此注册表，数字列应包含一个小的正整数。
A new identifier has been registered in the Permanent Message Header Field Names registry as described below.
已在永久消息头字段名称注册表中注册了一个新标识符，如下所述。
Header Field Name: Hobareg
标题字段名称：Hobareg
Protocol: http (RFC 7230)
协议：http（RFC 7230）
Status: experimental
现状：实验性
Author/Change controller: IETF
作者/变更控制员：IETF
Reference: Section 6.1.1 of RFC 7486
参考：RFC 7486第6.1.1节
Related information: N/A
相关信息：不适用
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月<http://www.rfc-editor.org/info/rfc3447>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 57852010年4月<http://www.rfc-editor.org/info/rfc5785>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月<http://www.rfc-editor.org/info/rfc6454>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 67502012年10月<http://www.rfc-editor.org/info/rfc6750>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[SHS]NIST，“安全哈希标准（SHS）”，FIPS PUB 180-42012年3月。
[Bonneau] Bonneau, J., "The Science of Guessing: Analyzing an Anonymized Corpus of 70 Million Passwords", IEEE Symposium on Security and Privacy 538-552, 2012.
[Bonneau]Bonneau，J.，“猜测的科学：分析7000万个密码的匿名语料库”，IEEE安全和隐私研讨会538-5522012。
[MI93] Mitchell, C. and A. Thomas, "Standardising authentication protocols based on public key techniques", Journal of Computer Security Volume 2, 23-36, 1993.
[MI93]Mitchell，C.和A.Thomas，“基于公钥技术的认证协议标准化”，《计算机安全杂志》第2卷，23-361993年。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年9月<http://www.rfc-editor.org/info/rfc6376>.
[ThreatReport] Sophos, "Security Threat Report 2013", January 2013, <http://www.sophos.com/en-us/medialibrary/pdfs/other/ sophossecuritythreatreport2013.pdf>.
【威胁报告】Sophos，“2013年安全威胁报告”，2013年1月<http://www.sophos.com/en-us/medialibrary/pdfs/other/ sophossecuritythreatreport2013.pdf>。
By far, the most common mechanism for web authentication is passwords that can be remembered by the user, called "human-memorable passwords". There is plenty of good research on how users typically use human-memorable passwords (e.g., see [Bonneau]), but some of the highlights are that users typically try hard to reuse passwords on as many web sites as possible, and that web sites often use either email addresses or users' names as the identifiers that go with these passwords.
到目前为止，最常见的web身份验证机制是用户可以记住的密码，称为“人类记忆密码”。关于用户通常如何使用人类记忆密码（例如，参见[Bonneau]），有很多很好的研究，但其中一些亮点是，用户通常会在尽可能多的网站上尝试重复使用密码，网站通常使用电子邮件地址或用户名作为这些密码的标识符。
If an attacker gets access to the database of memorizable passwords, that attacker can impersonate any of the users. Even if the breach is discovered, the attacker can still impersonate users until every password is changed. Even if all the passwords are changed or at least made unusable, the attacker now possesses a list of likely username/password pairs that might exist on other sites.
如果攻击者能够访问可记忆密码数据库，则该攻击者可以模拟任何用户。即使发现漏洞，攻击者仍然可以模拟用户，直到更改每个密码。即使所有密码都已更改或至少无法使用，攻击者现在仍拥有可能存在于其他站点上的用户名/密码对列表。
Using memorizable passwords on unencrypted channels also poses risks to the users. If a web site uses either the HTTP Basic authentication method, or an HTML form that does no cryptographic protection of the password in transit, a passive attacker can see the password and immediately impersonate the user. If a hash-based authentication scheme such as HTTP Digest authentication is used, a passive attacker still has a high chance of being able to determine the password using a dictionary of known passwords.
在未加密的通道上使用可记忆的密码也会给用户带来风险。如果网站使用HTTP基本身份验证方法或对传输中的密码没有加密保护的HTML表单，则被动攻击者可以看到密码并立即模拟用户。如果使用基于散列的身份验证方案（如HTTP摘要身份验证），则被动攻击者仍然很有可能使用已知密码字典确定密码。
Note that passwords that are not human-memorable are still subject to database attack, though they are of course unlikely to be reused across many systems. Similarly, database attacks of some form or other will work against any password-based authentication scheme, regardless of the cryptographic protocol used. So for example, zero-knowledge or Password-Authenticated Key Exchange (PAKE) schemes, though making use of elegant cryptographic protocols, remain as vulnerable to what is clearly the most common exploit seen when it comes to passwords. HOBA is, however, not vulnerable to database theft.
请注意，非人类记忆的密码仍然会受到数据库攻击，尽管它们当然不太可能在许多系统中重复使用。类似地，无论使用何种加密协议，某种形式或其他形式的数据库攻击都会针对任何基于密码的身份验证方案。因此，例如，零知识或密码认证密钥交换（PAKE）方案虽然使用了优雅的密码协议，但仍然容易受到密码方面最常见的攻击。然而，HOBA不易受到数据库盗窃的攻击。
The following values show an example of HOBA-http authentication to the origin "https://example.com:443". Carriage returns have been added and need to be removed to validate the example.
以下值显示了到源站的HOBA http身份验证示例”https://example.com:443". 已添加回车，需要删除回车以验证示例。
Public Key:
公钥：
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
DQIDAQAB
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
DQIDAQAB
-----END PUBLIC KEY-----
Origin: https://example.com:443
Origin: https://example.com:443
Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
关键标识符：vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
Signature algorithm: RSA-SHA256 ("0")
签名算法：RSA-SHA256（“0”）
Nonce: Pm3yUW-sW5Q
暂时名称：Pm3yUW-sW5Q
Signature:
签名：
VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI S13qQA43m4IMExkbApqrSg
2.一个中国政府对一个中国政府提出了一个中国政府对一个中国政府对一个中国政府在一个中国政府对一个中国政府在一个中国政府对一个中国政府对一个中国政府对一个中国政府的4个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府的一个中国政府对一个中国政府的一个中国政府对中国政府对中国政府的一个中国政府对一个中国政府在一个中国政府对一个中国政府一个中国政府一个中国政府对中国政府一个中国政府对中国政府的政府的政策的一个中国政府一个中国政府在一个中国政府对中国政府对中国政府的政策的政策的承诺承诺，在一个中国政府在一个中国政府对中国政府在一个中国政府对中国政府对中国政府的政府的政府的政策的承诺在在中国政府的承诺BK34EUWG9KI S13qQA43m4IMExkbApqrSg
Authorization Header:
授权标头：
Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0 i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr 96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k IS13qQA43m4IMExkbApqrSg"
授权：HOBA结果="VESSCAMS2KZE4FFOG32UYCJPHUQ6-k3W.PUE77W0LYLHYPHKHBQAQHUGC751GIOVV4/7pSlo9jc=.Pm3yUW-sW5Q.VD-0LGVBVEVJFQ4XED35FJNORZJ2OQMX5W8E52DGVXFD6R0RYESHCD31YKH0IZIZIZIZHX7BE4X9YP-9YP-9FMBCEWKHJWYKKWKWKWAZ-IH1TB-U66miU ZGZGZZ2RKJJJJ2RKJJJJJJJJJ2RKZ2RK6GZ2RKKKJJJJJJJJJJJJJJJJ0GZ2RKZ2RKZ2RKJ6GZZZPtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr 96ZJ2I9LE6UKSUDLCD2EEESEVUR——4OGTRGJYYSHZKDVSKAI7OOQBK34EUWG9K是13QQA43M4IMEXKBAPQRSG“
Acknowledgements
致谢
Thanks to the following for good comments received during the preparation of this specification: Richard Barnes, David Black, Alissa Cooper, Donald Eastlake, Amos Jeffries, Benjamin Kaduk, Watson Ladd, Barry Leiba, Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Julian Reschke, Pete Resnick, Michael Richardson, Yaron Sheffer, and Michael Sweet. All errors and stupidities are of course the editors' fault.
感谢以下在本规范编制过程中收到的好评：理查德·巴恩斯、大卫·布莱克、艾莉莎·库珀、唐纳德·伊斯特莱克、阿莫斯·杰弗里斯、本杰明·卡杜克、沃森·拉德、巴里·莱巴、马特·莱宾斯基、伊拉里·柳斯瓦拉、詹姆斯·马格尔、亚历克赛·梅尔尼科夫、凯瑟琳·莫里亚蒂、约夫·尼尔、马克·诺丁汉、朱利安·雷什克、，皮特·雷斯尼克、迈克尔·理查森、亚龙·谢弗和迈克尔·斯威特。所有的错误和愚蠢当然都是编辑的错。
Authors' Addresses
作者地址
Stephen Farrell Trinity College Dublin Dublin 2 Ireland
斯蒂芬·法雷尔三一学院都柏林爱尔兰都柏林2
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Michael Thomas Phresheez
迈克尔·托马斯·弗雷希兹
EMail: mike@phresheez.com
EMail: mike@phresheez.com