Skip to content

Commit

Permalink
Script updating gh-pages from 9fea163. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jun 21, 2024
1 parent 219857c commit 4d1c4ab
Show file tree
Hide file tree
Showing 9 changed files with 47 additions and 4,325 deletions.
1,629 changes: 0 additions & 1,629 deletions ack/draft-demarco-oauth-nonce-endpoint.html
View file

This file was deleted.

474 changes: 0 additions & 474 deletions ack/draft-demarco-oauth-nonce-endpoint.txt
View file

This file was deleted.

45 changes: 0 additions & 45 deletions ack/index.html
View file

This file was deleted.

45 changes: 21 additions & 24 deletions draft-demarco-oauth-nonce-endpoint.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,17 +15,17 @@
<meta content="draft-demarco-oauth-nonce-endpoint-latest" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.21.0
Python 3.11.9
Python 3.12.3
ConfigArgParse 1.7
google-i18n-address 3.1.0
intervaltree 3.1.0
Jinja2 3.1.2
lxml 4.9.3
platformdirs 4.2.0
Jinja2 3.1.4
lxml 4.9.4
platformdirs 4.2.2
pycountry 22.3.5
PyYAML 6.0.1
requests 2.31.0
setuptools 68.2.2
setuptools 69.5.1
six 1.16.0
wcwidth 0.2.13
-->
Expand Down Expand Up @@ -1026,11 +1026,11 @@
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">Nonce Endpoint</td>
<td class="right">April 2024</td>
<td class="right">June 2024</td>
</tr></thead>
<tfoot><tr>
<td class="left">Marco &amp; Steele</td>
<td class="center">Expires 20 October 2024</td>
<td class="center">Expires 23 December 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1043,12 +1043,12 @@
<dd class="internet-draft">draft-demarco-oauth-nonce-endpoint-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2024-04-18" class="published">18 April 2024</time>
<time datetime="2024-06-21" class="published">21 June 2024</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-10-20">20 October 2024</time></dd>
<dd class="expires"><time datetime="2024-12-23">23 December 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1097,7 +1097,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 20 October 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 23 December 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1227,7 +1227,7 @@ <h2 id="name-terminology">
<dt id="section-3-1.3">
<strong>Nonce Issuer</strong>:</dt>
<dd style="margin-left: 1.5em" id="section-3-1.4">
<p id="section-3-1.4.1">The entity that generates and provides the Nonce. The Nonce Issuer would typically be the Authorization Server.<a href="#section-3-1.4.1" class="pilcrow"></a></p>
<p id="section-3-1.4.1">The entity that generates and provides the Nonce.<a href="#section-3-1.4.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-3-1.5">
Expand Down Expand Up @@ -1320,7 +1320,7 @@ <h3 id="name-nonce-endpoint-metadata">
<h4 id="name-example-metadata">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-example-metadata" class="section-name selfRef">Example Metadata</a>
</h4>
<p id="section-5.1.1-1">Below is an example of how the Authorization Server Metadata might include the <code>nonce_endpoint</code>:<a href="#section-5.1.1-1" class="pilcrow"></a></p>
<p id="section-5.1.1-1">Below is an example of how an OAuth 2.0 Authorization Server Metadata might include the <code>nonce_endpoint</code>:<a href="#section-5.1.1-1" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-5.1.1-2">
<pre>
{
Expand Down Expand Up @@ -1396,10 +1396,10 @@ <h2 id="name-nonce-response">
<h2 id="name-nonce-endpoint-discovery">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-nonce-endpoint-discovery" class="section-name selfRef">Nonce Endpoint Discovery</a>
</h2>
<p id="section-8-1">When an Authorization Server requires the use of a Nonce in the request for a specific resource and the Client does not provide it in its request,
the Authorization Server <span class="bcp14">MUST</span> return an HTTP response with the HTTP status code <code>400</code> and an <code>error</code> field with the value set to <code>"nonce_required"</code>.<a href="#section-8-1" class="pilcrow"></a></p>
<p id="section-8-2">This response <span class="bcp14">MUST</span> also contain the <code>Nonce-Endpoint-URI</code> HTTP header, with the value set to the URL corresponding to the Nonce Endpoint, where the Client <span class="bcp14">SHOULD</span> request and fetch a new Nonce. Once the Nonce is received, the Client <span class="bcp14">MAY</span> renew the request to the Authorization Server, including the obtained Nonce.<a href="#section-8-2" class="pilcrow"></a></p>
<p id="section-8-3">Below is a non-normative example of an error response issued by an Authorization Server that requires the Nonce in the Client request, the response informs the Client about the Nonce Endpoint where the Nonce should be requested:<a href="#section-8-3" class="pilcrow"></a></p>
<p id="section-8-1">When a server requires the use of a Nonce in the request for a specific resource and the Client does not provide it in its request,
the server <span class="bcp14">MUST</span> return an HTTP response with the HTTP status code <code>400</code> and an <code>error</code> field with the value set to <code>"nonce_required"</code>.<a href="#section-8-1" class="pilcrow"></a></p>
<p id="section-8-2">This response <span class="bcp14">MUST</span> also contain the <code>Nonce-Endpoint-URI</code> HTTP header, with the value set to the URL corresponding to the Nonce Endpoint, where the Client <span class="bcp14">SHOULD</span> request and fetch a new Nonce. Once the Nonce is received, the Client <span class="bcp14">MAY</span> renew the request to the server, including the obtained Nonce.<a href="#section-8-2" class="pilcrow"></a></p>
<p id="section-8-3">Below is a non-normative example of an error response issued by an server that requires the Nonce in the Client request, the response informs the Client about the Nonce Endpoint where the Nonce should be requested:<a href="#section-8-3" class="pilcrow"></a></p>
<div class="lang-http sourcecode" id="section-8-4">
<pre>
HTTP/1.1 400 Bad Request
Expand All @@ -1408,11 +1408,11 @@ <h2 id="name-nonce-endpoint-discovery">
{
"error": "nonce_required",
"error_description":
"Authorization server requires the nonce in the request"
"Server requires the nonce in the request"
}
</pre><a href="#section-8-4" class="pilcrow"></a>
</div>
<p id="section-8-5">In cases where, for some reasons, a correctly issued Nonce can no longer be considered valid by the Authorization Server that receives it, the Authorization Server <span class="bcp14">MUST</span> return the generic error <code>"nonce_required"</code> reporting the same description as <code>"error_description"</code>, as if the Nonce had not been received. The cases when an issued Nonce is considered no longer valid <span class="bcp14">MAY</span> be caused by the rotation of the encryption keys, its expiration or other specific conditions internal to an implementation.<a href="#section-8-5" class="pilcrow"></a></p>
<p id="section-8-5">In cases where, for some reasons, a correctly issued Nonce can no longer be considered valid by the server that receives it, the server <span class="bcp14">MUST</span> return the generic error <code>"nonce_required"</code> reporting the same description as <code>"error_description"</code>, as if the Nonce had not been received. The cases when an issued Nonce is considered no longer valid <span class="bcp14">MAY</span> be caused by the rotation of the encryption keys, its expiration or other specific conditions internal to an implementation.<a href="#section-8-5" class="pilcrow"></a></p>
</section>
</div>
<div id="non-normative-examples-of-a-nonce-payload">
Expand Down Expand Up @@ -1481,16 +1481,13 @@ <h2 id="name-considerations-about-nonce-">
<p id="section-11-3">The main differences between the use of the <code>jti</code> and the Nonces can be summarized as follows:<a href="#section-11-3" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-11-4">
<li id="section-11-4.1">
<p id="section-11-4.1.1"><strong>Generation</strong>: Nonces are generated by the server, while <code>jti</code> is generated by the Client.<a href="#section-11-4.1.1" class="pilcrow"></a></p>
<p id="section-11-4.1.1"><strong>Generation</strong>: Nonces and jti can be are generated both by the server and the client.<a href="#section-11-4.1.1" class="pilcrow"></a></p>
</li>
<li id="section-11-4.2">
<p id="section-11-4.2.1"><strong>Storage</strong>: Nonces can be self-authenticating and self-contained and therefore need not be stored. A common way to achieve this is for the Nonce to contain content encrypted to the Authorization Server that creates it. On the other hand, checking <code>jti</code> properly definitely requires a store that is shared across all domains that the associated JWT can be presented in.<a href="#section-11-4.2.1" class="pilcrow"></a></p>
<p id="section-11-4.2.1"><strong>Lifetime</strong>: The life span difference between a Nonce and a <code>jti</code> is significant. Nonces are kept just until the Client responds, which happens practically immediately after they are obtained, resulting in a very short lifespan. A <code>jti</code>, on the other hand, must be stored until the expiration window of its associated JWT expires, which is a substantially longer length than that of a Nonce.<a href="#section-11-4.2.1" class="pilcrow"></a></p>
</li>
<li id="section-11-4.3">
<p id="section-11-4.3.1"><strong>Lifetime</strong>: The life span difference between a Nonce and a <code>jti</code> is significant. Nonces are kept just until the Client responds, which happens practically immediately after they are obtained, resulting in a very short lifespan. A <code>jti</code>, on the other hand, must be stored until the expiration window of its associated JWT expires, which is a substantially longer length than that of a Nonce.<a href="#section-11-4.3.1" class="pilcrow"></a></p>
</li>
<li id="section-11-4.4">
<p id="section-11-4.4.1"><strong>Security</strong>: Nonces prevent replay attacks by ensuring that the proof of possession is fresh. On the other hand, <code>jti</code> does not guarantee freshness and using client-generated timestamps has problems, even for non-attacking Clients (e.g. devices with incorrect time-zones or daylight saving settings).<a href="#section-11-4.4.1" class="pilcrow"></a></p>
<p id="section-11-4.3.1"><strong>Freshness</strong>: Nonces prevent replay attacks by ensuring that the proof of possession is fresh. On the other hand, <code>jti</code> does not guarantee freshness and using client-generated timestamps has problems, even for non-attacking Clients (e.g. devices with incorrect time-zones or daylight saving settings).<a href="#section-11-4.3.1" class="pilcrow"></a></p>
</li>
</ol>
</section>
Expand Down
61 changes: 26 additions & 35 deletions draft-demarco-oauth-nonce-endpoint.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@
Network Working Group G. D. Marco
Internet-Draft Independent
Intended status: Informational O. Steele
Expires: 20 October 2024 Transmute
18 April 2024
Expires: 23 December 2024 Transmute
21 June 2024


The Nonce Endpoint
Expand Down Expand Up @@ -46,7 +46,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 October 2024.
This Internet-Draft will expire on 23 December 2024.

Copyright Notice

Expand Down Expand Up @@ -114,7 +114,6 @@ Table of Contents
some scope.

*Nonce Issuer*: The entity that generates and provides the Nonce.
The Nonce Issuer would typically be the Authorization Server.

*Nonce Endpoint*: The HTTP endpoint provided by the Nonce Issuer for
the issuance of the Nonces.
Expand Down Expand Up @@ -185,8 +184,8 @@ Table of Contents

5.1.1. Example Metadata

Below is an example of how the Authorization Server Metadata might
include the nonce_endpoint:
Below is an example of how an OAuth 2.0 Authorization Server Metadata
might include the nonce_endpoint:

{
"issuer": "https://server.example.com",
Expand Down Expand Up @@ -244,40 +243,39 @@ Table of Contents

8. Nonce Endpoint Discovery

When an Authorization Server requires the use of a Nonce in the
request for a specific resource and the Client does not provide it in
its request, the Authorization Server MUST return an HTTP response
with the HTTP status code 400 and an error field with the value set
to "nonce_required".
When a server requires the use of a Nonce in the request for a
specific resource and the Client does not provide it in its request,
the server MUST return an HTTP response with the HTTP status code 400
and an error field with the value set to "nonce_required".

This response MUST also contain the Nonce-Endpoint-URI HTTP header,
with the value set to the URL corresponding to the Nonce Endpoint,
where the Client SHOULD request and fetch a new Nonce. Once the
Nonce is received, the Client MAY renew the request to the
Authorization Server, including the obtained Nonce.
Nonce is received, the Client MAY renew the request to the server,
including the obtained Nonce.

Below is a non-normative example of an error response issued by an
Authorization Server that requires the Nonce in the Client request,
the response informs the Client about the Nonce Endpoint where the
Nonce should be requested:
server that requires the Nonce in the Client request, the response
informs the Client about the Nonce Endpoint where the Nonce should be
requested:

HTTP/1.1 400 Bad Request
Nonce-Endpoint-URI: https://server.example.org/nonce-endpoint

{
"error": "nonce_required",
"error_description":
"Authorization server requires the nonce in the request"
"Server requires the nonce in the request"
}

In cases where, for some reasons, a correctly issued Nonce can no
longer be considered valid by the Authorization Server that receives
it, the Authorization Server MUST return the generic error
"nonce_required" reporting the same description as
"error_description", as if the Nonce had not been received. The
cases when an issued Nonce is considered no longer valid MAY be
caused by the rotation of the encryption keys, its expiration or
other specific conditions internal to an implementation.
longer be considered valid by the server that receives it, the server
MUST return the generic error "nonce_required" reporting the same
description as "error_description", as if the Nonce had not been
received. The cases when an issued Nonce is considered no longer
valid MAY be caused by the rotation of the encryption keys, its
expiration or other specific conditions internal to an
implementation.

9. Non-normative Examples of a Nonce Payload

Expand Down Expand Up @@ -367,25 +365,18 @@ Table of Contents
The main differences between the use of the jti and the Nonces can be
summarized as follows:

1. *Generation*: Nonces are generated by the server, while jti is
generated by the Client.
1. *Generation*: Nonces and jti can be are generated both by the
server and the client.

2. *Storage*: Nonces can be self-authenticating and self-contained
and therefore need not be stored. A common way to achieve this
is for the Nonce to contain content encrypted to the
Authorization Server that creates it. On the other hand,
checking jti properly definitely requires a store that is shared
across all domains that the associated JWT can be presented in.

3. *Lifetime*: The life span difference between a Nonce and a jti is
2. *Lifetime*: The life span difference between a Nonce and a jti is
significant. Nonces are kept just until the Client responds,
which happens practically immediately after they are obtained,
resulting in a very short lifespan. A jti, on the other hand,
must be stored until the expiration window of its associated JWT
expires, which is a substantially longer length than that of a
Nonce.

4. *Security*: Nonces prevent replay attacks by ensuring that the
3. *Freshness*: Nonces prevent replay attacks by ensuring that the
proof of possession is fresh. On the other hand, jti does not
guarantee freshness and using client-generated timestamps has
problems, even for non-attacking Clients (e.g. devices with
Expand Down
Loading

0 comments on commit 4d1c4ab

Please sign in to comment.