fix: no strict OAuth 2.0 AS depedency and more neutrality with jti comparison

draft-demarco-oauth-nonce-endpoint.md

@@ -60,7 +60,7 @@ This specification presents a comprehensive guide to the Nonce endpoint. It desc
 :  A random or pseudo-random number that is generated for a specific use, typically for cryptographic communication. The Nonce is used to protect against replay attacks by ensuring that a message or data cannot be reused or retransmitted. The term "Nonce" stands for "number used once" and it MUST be unique within some scope.
 
 **Nonce Issuer**:
-:  The entity that generates and provides the Nonce. The Nonce Issuer would typically be the Authorization Server.
+:  The entity that generates and provides the Nonce.
 
 **Nonce Endpoint**:
 :  The HTTP endpoint provided by the Nonce Issuer for the issuance of the Nonces.
@@ -107,7 +107,7 @@ The OAuth 2.0 Authorization Server MUST include the `nonce_endpoint` metadata in
 
 ### 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`:
 
 ~~~~
 {
@@ -166,12 +166,12 @@ Content-Type: application/json
 
 # 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.
+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 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:
+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:
 
 ~~~~ http
 HTTP/1.1 400 Bad Request
@@ -180,11 +180,11 @@ 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.
+In cases where, for some reasons, a correctly issued Nonce can no 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.
 
 # Non-normative Examples of a Nonce Payload
 
@@ -238,13 +238,11 @@ Both `jti` and Nonces are used to prevent replay attacks, however Nonces offer m
 
 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.
+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.
 
-3. **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 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 incorrect time-zones or daylight saving settings).
+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 incorrect time-zones or daylight saving settings).
 
 # IANA Considerations