Script updating gh-pages from 0a7303f. [ci skip]

draft-ietf-oauth-v2-1.html

@@ -2846,18 +2846,18 @@ <h4 id="name-token-request">
 format per <a href="#application-x-www-form-urlencoded" class="auto internal xref">Appendix B</a> with a character encoding of UTF-8 in the HTTP
 request content:<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
 <span class="break"></span><dl class="dlParallel" id="section-3.2.2-2">
-            <dt id="section-3.2.2-2.1">"client_id":</dt>
+            <dt id="section-3.2.2-2.1">"grant_type":</dt>
             <dd style="margin-left: 1.5em" id="section-3.2.2-2.2">
-              <p id="section-3.2.2-2.2.1">REQUIRED, if the client is not authenticating with the
-authorization server as described in <a href="#token-endpoint-client-authentication" class="auto internal xref">Section 3.2.1</a>.<a href="#section-3.2.2-2.2.1" class="pilcrow">¶</a></p>
+              <p id="section-3.2.2-2.2.1">REQUIRED.  Identifier of the grant type the client uses with the particular token request.
+This specification defines the values <code>authorization_code</code>, <code>refresh_token</code>, and <code>client_credentials</code>.
+The grant type determines the further parameters required or supported by the token request. The
+details of those grant types are defined below.<a href="#section-3.2.2-2.2.1" class="pilcrow">¶</a></p>
 </dd>
             <dd class="break"></dd>
-<dt id="section-3.2.2-2.3">"grant_type":</dt>
+<dt id="section-3.2.2-2.3">"client_id":</dt>
             <dd style="margin-left: 1.5em" id="section-3.2.2-2.4">
-              <p id="section-3.2.2-2.4.1">REQUIRED.  Identifier of the grant type the client uses with the particular token request.
-This specification defines the values <code>authorization_code</code>, <code>refresh_token</code>, and <code>client_credentials</code>.
-The grant type determines the further parameters required or supported by the token request. The
-details of those grant types are defined below.<a href="#section-3.2.2-2.4.1" class="pilcrow">¶</a></p>
+              <p id="section-3.2.2-2.4.1">OPTIONAL.  The client identifier is needed when a form of client authentication that
+relies on the parameter is used, or the <code>grant_type</code> requires identification of public clients.<a href="#section-3.2.2-2.4.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 </dl>
@@ -3562,7 +3562,7 @@ <h4 id="name-token-endpoint-extension">
 <a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-token-endpoint-extension" class="section-name selfRef">Token Endpoint Extension</a>
           </h4>
 <p id="section-4.1.3-1">The authorization grant type is identified at the token endpoint with the <code>grant_type</code> value of <code>authorization_code</code>.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
-<p id="section-4.1.3-2">If this value is set, the following additional token request parameters beyond <a href="#token-request" class="auto internal xref">Section 3.2.2</a> are required:<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-2">If this value is set, the following additional token request parameters beyond <a href="#token-request" class="auto internal xref">Section 3.2.2</a> are supported:<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
 <span class="break"></span><dl class="dlParallel" id="section-4.1.3-3">
             <dt id="section-4.1.3-3.1">"code":</dt>
             <dd style="margin-left: 1.5em" id="section-4.1.3-3.2">
@@ -3574,6 +3574,12 @@ <h4 id="name-token-endpoint-extension">
             <dd style="margin-left: 1.5em" id="section-4.1.3-3.4">
               <p id="section-4.1.3-3.4.1">REQUIRED, if the <code>code_challenge</code> parameter was included in the authorization
 request. MUST NOT be used otherwise. The original code verifier string.<a href="#section-4.1.3-3.4.1" class="pilcrow">¶</a></p>
+</dd>
+            <dd class="break"></dd>
+<dt id="section-4.1.3-3.5">"client_id":</dt>
+            <dd style="margin-left: 1.5em" id="section-4.1.3-3.6">
+              <p id="section-4.1.3-3.6.1">REQUIRED, if the client is not authenticating with the authorization server
+as described in <a href="#token-endpoint-client-authentication" class="auto internal xref">Section 3.2.1</a>.<a href="#section-4.1.3-3.6.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 </dl>
@@ -3669,7 +3675,7 @@ <h3 id="name-client-credentials-grant">
           <h4 id="name-token-endpoint-extension-2">
 <a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-token-endpoint-extension-2" class="section-name selfRef">Token Endpoint Extension</a>
           </h4>
-<p id="section-4.2.1-1">The authorization grant type is identified at the token endpoint with the <code>grant_type</code> value of <code>client_credentials</code>.<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.2.1-1">The client credentials grant type is identified at the token endpoint with the <code>grant_type</code> value of <code>client_credentials</code>.<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.2.1-2">If this value is set, the following additional token request parameters beyond <a href="#token-request" class="auto internal xref">Section 3.2.2</a> are supported:<a href="#section-4.2.1-2" class="pilcrow">¶</a></p>
 <span class="break"></span><dl class="dlParallel" id="section-4.2.1-3">
             <dt id="section-4.2.1-3.1">"scope":</dt>
@@ -3725,8 +3731,8 @@ <h3 id="name-refresh-token-grant">
           <h4 id="name-token-endpoint-extension-3">
 <a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-token-endpoint-extension-3" class="section-name selfRef">Token Endpoint Extension</a>
           </h4>
-<p id="section-4.3.1-1">The authorization grant type is identified at the token endpoint with the <code>grant_type</code> value of <code>refresh_token</code>.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.3.1-2">If this value is set, the following additional parameters beyond <a href="#token-request" class="auto internal xref">Section 3.2.2</a> are required/supported:<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-1">The refresh token grant type is identified at the token endpoint with the <code>grant_type</code> value of <code>refresh_token</code>.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-2">If this value is set, the following additional parameters beyond <a href="#token-request" class="auto internal xref">Section 3.2.2</a> are supported:<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
 <span class="break"></span><dl class="dlParallel" id="section-4.3.1-3">
             <dt id="section-4.3.1-3.1">"refresh_token":</dt>
             <dd style="margin-left: 1.5em" id="section-4.3.1-3.2">
@@ -4801,7 +4807,7 @@ <h4 id="name-http-307-redirect">
 <p id="section-7.5.4-3">If the status code 307 were used for redirection, the user agent
 would send the user credentials via a POST request to the client.<a href="#section-7.5.4-3" class="pilcrow">¶</a></p>
 <p id="section-7.5.4-4">This discloses the sensitive credentials to the client.  If the
-relying party is malicious, it can use the credentials to impersonate
+client is malicious, it can use the credentials to impersonate
 the user at the AS.<a href="#section-7.5.4-4" class="pilcrow">¶</a></p>
 <p id="section-7.5.4-5">The behavior might be unexpected for developers, but is defined in
 Section 15.4.8 of <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>.  This status code does not require the user
@@ -6300,7 +6306,7 @@ <h2 id="name-acknowledgements">
 <a href="#appendix-D" class="section-number selfRef">Appendix D. </a><a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
       </h2>
 <p id="appendix-D-1">This specification is the work of the OAuth Working Group, and its starting point was based on the contents of the following specifications: OAuth 2.0 Authorization Framework (RFC 6749), OAuth 2.0 for Native Apps (RFC 8252), OAuth Security Best Current Practice, and OAuth 2.0 for Browser-Based Apps. The editors would like to thank everyone involved in the creation of those specifications upon which this is built.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
-<p id="appendix-D-2">The editors would also like to thank the following individuals for their ideas, feedback, corrections, and wording that helped shape this version of the specification: Vittorio Bertocci, Michael Jones, Justin Richer, Daniel Fett, Brian Campbell, Joseph Heenan, Roberto Polli, Andrii Deinega, Falko, Michael Peck, Bob Hamburg, Deng Chao, Karsten Meyer zu Selhausen, and Filip Skokan.<a href="#appendix-D-2" class="pilcrow">¶</a></p>
+<p id="appendix-D-2">The editors would also like to thank the following individuals for their ideas, feedback, corrections, and wording that helped shape this version of the specification: Vittorio Bertocci, Michael Jones, Justin Richer, Daniel Fett, Brian Campbell, Joseph Heenan, Roberto Polli, Andrii Deinega, Falko, Michael Peck, Bob Hamburg, Deng Chao, Karsten Meyer zu Selhausen, Filip Skokan, and Tim Würtele.<a href="#appendix-D-2" class="pilcrow">¶</a></p>
 <p id="appendix-D-3">Discussions around this specification have also occurred at the OAuth Security Workshop in 2021 and 2022. The authors thank the organizers of the workshop (Guido Schmitz, Steinar Noem, and Daniel Fett) for hosting an event that's conducive to collaboration and community input.<a href="#appendix-D-3" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -6320,6 +6326,12 @@ <h2 id="name-document-history">
 </li>
         <li class="normal" id="appendix-E-3.3">
           <p id="appendix-E-3.3.1">Updated reference for case insensitivity of auth scheme to HTTP instead of ABNF<a href="#appendix-E-3.3.1" class="pilcrow">¶</a></p>
+</li>
+        <li class="normal" id="appendix-E-3.4">
+          <p id="appendix-E-3.4.1">Corrected an instance of "relying party" vs "client"<a href="#appendix-E-3.4.1" class="pilcrow">¶</a></p>
+</li>
+        <li class="normal" id="appendix-E-3.5">
+          <p id="appendix-E-3.5.1">Moved <code>client_id</code> requirement to the individual grant types<a href="#appendix-E-3.5.1" class="pilcrow">¶</a></p>
 </li>
       </ul>
 <p id="appendix-E-4">-11<a href="#appendix-E-4" class="pilcrow">¶</a></p>

draft-ietf-oauth-v2-1.txt

@@ -1279,16 +1279,17 @@ Table of Contents
    format per Appendix B with a character encoding of UTF-8 in the HTTP
    request content:
 
-   "client_id":  REQUIRED, if the client is not authenticating with the
-      authorization server as described in Section 3.2.1.
-
    "grant_type":  REQUIRED.  Identifier of the grant type the client
       uses with the particular token request.  This specification
       defines the values authorization_code, refresh_token, and
       client_credentials.  The grant type determines the further
       parameters required or supported by the token request.  The
       details of those grant types are defined below.
 
+   "client_id":  OPTIONAL.  The client identifier is needed when a form
+      of client authentication that relies on the parameter is used, or
+      the grant_type requires identification of public clients.
+
    Confidential clients MUST authenticate with the authorization server
    as described in Section 3.2.1.
 
@@ -1864,7 +1865,7 @@ Table of Contents
    the grant_type value of authorization_code.
 
    If this value is set, the following additional token request
-   parameters beyond Section 3.2.2 are required:
+   parameters beyond Section 3.2.2 are supported:
 
    "code":  REQUIRED.  The authorization code received from the
       authorization server.
@@ -1873,6 +1874,9 @@ Table of Contents
       included in the authorization request.  MUST NOT be used
       otherwise.  The original code verifier string.
 
+   "client_id":  REQUIRED, if the client is not authenticating with the
+      authorization server as described in Section 3.2.1.
+
    The authorization server MUST return an access token only once for a
    given authorization code.
 
@@ -1954,8 +1958,8 @@ Table of Contents
 
 4.2.1.  Token Endpoint Extension
 
-   The authorization grant type is identified at the token endpoint with
-   the grant_type value of client_credentials.
+   The client credentials grant type is identified at the token endpoint
+   with the grant_type value of client_credentials.
 
    If this value is set, the following additional token request
    parameters beyond Section 3.2.2 are supported:
@@ -2004,11 +2008,11 @@ Table of Contents
 
 4.3.1.  Token Endpoint Extension
 
-   The authorization grant type is identified at the token endpoint with
+   The refresh token grant type is identified at the token endpoint with
    the grant_type value of refresh_token.
 
    If this value is set, the following additional parameters beyond
-   Section 3.2.2 are required/supported:
+   Section 3.2.2 are supported:
 
    "refresh_token":  REQUIRED.  The refresh token issued to the client.
 
@@ -2885,8 +2889,8 @@ Table of Contents
    would send the user credentials via a POST request to the client.
 
    This discloses the sensitive credentials to the client.  If the
-   relying party is malicious, it can use the credentials to impersonate
-   the user at the AS.
+   client is malicious, it can use the credentials to impersonate the
+   user at the AS.
 
    The behavior might be unexpected for developers, but is defined in
    Section 15.4.8 of [RFC9110].  This status code does not require the
@@ -4222,7 +4226,7 @@ Appendix D.  Acknowledgements
    this version of the specification: Vittorio Bertocci, Michael Jones,
    Justin Richer, Daniel Fett, Brian Campbell, Joseph Heenan, Roberto
    Polli, Andrii Deinega, Falko, Michael Peck, Bob Hamburg, Deng Chao,
-   Karsten Meyer zu Selhausen, and Filip Skokan.
+   Karsten Meyer zu Selhausen, Filip Skokan, and Tim Würtele.
 
    Discussions around this specification have also occurred at the OAuth
    Security Workshop in 2021 and 2022.  The authors thank the organizers
@@ -4245,6 +4249,10 @@ Appendix E.  Document History
    *  Updated reference for case insensitivity of auth scheme to HTTP
       instead of ABNF
 
+   *  Corrected an instance of "relying party" vs "client"
+
+   *  Moved client_id requirement to the individual grant types
+
    -11
 
    *  Explicitly mention that Bearer is case insensitive