added errata 3500 and improved section 1.2

rickryo · May 4, 2015 · 4cd35d5 · 4cd35d5
1 parent 2ef0489
commit 4cd35d5
Show file tree

Hide file tree

Showing 6 changed files with 39 additions and 10 deletions.
diff --git a/Errata/errata.3500.md b/Errata/errata.3500.md
@@ -0,0 +1,27 @@
+勘误编号：3500
+
+状态：已核实
+
+类型：编辑
+
+报告者：John Field
+
+报告日期：2013-02-26
+
+审核者：Stephen Farrell
+
+审核日期：2013-03-16
+
+第[4.1](../Section04/4.1.md)节：
+
+- （E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。
+
+应该是：
+
+- （E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向（资源所有者的用户代理）到客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。
+
+备注：
+
+问题中的URI是用于重定向资源所有者的用户代理回到客户端传送代码的URI。（E）步骤中原文好像说该URI用于重定向客户端，但是我认为这是对“客户端”这个词的不明确／不准确的使用。OAuth客户端不会使用URI被重定向，资源所有者的用户代理会被重定向**到**客户端。
+
+插入的“（资源所有者的用户代理）”会更准确但是可能会太冗长了。我觉得，至少，我们必须说“……该URI用于在步骤（C）中重定向**到**客户端。”
diff --git a/Errata/errata.md b/Errata/errata.md
@@ -1 +1,2 @@
-- [3446](errata.3446.md)
+- [3446](errata.3446.md)
+- [3500](errata.3500.md)
diff --git a/Section01/1.2.md b/Section01/1.2.md
@@ -19,15 +19,15 @@
      +--------+                               +---------------+
 图1：抽象的协议流程
 
-图1中所示的抽象OAuth 2.0流程描述了四个角色之间的交互，包括以下步骤：
-- （A）客户端向从资源所有者请求授权。授权请求可以直接向资源所有者发起（如图所示），或者更可取的是通过作为中介的授权服务器间接发起。
-- （B）客户端收到授权许可，这是一个代表资源所有者的授权的凭据，使用本规范中定义的四种许可类型之一或  者使用扩展许可类型表示。授权许可类型取决于客户端请求授权所使用的方式以及授权服务器支持的类型。
-- （C）客户端与授权服务器进行身份认证并出示授权许可请求访问令牌。
+图1中所示的抽象的OAuth 2.0流程描述了四种角色之间的交互，包括以下步骤：
+- （A）客户端从资源所有者处请求授权。授权请求可以直接向资源所有者发起（如图所示），或者更可取的是通过授权服务器作为中介间接发起。
+- （B）客户端收到授权许可，这是一个代表资源所有者的授权的凭据，使用本规范中定义的四种许可类型之一或者使用扩展许可类型表示。授权许可类型取决于客户端请求授权所使用的方法以及授权服务器支持的类型。
+- （C）客户端与授权服务器进行身份认证并出示授权许可以请求访问令牌。
 - （D）授权服务器验证客户端身份并验证授权许可，若有效则颁发访问令牌。 
 - （E）客户端从资源服务器请求受保护资源并出示访问令牌进行身份验证。
-- （F）资源服务器验证访问令牌，若有效则满足该请求。
+- （F）资源服务器验证访问令牌，若有效则处理该请求。
 
-客户端用于从资源所有者获得授权许可（步骤（A）和（B）所示）的更好方法是使用授权服务器作为中介，如                    [4.1节](../Section04/4.1.md)图3所示。
+客户端从资源所有者获得授权许可（步骤（A）和（B）所示）的更好方法是使用授权服务器作为中介，如[4.1节](../Section04/4.1.md)图3所示。
 
 ## Links
 

diff --git a/Section01/1.md b/Section01/1.md
@@ -10,7 +10,7 @@
 
 OAuth通过引入授权层以及从资源所有者角色分离出客户端角色来解决这些问题。在OAuth中，客户端请求对受资源所有者控制且托管在资源服务器上的资源的访问权限，并授予一组不同于资源所有者所拥有的凭据。
 
-作为使用资源所有者的凭据访问受保护资源的替代，客户端获得一个访问令牌————一个代表特定作用域、生命周期以及其他访问权限属性的字符串。访问令牌由授权服务器在资源所有者认可的情况下颁发给第三方客户端。客户端使用访问令牌访问托管在资源服务器上的受保护资源。
+作为使用资源所有者的凭据访问受保护资源的替代，客户端获得一个访问令牌———一个代表特定作用域、生命周期以及其他访问权限属性的字符串。访问令牌由授权服务器在资源所有者认可的情况下颁发给第三方客户端。客户端使用访问令牌访问托管在资源服务器上的受保护资源。
 
 例如，终端用户（资源所有者）可以许可一个打印服务（客户端）访问她存储在图片分享网站（资源服务器）上的受保护图片，而无需与打印服务分享自己的用户名和密码，而是，她直接与图片分享网站信任的服务器（授权服务器）进行身份验证，该服务器颁发给打印服务具体的委托凭据（访问令牌）。
 

diff --git a/Section04/4.1.md b/Section04/4.1.md
@@ -35,7 +35,7 @@
 - （B）授权服务器验证资源拥有者的身份（通过用户代理），并确定资源所有者是否授予或拒绝客户端的访问请求。
 - （C）假设资源所有者许可访问，授权服务器使用之前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI包括授权码和之前客户端提供的任何本地状态。
 - （D）客户端通过包含上一步中收到的授权码从授权服务器的令牌端点请求访问令牌。当发起请求时，客户端与授权服务器进行身份验证。客户端包含用于获得授权码的重定向URI来用于验证。
-- （E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。
+- （E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向（资源所有者的用户代理）到客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。
 
 - 4.1.1. [授权请求](4.1.1.md)
 - 4.1.2. [授权响应](4.1.2.md)

diff --git a/TableofContents.md b/TableofContents.md
@@ -114,4 +114,5 @@
 - 附录B. [使用application/x-www-form-urlencoded媒体类型](AppendixB/b.md)
 - 附录C. [致谢](AppendixC/c.md)
 - [勘误](Errata/errata.md)
-  - [3446](Errata/errata.3446.md)
+  - [3446](Errata/errata.3446.md)
+  - [3500](Errata/errata.3500.md)